The host was ubuntu 12.04, on an x86_64, running a custom 3.11 kernel.
Other versions of iperf work fine, as does netperf.
On Mon, Sep 29, 2014 at 5:30 AM, Aaron Brown <aa...@internet2.edu> wrote:
> Hey Drew,
>
> On Sep 25, 2014, at 1:47 PM, Andrew Gallatin <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" && 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
>
>
> 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> 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
>>
>>
>
>
------------------------------------------------------------------------------
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
