[netperf-dev] [netperf-talk] Considering declaring a 2.6.0 release

[Rick Jones]

> It though may have an intermittent issue with PAD_TIME too :) The extent
> to which that can be detected/compensated for is a good question. While,
> IIRC, the "omni" tests will attempt to signal end-of-test via a series
> of zero-length UDP datagrams, that is not a "reliable" signal. And even
> if the timer does pop, we don't "know" that the data stream actually
> terminated PAD_TIME seconds ago (long latency networks, buffer-bloat,
> etc - anywhere where one sees a TCP_STREAM test end somewhat longer than
> the desired test-time is the situation I'm thinking of)

Here is a small example, between my workstation and another system 
across a WAN:

raj at tardy:~/netperf2_trunk/src$ ./netperf -H <wansystem> -D 1
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
<wansystem> () port 0 AF_INET : interval : demo
Interim result:   18.55 10^6bits/s over 1.017 seconds ending at 
1335826552.879
Interim result:   24.69 10^6bits/s over 1.008 seconds ending at 
1335826553.887
Interim result:   26.17 10^6bits/s over 1.047 seconds ending at 
1335826554.934
Interim result:   27.67 10^6bits/s over 1.004 seconds ending at 
1335826555.938
Interim result:   27.42 10^6bits/s over 1.009 seconds ending at 
1335826556.947
Interim result:   36.37 10^6bits/s over 1.024 seconds ending at 
1335826557.970
Interim result:   47.33 10^6bits/s over 1.022 seconds ending at 
1335826558.992
Interim result:   66.45 10^6bits/s over 1.002 seconds ending at 
1335826559.994
Interim result:   84.42 10^6bits/s over 1.015 seconds ending at 
1335826561.010
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

  87380  16384  16384    10.15      44.39

The test was nominally 10 seconds long, but it took another ~150 
milliseconds to get the notification that all the data made it to the 
remote - that is why at the netserver side at least the PAD_TIME exists.

I suspect if I were to run over something even more WAN and/or slower 
the broad issue of "bufferbloat" may rear its ugly head and have that be 
rather more than 150 milliseconds.  From time to time I receive reports 
from users where tests actually fail because there was more added delay 
than the PAD_TIME and so the netserver's timer expired.

rick