Hello again,
: I have a question for you though... in terms of adding loss like
: this, this will not interact with hardware layer rate control of
: wireless cards right?
:
: For instance... dropping from 54Mbit to 11Mbit on an 802.11g card
: when loss certain loss begins occuring
Outgoing packets pass through the traffic control system (netem
qdisc, in this case) just before being dequeued to the driver. The
actual behaviour of the kernel, in this case, depends on a sanely
coded driver. I assume a sanely coded driver, in which case this is
what you should see when the hardware cannot accept packet for
transmission:
0. netem (or any other qdisc, for that matter) will operate as
configured (inducing loss, delaying, reordering or
prioritizing your outgoing packets)
1. eventually qdisc_restart() will call hardware driver
2A. [if success] packet is transmitted
2B. [if failure] the hardware driver cannot handle the packet for
some reason (TX ring full, link failure or other problem); it
will propagate an error condition to higher layer
3. qdisc_restart(), receiving such an error will cause the packet
to be requeued [0]
4. goto step 1
My source for this answer documents kernel 2.4, although the code in
the networking stack seems to be fundamentally the same in this
case. See the DataTAG report entitled "A Map of the Networking Code
in Linux Kernel 2.4.20" [1]. On page 19, Section 4.3.1, the authors
refer to the function net/sched/sch_generic.c which includes
qdisc_restart().
So, strictly speaking, there should be no interaction between your
use of the netem qdisc and lower layer rate control (lossy
transmissions and any compensatory mechanisms between radios).
Note! Both of the sources for my answer are from old documentation
(and, of course, ongoing general knowledge of the traffic control
system). I believe that the kernel still operates in this fashion,
but would absolutely welcome any corrections from those who are more
intimately familiar with the kernel and hardware perspective.
Good luck, George,
-Martin
[0] http://qos.ittc.ku.edu/howto/node11.html
http://qos.ittc.ku.edu/howto/
[1] http://datatag.web.cern.ch/datatag/papers/tr-datatag-2004-1.pdf
--
Martin A. Brown --- http://linux-ip.net/ --- martin@xxxxxxxxxxxx
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
