Steve> A much shorter timer works well with this scheme, as it is
Steve> restarted every time something significant happens. Even under
Steve> flood conditions it can't keep restarting forever, as you will
Steve> hit high tide (which is exactly what you want to do). This can
Steve> be implemented with a shorter timer, causing less low traffic
Steve> latency. Under low traffic conditions you may get somewhat more
Steve> interrupts, but under those conditions who cares? This is
Steve> exactly what a 16550A UART does. There, the timer is actually 2
Steve> characters times of idling on the receive line (assuming all
Steve> the clones follow the original NS chip faithfully).
Ok I see what you mean, having an inbetween packet timer might be a
good idea as well.
Steve> I'm not sure why anyone would implement the first strategy. The
Steve> second strategy is just as easy to implement in silicon, but
Steve> will perform better in almost every case. The first strategy
Steve> offers little over using a timed poll. The second strategy
Steve> tunes things more closely to the traffic.
Maybe they didn't think of it.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/