Hey Drew,
On Sep 25, 2014, at 1:47 PM, Andrew Gallatin
<galla...@gmail.com<mailto:galla...@gmail.com>> wrote:
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<http://libiperf.la/>" && ln
-s "../libiperf.la<http://libiperf.la/>" "libiperf.la<http://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<http://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
That’s bizarre. What type of host was this on?
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
Yeah, some sort of “—disable-jitter” flag would probably make sense.
Cheers,
Aaron
Drew
On Thu, Sep 25, 2014 at 9:16 AM, Aaron Brown
<aa...@internet2.edu<mailto: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<mailto: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<mailto:Iperf-users@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/iperf-users
------------------------------------------------------------------------------
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
