RE: [ns] About pareto.cc

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

>> 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"...
>
>    Personally, I don't think that generating pareto r.v.'s based on
>"ontime_" and
>"burstlen_," respectively,  have the same meaning. burstlen_ 
>is magnified,
>as always is the case, and the time resolution is spoiled. 

Random::pareto(scale,shape) returns  scale / (u ^ (1 / shape)) where u is a
uniformly distributed random variable (see rng.h). So dividing scale by
interval_ is identical to dividing the random value by interval_. It makes
no difference. Or am I misunderstanding what you're saying ?

>ontime_ should be
>used for calculating p1_, and rem_ is determined right after that by
>"p1_ / interval_."
>>
>> 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.
>
>    rem_ = 0 would be caused by 2 factors: one is zero-valued 
>r.v.,

well, if the random variable causes rem_ = 0, rem_ is set to 1 in the code
so as never to have a next burst of 0 packets. So rem_ can never be set to
zero, only decreased to zero.

>but the
>other is due
>to "transmission deadline." For the latter, the "interval_" is 
>not included
>in "t" calculation,
>I think.

t has a minimum of interval_, otherwise you start sending a second packet
before the first one has been totally sent. If you want an idle_time long
delay between the end of packet1 and the beginning of packet2, you need
interval_+idle_time between the beginning of packet1 and the beginning of
packet2. Once again, next_interval is called just before a packet is sent,
and rem_ = 0 means that there is still one packet to be sent in the current
burst of packets.

Rgds,
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
*******************************************************************************