---------- Forwarded message ---------- From: Dave Taht <dave.taht@xxxxxxxxx> Date: Mon, Sep 15, 2014 at 1:16 PM Subject: Re: Unexpected result with PFIFO or PRIO queue disciplines To: Miguel Ángel Bernabé <mabernabe@xxxxxxxxxxxxxxxxxx> Cc: lartc@xxxxxxxxxxxxxxx No this is an expected result. You are observing classic bufferbloat in your dsl device. NO AMOUNT of classification can help there. The codel algorithm and fq_codel will reduce the queue length appropriately in conjunction with htb to move the bottleneck queue to your device. There are now several scripts to set this up out there, A simple one: http://wiki.gentoo.org/wiki/Traffic_shaping Note you need to increase the target parameter on the 768k uplink to 18 ms and do atm and pppoe compensation if needed. A more complex one: https://github.com/dtaht/ceropackages-3.10/tree/master/net/sqm-scripts/files/usr/lib/sqm Which handles that and also will respect tos markings. (I need to get around to making sqm just work on ubuntu. It ports right over, but doesn't modprobe ifb and other tweaks) Examples of results: http://burntchrome.blogspot.gr/2014_05_01_archive.html http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html On Sep 11, 2014 2:56 AM, "Miguel Ángel Bernabé" <mabernabe@xxxxxxxxxxxxxxxxxx> wrote: > > Using Ubuntu 12.10 (Linux version 3.5.0), i would like to do some basic QoS on an ethernet interface. This ethernet interface is the default route to the internet. > > As i concern, the default Linux queue discipline configured for network devices is the `pfifo_fast` queue discipline that gives priority regarding TOS mark in the IP datagram header. > > To test this queue discipline i am using `ping` with the option `-Q` to set the DSCP value of the packets. > > $ ping -Q 184 www.google.com > > I start with a round-trip time about 50ms but as soon i start to upload a file to Dropbox service via HTTP the ping time increases up from 50ms to 1500ms and it becomes very unstable. I have checked that TOS mark for Dropbox traffic is 0x0. > > Then I am trying to accomplish the same task using `PRIO` queue discipline. To test this queue discipline i create the root PRIO queue discipline associated to the ethernet interface. Then i add a filter to send ICMP traffic to the most priority queue: > > # tc qdisc add dev eth0 root handle 1: prio > # tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1 > > After configuring `PRIO` queue discipline i am failing with the same result, ping time increases much again as soon i upload a file to any hosting service. > > I have checked tc statistics and i see that ICMP packets are already sent to the band 0 while dropbox traffic is queued in a less priority queue. > > $ tc -s class show dev eth0 > class prio 1:1 parent 1: > Sent 7486 bytes 74 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > class prio 1:2 parent 1: > Sent 863935 bytes 1956 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > class prio 1:3 parent 1: > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > > My gateway is connected to the internet via ATM/DSL connection, upstream speed is 0.6Mbps and downstream speed is 10Mbps. If i configure the router as a bridge between LAN/ATM ports and I try to connect via PPPoE from LAN (so i configure the Qdisc for ppp0 interface) I get the same unexpected result, so the bottleneck is not in my router. > > Are `prio` or `pfifo_fast` queue disciplines broken in the Linux kernel?. > > -- > To unsubscribe from this list: send the line "unsubscribe lartc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
