>>>>> "kuznet" == kuznet <kuznet@xxxxxxxxxxxxx> writes:
kuznet> Khm... Please, get some simple benchmark applet sort of netperf
kuznet> and enjoy with this impossible phenomenon on single 100Mbit
kuznet> interface. Despite of all the "max job on interrupt" linux-2.2
Alexey is totally right. Even with maximum of work on interrupt, a Linux
box facing full speed fast ethernet simply stops.
kuznet> never leaves irq handler and does no job in result. BSD (and NT,
kuznet> by a strange reason) with their silly approach _work_ at any load
kuznet> level, by the way.
That's is essentially because BSD go and process the packet, discarding
thousands at the NIC layer (due to it being out of receive buffers), and
therefore get a little bit of work done.
Linux tries (smartly) to empty the entire queue from the network card
before processing any packets, and since it just can't keep up, period, it
never finishes, regardless of max-interrupt-work --- there is immediately
another interrupt.
See
http://www.research.solidum.com/papers/ols1999/top.html
NT "solves" the problem because most of its drivers are actually threads,
so they must submit to scheduling as well. (that's also what makes them so
unresponsive)
To solve the the problem, you have to do QoS on CPU scheduling, or offload
the bulk of the work to smarter hardware...
:!mcr!: | Solidum Systems Corporation, http://www.solidum.com
Michael Richardson |For a better connected world,where data flows faster<tm>
Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
mailto:mcr@xxxxxxxxxxxxxxxxxxxxxx mailto:mcr@xxxxxxxxxxx
|