Okay i need a little help.
So, I have this qdisc module q_xcp.so that was compiled for tc version 2.4.7, so I have version 2.4.7 for q_xcp.so to work properly. I tried using q_xcp.so with a the newest version of iproute/tc but it seems as though since version 2.4.7 qdisc_util structure has changed some and i keep getting seg faults trying to use q_xcp. For instance, in the newer versions of tc, i see qdisc's structures defined like:
struct qdisc_util netem_qdisc_util = { };
and in the same newer versions, in tc.c get_qdisc_kind, before it calls "q = dlsym(dlh, buf);" ... it sets buf to "%s_qdisc_util"
however in the old version of tc that q_xcp was made for, it sets buf to "%s_util"
so I guess my main question is, do you know of a version of iproute/tc that uses this old structure that has netem support? I tried copying the q_netem.c code from the newer version of iproute and trying to compile it for an old version of ip route... but its just not working out nicely at all
I'd greatly appreciate any help.
Thanks!
George
> 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
