[netperf-talk] Question about burst mode and interval

[Rick Jones]

George Valzcig wrote:
> Hello all,
> I have come questions about the burst mode. I have gone through the code 
> and this is what I have understood from the code so far. Kindly point me 
> out if I have got anything wrong.

First is, based on what you have below, you are asking about intervals mode, not 
burst mode :)  Burst mode is where an *_RR test can have more than one 
transaction in flight at one time.

> I am working with an example of -t UDP_STREAM -b 5000 -l 10s -w 1s
> 
> 1) By default the start_timer()sets the SIGALRM catcher and the value of 
> the ITIMER_REAL to test_len and initializes the test_len_ticks to 1. 
> Then INTERVALS_INIT() will reset the value of the ITIMER_REAL to 1 
> second (specified by -w) and test_len_ticks to 10 (10s / 1s) - correct?.
> 
> 2) From here on, the timer will pop up and invoke catcher() every one 
> second. At the end of 10 seconds (when test_len_ticks has decremented to 
> 0), this will stop the timer and complete the test - correct?

That is my recollection of how I coded it, yes :)

> 3) At the end of every 5000 (-b) packets being sent, the 
> INTERVALS_WAIT() is called and the process is SIG_BLOCK'ed. I dont 
> understand how this is unblocked and next burst sent?

There is a signal raised by the interval timer.

> 4) Also, lets say that this 5000 packets is sent in 1.5 seconds and then 
> the SIG_BLOCK happens - how does ensure that the process waits for 1 
> seconds and not 0.5 seconds (i.e. till the timer pops up again)?

What will happen (on anything other than HP-UX IIRC) is the interval timer will 
pop in the middle of the send burst and the logic there will interpret it as 
meaning the test is over (or perhaps that there was an error on the system 
call).  At least at points in the past there were platforms where when the burst 
takes longer than the interval to send, the test would end prematurely.

In other words, keep the burst short enough to complete within the interval :)

hth,

rick jones

> 
> Thanks
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netperf-talk mailing list
> netperf-talk at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk