[netperf-talk] exact behaviour of generated burst traffic

[Rick Jones]

> OK, I'm fine with that. 
> Let's imagine follwowing concrete example:

> Let's say I set parameter "-w 100". And let us assume I choose a
> right value for parameter -b, so that sending a burst would end after 10ms.
> What happens in the 90 ms till the next burst is sent out (I mean are
> there sent still packets in a different rate or aren't there sent
> packets at all)?
> I ask this question, because when I get the stats of my measurement,
> I always have about the same amount of packets emitted, no matter I choose
> long intervals with short bursts or vice versa (of course I chose also
> values stepwise in between).


If the burst completes before the interval timer fires, netperf should 
sit in a sigsuspend() call until the interval timer fires.  While it is 
sitting in that sigsuspend() call, netperf will not be making any calls 
to send.

That sigsuspend() call would become just a "sit and spin" call if you 
configure netperf with --enable-spin in addition to --enable-burst.  It 
should behave otherwise the same, but allow finer granularity on the 
burst interval - at the expense of CPU consumption.

If the burst stuff is indeed compiled-in, and if you set the -w to 
something obscenely large and still you get the same results, it is time 
for debugging.  A system call trace would be one place to start - 
perhaps sigsuspend() is returning an error that netperf is not otherwise 
noticing.

happy benchmarking,

rick jones