From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Goodman Date: Sun, 06 Jul 2014 15:34:05 +0000 Subject: Re: HFSC not working as expected Message-Id: <53B96C6D.2050403@yescomputersolutions.com> List-Id: References: <53AC30A8.2080403@yescomputersolutions.com> In-Reply-To: <53AC30A8.2080403@yescomputersolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Hi, Once again many thanks for your informative response. On 06/07/14 02:18, Michal Soltys wrote: > On 2014-07-03 02:56, Alan Goodman wrote: >> >> Its a BT Business Hub 3, which I think is made by Huawei. Im not sure of >> the technical underpinnings of how a router in bridgemode operates >> beyond I set it to bridge mode and connect it to a device that does >> PPPoE and it 'just works'. > > Hmmm, maybe the isp handles both pppoa and pppoe ? Yeah, on further investigation it seems the ISP (BT Business) supports=20 both PPPoA and PPPoE. As is clear I am using PPPoE. >> Do you have any examples (or links to correct examples online) of a good >> method of utilising 'tc-stab' ? I have looked at the documentation and >> am feeling a little overwhelmed at the moment! >> > > tc-stab essentially answers "what is the real length of packet being=20 > sent ? (later)". ATM cells are always 53 bytes long with 48 bytes=20 > payload - so the data send is divided in 48 byte packs, some=20 > atm/ethernert/ppp specific info (overhead) and padded to fit into 48*n=20 > size. > > Assuming your link is actualle pppoe, the overhead would be 32 (vcmux)=20 > or 40 (llc) with 'linklayer atm' option. Then you can use the speed at=20 > which modem synchronizes (or well a tiny bit less to compensate for=20 > small variations) when using tc. Thanks for your clear explanation here. I added 'stab overhead 40 linklayer atm' to my root qdisc line since I=20 am confident my connection uses LLC multiplexing. This transformed the=20 hfsc based shaper to being the most accurate I have so far experienced. =20 I am able to set tc upload limit by the sync speed, and tc downstream by=20 the sync minus 12% which accounts for some rate limiting BT do on all=20 lines (they limit downstream to 88.2% of sync rate). This works great in almost every test case except 'excessive p2p'. As a=20 test I configured a 9mbit RATE and upper limit m2 10mbit on my bulk=20 class. I then started downloading a CentOS torrent with very high=20 maximum connection limit set. I see 10mbit coming in on my ppp0=20 interface however latency in my priority queue (sc umax 1412b dmax 20ms=20 rate 460kbit) however my priority queue roundtrip is hitting 100+ms. =20 Below is a clip from a ping session which shows what happens when I=20 pause the torrent download. 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=179 ttlT=20 time=128 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=180 ttlT=20 time=152 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=181 ttlT=20 time=137 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=182 ttlT=20 time=134 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=183 ttlT=20 time=133 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=184 ttlT=20 time=106 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=185 ttlT=20 time=105 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=186 ttlT=20 time=144 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=187 ttlT=20 time=127 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=188 ttlT=20 time=96.0 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=189 ttlT=20 time!.8 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=190 ttlT=20 time=16.8 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=191 ttlT=20 time=17.9 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=192 ttlT=20 time=17.8 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=193 ttlT=20 time=17.9 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=194 ttlT=20 time=16.9 ms 64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=195 ttlT=20 time=16.9 ms Is it possible to iron this out, or is my unusual extreme test just too=20 much? Many thanks, Alan