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=179 ttl=54
time=128 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=180 ttl=54
time=152 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=181 ttl=54
time=137 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=182 ttl=54
time=134 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=183 ttl=54
time=133 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=184 ttl=54
time=106 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=185 ttl=54
time=105 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=186 ttl=54
time=144 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=187 ttl=54
time=127 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=188 ttl=54
time=96.0 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=189 ttl=54
time=21.8 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=190 ttl=54
time=16.8 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=191 ttl=54
time=17.9 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=192 ttl=54
time=17.8 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=193 ttl=54
time=17.9 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=194 ttl=54
time=16.9 ms
64 bytes from ha01.multiplay.co.uk (85.236.96.26): icmp_seq=195 ttl=54
time=16.9 ms
Is it possible to iron this out, or is my unusual extreme test just too
much?
Many thanks,
Alan
--
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
