RE: [ns] About pareto.cc

["Timothy.Bauge" <Tim.Bauge@rrl.co.uk>]

	I think that some lines in pareto.cc are quite strange:
	(i) burstlen_ is used for p1_ calculation. In that way ontime_
	    will be lengthened for tens or hundreds of times and
	    once it's on, it goes ON and ON. After replacing burstlen_
	    w/ ontime_, everything is more reasonable.

Note that p1_ and rem_ are numbers of packets, p2_ and t are delays. During
an ON period, rem_ != 0 and t = interval_ (i.e. packet serialisation time)
so packets are sent back to back, which is the correct behaviour. I'm not
sure what you mean by "more reasonable"...

	(ii) as rem_ gets to 0, an idle period is calculated and set to t.
	    In pareto.cc that idle period was added to t instead of setting
to t.
	    I have no idea why t must be (interval_ + idle period).

If rem_ = 0 at the beginning of next_interval, there is still 1 packet to be
sent in the current burst. Therefore the subsequent packet will be sent at
interval_ + next idle period, i.e. serialisation time for the last packet +
next idle time.

Hope this helps.
Regards,
Tim


*******************************************************************************
This email and any files transmitted with it are intended solely for the use of
the individual or entity to whom they are addressed and may not be divulged to
any third party without the express permission of the originator.  Any views
expressed in this message are those of the individual sender, except where the
sender specifically states them to be the views of Thales Research Ltd.

Following the acquisition of Racal Electronics plc by Thomson-CSF, please note
that our new name is Thales Research Ltd.  For more information regarding the
Thales Group (formerly Thomson-CSF) please see our website www.Thalesgroup.com
*******************************************************************************