Notes from Zhonghua
In this paper, the author analyzed the performance of Amazon EC2 instances focusing on the CPU and network.
The author used Badabing tool[1] for packet loss measurement and CPUTest (created by themselves, but really smart and easy to build. This program is a loop using gettimeofday() to store the timestamp in a pre-allocated vector to exam the time cost of each loop. Then the CPU sharing can be found because if no context switch, the time gap between each loop should be same) for CPU measurement. These tools can also be used by us in research.
The author mentioned in Section III.A that "we always run the CPUTest program as the only user process in our processor sharing experiments to minimize the impact of context switching." And in Section IV, the author also tells that the 20% cases where medium instances get 95% of the CPU sharing may caused by the context switch between the CPUTest program and kernel service processes. I think, if we want a more accurate result, the kernel can be modified to be non-preemptible to prevent the context switching.
In discussion of bandwidth measurement in Section V.A, the author did not mention that the difference of TCP and UDP bandwidth in small instances may caused by the processing overhead of TCP flow. TCP is more complex than UDP in control thus introduced some overhead. In the medium instances, as the computational power is higher, this overhead may not be enough to influence the TCP bandwidth. But in the small size ones, it is probably that it lower the TCP bandwidth.
[1] J.Sommers, P.Barford, N.Duffield, and A.Ron, "Improving accuracy in end-to-end packet loss measurement", in proceeding of SIGCOMM'05.
(12-09-2010 01:37 PM)szh Wrote: [ -> ]The author mentioned in Section III.A that "we always run the CPUTest program as the only user process in our processor sharing experiments to minimize the impact of context switching." And in Section IV, the author also tells that the 20% cases where medium instances get 95% of the CPU sharing may caused by the context switch between the CPUTest program and kernel service processes. I think, if we want a more accurate result, the kernel can be modified to be non-preemptible to prevent the context switching.
Would this non-preemptive schedule be viable and practical to be implemented without hurting the fidelity of the measurements?
This paper measures impact of Xen virtualization on the networking performance
of EC2. The measurement show some interesting results:
1. EC2 may use strict virtual machine scheduling policy for the computation
capacity. Even there is no CPU competition on the same server, small instances
still gets no more than 50% of the processor. The interval "suspension" causes
the network of small instance to has some "gaps".
2. On the other hand, medium instances get more stable CPU and network
performance.
Zaharia. et al also find similar result as 1. and design heterogeneous scheduler
for MapReduce [1].
Xen has multiple kinds of networking topologies [2]. One technique from [1] is
to find out dom0: using traceroute from each VM to an external URL -- the first
hop from a Xen virtual machine is always the dom0 or supervisor process for that
physical host. From this piece of information, we may infer EC2 possibly uses
"routing" networking topology. As in "bridging" based networking topology, the
first hop is not dom0 and we have confirmed this in our cluster (we use
"bridging").
[1]
http://baijia.info/showthread.php?tid=209
[2]
http://wiki.xensource.com/xenwiki/XenNetworking