[Click] gaprate has startup bug

[Eddie Kohler]

Hi Bart,

GapRate's implementation is aligned on second boundaries.  For example, if the 
rate is 2 pps, then GapRate will approve packet generation at X.0 and X.5 
seconds, for every X.

Imagine a GapRate that always accepted the first packet, then went back to 
normal behavior.  If the first packet arrived at X.999999 seconds, that'd be bad.

So I checked in a fix that will sometimes let the first packet be accepted. 
Hopefully that's good enough.

In the long term, RatedSplitter should maybe use something other than GapRate.

Eddie


Bart Braem wrote:
> Hello,
> 
> I've been busy investigating why ratedsplitter always drops the first packet. 
> Here's why:
> - ratedsplitter uses _rate.set_rate (with error handler argument) in its 
> configure
> - after a check on too large rates set_rate calls its own set_rate (without 
> error handler argument) which calls reset at the end
> - one of the things reset does is setting _tv_sec to -1
> - next the first packet arrives at ratedsplitter, that calls need_update
> - need_update check checks wether _tv_sec is negative and so sets sec_count to 
> ((now.tv_usec << UGAP_SHIFT) / _ugap) + 1
> - unsigned need is set to ((now.tv_usec << UGAP_SHIFT) / _ugap)
> (that last one always turns out to be 0 in my simulations!)
> - the result of need_update is: (int)need >= sec_count
> - that's not true, so ratedsplitter pushes on port 1, so first packet is 
> dropped...
> 
> My guess is that somewhere the unsigned-signed conversion doesn't do its job. 
> Mainly because otherwise need would always be smaller than _sec_count...
> Does someone know more about this piece of the code? Or should I just abondon 
> it?
> 
> Bart
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click