Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections

[Dave Taht <dave.taht@gmail.com>]

We'd had a very long thread on cerowrt-devel and in the end sebastian
(I think) had developed some scripts to exaustively (it took hours)
derive the right encapsulation frame size on a link. I can't find the
relevant link right now, ccing that list...

On Sat, Sep 20, 2014 at 7:17 PM, Andy Furniss <adf.lists@gmail.com> 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