Hi guys, I''m doing some tests to understand how credit and sedf schedulers perform on real-time systems in mixed io and cpu intesive environments. During my first test I saw a quite strange behaviour I''m going to describe. The test has been setup as follow: 1 domain running Linux with default scheduler setup and one bridged network. Here iperf run as a client and sends udp packet to an host on the same net with 1Mb/s rate. Dom0 runs nothing except XenMon. Iperf (server mode) and a tcpdump run on a non-virtualized host. Measuring packets inter occurences, I''d expect to find out a costant value because of the constant rate at which the packet are sent. It''s not so. Let say the first packet arrives after 1ms, the second arrives after 3, the third after 4, the fourth after 6 and so on. The interoccurence times are: Packet# Absolute Time Interoccurence Time 1 1 1 2 3 2 3 4 1 4 6 2 5 7 1 6 9 2 ... .... I tried to shutdown domU and run iperf on dom0, same result. The last test I made was run iperf on a non-virtualized environment. And here I got the results I expect: constant interoccurence time. Do you have any idea of the reasong why the packet are sent with this strange rate even if there are no other domains competiting for resources? Thaks, Marco On Xen the packet are sent, and then receive _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
What''s the granularity of your measurement? If, for example, the actual delta between was 1.5ms, but you''re only measuring at a 1ms granularity, you''d expect to see something like this: Actual time, measured time 1 , 1 2.5, 3 4 , 4 5.5 , 6 7 , 7 &c -George On Tue, Jul 28, 2009 at 9:21 AM, Marco Tizzoni<marco.tizzoni@gmail.com> wrote:> Hi guys, > I''m doing some tests to understand how credit and sedf schedulers > perform on real-time systems in mixed io and cpu intesive > environments. > During my first test I saw a quite strange behaviour I''m going to describe. > > The test has been setup as follow: 1 domain running Linux with default > scheduler setup and one bridged network. Here iperf run as a client > and sends udp packet to an host on the same net with 1Mb/s rate. Dom0 > runs nothing except XenMon. Iperf (server mode) and a tcpdump run on a > non-virtualized host. > > Measuring packets inter occurences, I''d expect to find out a costant > value because of the constant rate at which the packet are sent. It''s > not so. > Let say the first packet arrives after 1ms, the second arrives after > 3, the third after 4, the fourth after 6 and so on. The interoccurence > times are: > Packet# Absolute Time Interoccurence Time > 1 1 1 > 2 3 2 > 3 4 1 > 4 6 2 > 5 7 1 > 6 9 2 > ... .... > > I tried to shutdown domU and run iperf on dom0, same result. > The last test I made was run iperf on a non-virtualized environment. > And here I got the results I expect: constant interoccurence time. > > Do you have any idea of the reasong why the packet are sent with this > strange rate even if there are no other domains competiting for > resources? > > Thaks, > Marco > On Xen the packet are sent, and then receive > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Jul 28, 2009 at 3:03 PM, George Dunlap<George.Dunlap@eu.citrix.com> wrote:> What''s the granularity of your measurement?I use tcpdump/tshark to dump e decode incoming packets and I think it uses the timestamp from the nic. The two gaps are 0.011781 and 0.011731 and they remain constant over the time. This is a snap: # Order AbsoluteTime DeltaTime 1 0.000000 0.000000 2 0.009734 0.009734 3 0.021515 0.011781 4 0.033245 0.011730 5 0.045027 0.011782 6 0.056757 0.011730 7 0.068538 0.011781 8 0.080269 0.011731 9 0.092050 0.011781 10 0.103831 0.011781 11 0.115562 0.011731 12 0.127342 0.011780 13 0.139073 0.011731 Attached a decoded dump of 10 seconds with arrival order, absolute time, relative time. Also you can find a graph where this issue is clear. Thanks, Marco _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
That''s a difference of only 0.5%. It is interesting that it''s bi-modal, but I don''t think it''s very significant. If you''re really keen to just understand where that comes from, you can try taking a trace and analyzing the results. -George On Tue, Jul 28, 2009 at 3:09 PM, Marco Tizzoni<marco.tizzoni@gmail.com> wrote:> On Tue, Jul 28, 2009 at 3:03 PM, George > Dunlap<George.Dunlap@eu.citrix.com> wrote: >> What''s the granularity of your measurement? > > I use tcpdump/tshark to dump e decode incoming packets and I think it > uses the timestamp from the nic. > The two gaps are 0.011781 and 0.011731 and they remain constant over > the time. This is a snap: > > # Order AbsoluteTime DeltaTime > 1 0.000000 0.000000 > 2 0.009734 0.009734 > 3 0.021515 0.011781 > 4 0.033245 0.011730 > 5 0.045027 0.011782 > 6 0.056757 0.011730 > 7 0.068538 0.011781 > 8 0.080269 0.011731 > 9 0.092050 0.011781 > 10 0.103831 0.011781 > 11 0.115562 0.011731 > 12 0.127342 0.011780 > 13 0.139073 0.011731 > > > Attached a decoded dump of 10 seconds with arrival order, absolute > time, relative time. > Also you can find a graph where this issue is clear. > > Thanks, > Marco > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Jul 28, 2009 at 4:15 PM, George Dunlap<George.Dunlap@eu.citrix.com> wrote:> That''s a difference of only 0.5%. It is interesting that it''s > bi-modal, but I don''t think it''s very significant.Yes you''re right but it''s quite intersting that it does not occurs in non virtualized envs.> If you''re really > keen to just understand where that comes from, you can try taking a > trace and analyzing the results.Do you have any tools (xentrace?) for taking the trace or suggestions (i.e. object/events to trace)? thanks, Marco _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel