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 >> [email protected] >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
