Re: HFSC not working as expected

[Alan Goodman <notifications@yescomputersolutions.com>]

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 
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 
> sent ? (later)". ATM cells are always 53 bytes long with 48 bytes 
> payload - so the data send is divided in 48 byte packs, some 
> atm/ethernert/ppp specific info (overhead) and padded to fit into 48*n 
> size.
>
> Assuming your link is actualle pppoe, the overhead would be 32 (vcmux) 
> or 40 (llc) with 'linklayer atm' option. Then you can use the speed at 
> which modem synchronizes (or well a tiny bit less to compensate for 
> 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 
am confident my connection uses LLC multiplexing.  This transformed the 
hfsc based shaper to being the most accurate I have so far experienced.  
I am able to set tc upload limit by the sync speed, and tc downstream by 
the sync minus 12% which accounts for some rate limiting BT do on all 
lines (they limit downstream to 88.2% of sync rate).

This works great in almost every test case except 'excessive p2p'. As a 
test I configured a 9mbit RATE and upper limit m2 10mbit on my bulk 
class.  I then started downloading a CentOS torrent with very high 
maximum connection limit set.  I see 10mbit coming in on my ppp0 
interface however latency in my priority queue (sc umax 1412b dmax 20ms 
rate 460kbit) however my priority queue roundtrip is hitting 100+ms.  
Below is a clip from a ping session which shows what happens when I 
pause the torrent download.

64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x179 ttlT 
time\x128 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x180 ttlT 
time\x152 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x181 ttlT 
time\x137 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x182 ttlT 
time\x134 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x183 ttlT 
time\x133 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x184 ttlT 
time\x106 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x185 ttlT 
time\x105 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x186 ttlT 
time\x144 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x187 ttlT 
time\x127 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x188 ttlT 
time–.0 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x189 ttlT 
time!.8 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x190 ttlT 
time\x16.8 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x191 ttlT 
time\x17.9 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x192 ttlT 
time\x17.8 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x193 ttlT 
time\x17.9 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x194 ttlT 
time\x16.9 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq\x195 ttlT 
time\x16.9 ms

Is it possible to iron this out, or is my unusual extreme test just too 
much?

Many thanks,

Alan