Best Regards Sebastian > > On Sat, Sep 20, 2014 at 7:17 PM, Andy Furniss wrote: >> 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 > > Hmm? sfq separates bulk from interactive pretty nicely. It tends to do > bad things to bulk as it doesn't manage queue length. > > A little bit of prioritization or deprioritization for some traffic is > helpful, but most traffic is hard to classify. > >> bufferbloat bit, you could make the default 128 limit lower if you wanted. > > htb + fq_codel, if available, is the right thing here.... > > http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die > >>> 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@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Dave Täht > > https://www.bufferbloat.net/projects/make-wifi-fast > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel