Page 2:
I think you mean slower.and 6.2x faster than the Fedora KVM
Phoronix: Amazon EC2 Micro: Barely Faster Than A Nokia N900?
In December we published our first set of Amazon EC2 benchmarks for their Elastic Compute Cloud using Ubuntu EC2 and the different instances that were compatible. Now though we are in the process of carrying out a new set of benchmarks from Amazon's cloud that not only contains more tests, but using the official Amazon Linux AMI we tested nearly every instance type. Except what is missing are the results for the "micro" (the t1.micro API name) instance. Why? It is simply too slow and irregular.
http://www.phoronix.com/vr.php?view=15598
Page 2:
I think you mean slower.and 6.2x faster than the Fedora KVM
Hmm, well it does clearly indicate some of the limiting factor of smart phones...
Grr wrong thread:
Why does everyone seem so surprised by the results?
You get what you pay for, if you were running a hog of a program on a mainframe the work load balancer would severally cut your share of resources if you were a low priority user
The exact same is happening here
The varying results are entirely based on the current load of the instance it's running on and I don't think other users of that instance will be happy if a simple web app has poor responsiveness purely because a reviewer is hammering the system with mostly pointless benchmarks
I could understand reviewing the paid for instances where Michael would be prooving is you're getting bang for buck but this clearly isn't the case
so does that mean i should set-up my n900 as a cloud server![]()
Since it has been shown that the t1.micro instances throttle the cpu dramatically after 15 seconds, it would be hard to benchmark using any test that runs over 15 seconds. And I'm not sure how long it takes to go back to unthrottled speeds either.
Reference:
http://blog.documentcloud.org/blog/2...cro-instances/
The micro instance’s CPU is reasonably fast while bursting, but when the burst runs out then the rate limit is pretty brutal. The rate limited speed is roughly 1/3 of the burst speed that you get for the first 15 seconds.
A simple test, showing compute power per second with some sleep in-between runs to allow the rate-limiter’s bucket to refill:
#!/usr/bin/perl
my $firsttime = my $time = time;
for(my $x = 0; time-$firsttime < 30; $x++) {
if($time != time) {
printf "%2d %d\n", time-$firsttime, $x;
$x = 0;
$time = time;
}
}
# sleep 300; ./throttleme.pl; sleep 300; ./throttleme.pl
1 3050483
2 4499169
3 4351002
4 4480768
5 4491703
6 4495259
7 4502143
8 4494198
9 4174903
10 4097267
11 4259348
12 4370439
13 4216742
14 4379620
15 4499622
16 448604
17 132731
19 133197
20 132758
22 132523
23 129993
24 127614
25 133869
27 132596
28 133385
1 3637552
2 4357062
3 4086175
4 4352176
5 4357643
6 4044038
7 4353554
8 4356628
9 51296
10 129492
12 128712
13 126456
15 129196
16 125337
18 129433
19 111697
21 129684
22 128626
24 128390
25 129025
27 128435
28 128914
30 110801
One important observation here is that it appears to be skipping seconds once rate limiting kicks in. That implies the rate limiter is doing a few very long pauses to rate limit me (as opposed to doing lots of small pauses). So, I get really bad CPU jitter once the rate limiter kicks in.