[Click] suggested patch for DelayUnqueue

[Eddie Kohler]

:)  Sorry it took so long.  That IS what I meant; and congratulations on the 
writing phase!
E


On 2/23/11 5:19 PM, Ian Rose wrote:
> Hi Eddie -
>
> This patch is sufficiently long-ago that I'm not really using this code
> anymore (I'm on to dissertation writing :), so I don't have a stake in this
> currently. Purely from a "I want code to be good just for the sake of the
> universe even if I'm not using it" perspective, your modification seems
> reasonable, assuming that what you mean by "delayed time" is "[current time +
> DELAY-parameter] regardless of the actual delay (which may be longer than the
> DELAY-parameter)".
>
> cheers,
> - Ian
>
>
> On 02/23/2011 07:32 PM, Eddie Kohler wrote:
>> Hi Ian,
>>
>> Thanks for this long-ago patch.
>>
>> I actually am not sure that I like it. It slightly slows down
>> comparisons (trivially, but still), and it makes DelayUnqueue unlike
>> (say) LinkUnqueue, and it's the sort of configuration knob that confuses
>> me -- either it should always update or never update, I'd say.
>>
>> I applied some parts of the patch -- namely, not updating the timestamp
>> to THE CURRENT time but rather updating it to the delayed time; and
>> writable "delay" handler. Do you really need "UPDATE false" behavior?
>> Could you cope with, e.g.,
>>
>> DelayUnqueue(0.1) -> AdjustTimestamp(-0.1) -> ...
>>
>> ? (Just added AdjustTimestmap.)
>>
>>
>> Eddie
>>
>>
>>
>>
>> On 05/06/2010 10:22 AM, Ian Rose wrote:
>>> Hi -
>>>
>>> I've noticed that DelayUnqueue always updates the timestamp of output
>>> packets
>>> to the current time. The enclosed patch adds an optional UPDATE
>>> configuration
>>> parameter (default=true) that can turn off this behavior.
>>>
>>> cheers,
>>> - Ian
>>>
>>>
>>>
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click