Ok, I'll too think about adding the burst option to iperf2 that I've been doing and only call gettimeofday() for the first packet of the burst. It will make end/end latency less comprehensive as there won't be the usec timestamp in every packet (hence my reservations.)
http://sourceforge.net/projects/iperf2/?source=directory Bob -----Original Message----- From: Bruce A. Mah [mailto:b...@es.net] Sent: Wednesday, September 24, 2014 9:14 AM To: Bob (Robert) McMahon; Andrew Gallatin; iperf-users Subject: Re: [Iperf-users] gettimeofday If memory serves me right, Bob (Robert) McMahon wrote: > 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. Opened issue #210 in the iperf3 GitHub issue tracker for this problem. I found one fairly obvious not-so-smart thing that it does for Andrew's UDP test case...now to find time to fix and test it. https://github.com/esnet/iperf/issues/210 Thanks, Bruce. > *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 > ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
