Alan Goodman wrote:
Hi, I am looking to figure out the most fool proof way to calculate stab overheads for ADSL/VDSL connections. ppp0 Link encap:Point-to-Point Protocol inet addr:81.149.38.69 P-t-P:81.139.160.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:17368223 errors:0 dropped:0 overruns:0 frame:0 TX packets:12040295 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:17420109286 (16.2 GiB) TX bytes:3611007028 (3.3 GiB) I am setting a longer txqueuelen as I am not currently using any fair queuing (buffer bloat issues with sfq)
Whatever is txqlen is on ppp there is likely some other buffer after it - the default can hurt with eg, htb as if you don't add qdiscs to classes it takes (last time I looked) its qlen from that. Sfq was only ever meant for bulk, so should really be in addition to some classification to separate interactive - I don't really get the bufferbloat bit, you could make the default 128 limit lower if you wanted.
The connection is a BT Infinity FTTC VDSL connection synced at 80mbit/20mbit. The modem is connected directly to the ethernet port on a server running a slightly tweaked HFSC setup that you folks helped me set up in July - back when I was on ADSL. I am still running pppoe I believe from my server.
I have similar since May 2013 and I still haven't got round to reading up on everything yet :-) I have extra geek score for using mini jumbos = running pppoe with mtu 1500 which works for me on plusnet. You need a recent pppd for this and a nic that works with mtu >= 1508. As for overheads, initial searching indicated that it's not easy or maybe even truly possible like adsl.
The largest ping packet that I can fit out onto the wire is 1464 bytes: # ping -c 2 -s 1464 -M do google.com PING google.com (31.55.166.216) 1464(1492) bytes of data. 1472 bytes from 31.55.166.216: icmp_seq=1 ttl=58 time=11.7 ms 1472 bytes from 31.55.166.216: icmp_seq=2 ttl=58 time=11.9 ms # ping -c 2 -s 1465 -M do google.com PING google.com (31.55.166.212) 1465(1493) bytes of data. From host81-149-38-69.in-addr.btopenworld.com (81.149.38.69) icmp_seq=1 Frag needed and DF set (mtu = 1492) From host81-149-38-69.in-addr.btopenworld.com (81.149.38.69) icmp_seq=1 Frag needed and DF set (mtu = 1492)
You can't work out your overheads like this. On slow uplink adsl it was possible with ping to infer the fixed part but you needed to send loads of pings increasing in size and plot the best time for each to make a stepped graph.
Based on this I believe overhead should be set to 28, however with 28 set as my overhead and hfsc ls m2 20000kbit ul m2 20000kbit I seem to be loosing about 1.5mbit of upload...
Even if you could do things perfectly I would back off a few kbit just to be safe. Timers may be different or there may be OAM/Reporting data going up, albeit rarely.
No traffic manager enabled: http://www.thinkbroadband.com/speedtest/results.html?id=141116089424883990118 HFSC traffic manager: http://www.thinkbroadband.com/speedtest/results.html?id=141116216621093133034 Am I calculating overhead incorrectly?
VDSL doesn't use ATM I think the PTM it uses is 64/65 - so don't specify atm with stab. Unfortunately stab doesn't do 64/65. As for the fixed part - I am not sure, but roughly starting with IP as that's what tc sees on ppp (as opposed to ip + 14 on eth) IP +8 for PPPOE +14 for ethertype and macs +4 because Openreach modem uses vlan +2 CRC ?? + "a few" 64/65 That's it for fixed - of course 64/65 adds another one for every 64 TBH I didn't get the precice detail from the spec and not having looked recently I can't remember. BT Sin 498 does give some of this info and a couple of examples of throughput for different frame sizes - but it's rounded to kbit which means I couldn't work out to the byte what the overheads were. Worse still VDSL can use link layer retransmits and the sin says that though currently (2013) not enabled, they would be in due course. I have no clue how these work. -- 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
