Sorry to spam, but just to save anyone trying to help some time, I modified q_xcp to work with newer version of iproute2/tc now :)
So now I can use netem!
Thanks for everyones help.
- George
> 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
>
>
--
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
