I tried the tarball, and I could not get it to link on ubuntu 12.04. The
tail end of the compile is:
libtool: link: ranlib .libs/libiperf.a
libtool: link: ( cd ".libs" && rm -f "libiperf.la" && ln -s "../libiperf.la"
"libiperf.la" )
gcc -DHAVE_CONFIG_H -I. -g -g -O2 -Wall -MT iperf3-main.o -MD -MP -MF
.deps/iperf3-main.Tpo -c -o iperf3-main.o `test -f 'main.c' || echo
'./'`main.c
mv -f .deps/iperf3-main.Tpo .deps/iperf3-main.Po
/bin/bash ../libtool --tag=CC --mode=link gcc -g -g -O2 -Wall -g -lrt -o
iperf3 iperf3-main.o libiperf.la
libtool: link: gcc -g -g -O2 -Wall -g -o .libs/iperf3 iperf3-main.o -lrt
./.libs/libiperf.so
./.libs/libiperf.so: undefined reference to `timer_create'
./.libs/libiperf.so: undefined reference to `timer_delete'
./.libs/libiperf.so: undefined reference to `timer_settime'
collect2: ld returned 1 exit status
Amusingly, if I just ignore libfool, and link it manually, I get a binary:
% gcc -o iperf3 iperf3-main.o .libs/libiperf.a -lrt
Experimentally, it looks like the order of the -lrt is wrong, and it must
come last. Eg:
% gcc -o iperf3 iperf3-main.o -lrt .libs/libiperf.a
.libs/libiperf.a(timer.o): In function `tmr_reset':
/home/gallatin/iperf-3.0.7-signal/src/timer.c:162: undefined reference to
`timer_settime'
<...>
The binary itself behaves oddly:
Connecting to host 198.18.0.1, port 5201
[ 4] local 198.18.0.2 port 40068 connected to 198.18.0.1 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 0
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0
<...>
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
Datagrams
[ 4] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec 666910000.000 ms
-357639344/-357639343 (1e+02%)
[ 4] Sent -357639343 datagrams
Unfortunately, I'm no longer at Myricom, where I ran iperf on across 10GbE
or larger links on hosts with painfully slow gettimeofday(), and syscalls
in general (mostly FreeBSD with poorly configured timecounters, and Solaris
in various forms, and MacOSX). Without access to those hosts, my testing
may not be very helpful.
One other bit of feedback is that it would be great to get rid of the
gettimeofday around every packet (eg, turn off jitter measurement). A lot
of times you don't care about the jitter, and just want to fill the link.
I think that iperf2 was just doing the gettimeofday around each packet, and
that was still enough overhead on systems with expensive gettimeofday()
calls to reduce perceived performance from 9.4Gb/s to ~5Gb/s
Drew
On Thu, Sep 25, 2014 at 9:16 AM, Aaron Brown <aa...@internet2.edu> wrote:
> Hey Andrew,
>
> I’ve got a few patches I hacked together that use posix timers for the
> timers instead of the heavy gettimeofday usage done before. They seem to
> work, with the caveats that it stills calls gettimeofday per-packet, the
> intervals can be slightly off (e.g. 0.00-1.06 instead of 0.00-1.00), and
> i’ve not tested burst mode at all to verify if it works or not. You can
> grab a copy of the source from
> http://ndb1.internet2.edu/~aaron/iperf-3.0.7-signal.tar.gz . The patches
> themselves are:
>
>
> http://ndb1.internet2.edu/~aaron/0001-Modify-the-timer-stuff-to-use-POSIX-timers-instead-o.patch
>
> http://ndb1.internet2.edu/~aaron/0002-Handle-the-rate-based-tests-using-timers-instead-of-.patch
> http://ndb1.internet2.edu/~aaron/0003-Remove-some-spurious-commits.patch
>
> I’d be curious what your experience with these ends up being since
> gettimeofday runs quickly on my hosts :)
>
> Cheers,
> Aaron
>
> On Sep 10, 2014, at 12:14 PM, Andrew Gallatin <galla...@gmail.com> wrote:
>
> > 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
