[netperf-talk] PAD_TIME in 2.4.5

[Rick Jones]

First a procedural note.  When changing the topic of a thread so fully, 
it is best to start a new base message rather than using a reply-to. 
That way when someone is scanning thread subjects, your's won't be 
buried behind the initial one.

On 04/04/2012 01:14 PM, Srikanth Sundaresan wrote:
> We faced some issues using netperf 2.4.5 on low bandwidth networks.
>
> The recv() call was getting interrupted by a SIGALRM; we figured it's
> caused by low values of PAD_TIME. Our guess is that with high
> buffering in modems the delays (multiple seconds) is causing a
> timeout. This only occurs on upstream tests and not on downstream
> tests (presumably because the data rates are higher, and so buffering
> is lower).

Have you heard about the efforts at http://www.bufferbloat.net/ ? 
Unless those modems are connected to something that has seconds 
"natural" latency it sounds like they are truly bufferbloated (queue 
length bloated).

> We *kind of* fixed this by setting higher values of PAD_TIME - it
> seems to work better with ~30 seconds (our tests are 15 seconds
> long). We have two questions regarding this fix:
>
> 1) Will higher PAD_TIMEs affect test accuracy?

One of the more active users of netperf under Windows believes it might 
(thanks to the way it happens to work there, but I think for Linux it 
would be "OK." Netperf on *nix has had a PAD_TIME "since the beginning"

> 2) Do we need to patch the client too? Currently we test both sides
> by running -t TCP_STREAM and -t TCP_MAERTS respectively; does the
> client time out too?

I think it would be best if both netperf and netserver had the same 
concept of the value of PAD_TIME.  That is just a gut-level thing, not 
backed-up by code inspection.

Also, if there is indeed that much buffering in the modem(s) you might 
want to consider explicit, smaller socket buffer sizes than system 
defaults.  I wouldn't be surprised if Linux autotuning didn't play all 
that well here either, which would be another reason to go with 
explicitly set socket buffer sizes.

rick jones