What about the idea of supporting bursts (vs single packets) and only calling
gettimeofday() for each burst? I think this effectively supports your gofast
idea as defined by the burst size.
Bob
From: Andrew Gallatin [mailto:galla...@gmail.com]
Sent: Wednesday, September 10, 2014 9:15 AM
To: iperf-users
Subject: [Iperf-users] gettimeofday
I was looking at the iperf3 source code, and its ... unfortunate ... that
iperf3 still seems to be nearly as much of a gettimeofday() benchmark as it is
a network benchmark.
For example, if I want to send UDP as fast as possible, I'll do something like:
iperf -c 172.18.126.63 -u -b 9999999M
If I use strace -c on this, I see:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
42.92 0.238950 1 287535 gettimeofday
41.96 0.233611 3 71567 write
14.87 0.082772 1 72900 select
The pattern seems to be:
gettimeofday
gettimeofday
select
gettimeofday
gettimeofday
write
gettimeofday
gettimeofday
select
<repeats>
This isn't a problem on *most* OSes (and it is getting better), but it can lead
to surprisingly bad results on 10GbE or 40GbE networks on some OSes, especially
one that chose an expensive timecounter (eg, one that does a PIO read access on
every gettimeofday). This is the big reason why I still use netperf.
Maybe iperf needs a "go fast" option that dispenses with all timing except to
mark the time at the start & end of the test.
Drew
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
