Le dimanche 27 fÃvrier 2011 Ã 12:55 +0200, Jussi Kivilinna a Ãcrit :Quoting Albert Cahalan <acahalan@xxxxxxxxx>:
> On Sun, Feb 27, 2011 at 2:54 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
>> Le dimanche 27 fÃvrier 2011 Ã 08:02 +0100, Mikael Abrahamsson a Ãcrit :
>>> On Sun, 27 Feb 2011, Albert Cahalan wrote:
>>> > Nanoseconds seems fine; it's unlikely you'd ever want
>>> > more than 4.2 seconds (32-bit unsigned) of queue.
>> Problem is some machines have slow High Resolution timing services.
>> _If_ we have a time limit, it will probably use the low resolution (aka
>> jiffies), unless high resolution services are cheap.
> As long as that is totally internal to the kernel and never
> getting exposed by some API for setting the amount, sure.
>> I was thinking not having an absolute hard limit, but an EWMA based one.
> The whole point is to prevent stale packets, especially to prevent
> them from messing with TCP, so I really don't think so. I suppose
> you do get this to some extent via early drop.
I made simple hack on sch_fifo with per packet time limits
(attachment) this weekend and have been doing limited testing on
wireless link. I think hardlimit is fine, it's simple and does
somewhat same as what packet(-hard)limited buffer does, drops packets
when buffer is 'full'. My hack checks for timed out packets on
enqueue, might be wrong approach (on other hand might allow some more
Qdisc should return to caller a good indication packet is queued or
dropped at enqueue() time... not later (aka : never)
Accepting a packet at t0, and dropping it later at t0+limit without
giving any indication to caller is a problem.
This is why I suggested using an EWMA plus a probabilist drop or
congestion indication (NET_XMIT_CN) to caller at enqueue() time.
The absolute time limit you are trying to implement should be checked at
dequeue time, to cope with enqueue bursts or pauses on wire.