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