On Tue, Nov 17, 2009 at 5:00 PM, clownix wrote:
> The qdisc may not be the only queue in your system, I have had
> bad qdisc experiences because of another waiting queue
> after the qdisc queue, and the jam is sadly at this point:
>
> traffic ---> QDISC ----> BIG JAM ----> ppp link
Is it possible this mystery queue is a serial port
kernel driver buffer for the serial port that ppp is
connected to? I think the serial port drivers have 4k
buffers which is pretty close to the ~4600 bytes
that seem to be getting buffered up somewhere.
Cheers...
Dave
>
> If the qdisc can transmit freely, it does not "feel" the jam
> that is afterwards and lets low priority pass because there is
> no problem.
>
> A solution, not perfect because it wastes a little bandwidth
> is to "shape" your traffic before your jam.
>
> For this, you can use the hfsc:
> I have made a little tool that can monitor the qdiscs, a hfsc script
> is provided with it, if you have some time, you can try to make it run,
> it is at http://clownix.net
>
> Regards
> Vincent Perrier
>
>
>
> Le mardi 17 novembre 2009 à 16:29 -0800, David L a écrit :
>> On Tue, Nov 17, 2009 at 3:11 PM, clownix wrote:
>> > Try the following:
>> >
>> > tc qdisc del root dev eth0
>> > tc qdisc add dev eth0 root handle 1: prio
>> > tc filter add dev eth0 parent 1:0 protocol all u32 match u32 0x00000000
>> > 0x00000000 at 0 flowid 1:3
>> > tc filter add dev eth0 parent 1:0 protocol all u32 match u32 0x00E00000
>> > 0x00E00000 at 0 flowid 1:1
>> >
>> >
>> > ping -Q 255 192.168.1.1
>> > tc -s class ls dev eth0
>> >
>>
>> Thanks for your response.
>>
>> I tried this on both sides of the ppp link and I see that the filter
>> is categorizing the pings differently from the miscellaneous http traffic:
>>
>> tc -s class ls dev ppp0
>> class prio 1:1 parent 1:
>> Sent 5124 bytes 61 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> class prio 1:2 parent 1:
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> class prio 1:3 parent 1:
>> Sent 1144196 bytes 4119 pkt (dropped 68, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>>
>>
>> However, the ping statistics are a lot worse when the http traffic is active:
>>
>> 60 packets transmitted, 60 received, 0% packet loss, time 59057ms
>> rtt min/avg/max/mdev = 5.828/65.577/404.738/90.916 ms
>>
>> than when it is inactive:
>>
>> 60 packets transmitted, 60 received, 0% packet loss, time 59117ms
>> rtt min/avg/max/mdev = 5.931/6.747/7.418/0.356 ms
>>
>>
>> 404 msecs maximum ping time when I had http traffic active
>> versus 7 msecs when it wasn't active. 400 msec difference
>> corresponds to about 4600 bytes over the 115200 ppp serial
>> link. The MTU was set to 500 bytes, so I don't understand
>> where that time is coming from if the pings are being queued
>> in preference to the http traffic. I'd expect the maximum ping
>> time to be about 50 msec, not 400 msec. What am I missing?
>>
>> Thanks,
>>
>> David
>>
>>
>> >
>> > Le mardi 17 novembre 2009 à 14:14 -0800, David L a écrit :
>> >> Hi,
>> >>
>> >> I need to prioritize data sent on a socket over a ppp link
>> >> so it is transmitted before some other data sharing that link.
>> >> I googled around for a few days and I thought I understood
>> >> how I might go about doing this, but my attempts have
>> >> failed.
>> >>
>> >> I thought the default qdisc (pfifo_fast) would prioritize data
>> >> flagged as "lowdelay" by putting it in a different band that has
>> >> preferential queuing priority over data in other bands. I
>> >> attempted to configure the socket like this:
>> >>
>> >> int lowdelay = IPTOS_LOWDELAY;
>> >> return setsockopt(servFd_, IPPROTO_IP, IP_TOS,
>> >> (void *)&lowdelay, sizeof(lowdelay));
>> >>
>> >>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-net" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
