Affect on speeds of the Plusnet profile

[#1]

I have a question.
If the customer can set their home gateway MTU value to anything they like (up to 1500 on PPPoA), this potentially means the PPP frame could contain anything from zero padding to whatever the worst case value is.
Does the 88.2% value assume that MTU is set to give optimal throughput (i.e. zero padding) - in which case downloads should occur at profile speeds for home gateways set to ideal MTU values such as 1430 or 1478, at the risk of the ISP sending too much data to the exchange if the MTU causes the frame to contain padding.
Or does the 88.2% limit throughput for connections as if they had the worst case padding, so as not to send too much data to the exchange in case the home gateway MTU is not configured to an optimum value ?, and therefore connections with optimal MTU will never achieve profile speeds because the percentage is too low.
I'm sorry if this makes no sense, because I've had more than a drink or two  , but I think my question is valid.
Unfortunately I'm too far gone to even consider trying to do the maths 

@'ejs' - have you optimized your MTU, and checked for zero padding using a tool such as DSLReports : Tweak Test ?

[#2]

Which part of that tweak test tool do you imagine checks for zero padding of ATM cells? Fiddling with the MTU makes no difference to the transfer efficiency reported by that tool. That tweak test is going to have no idea if your packets are being chopped up and stuffed into ATM cells or not unless you tell it so by choosing pppoa after the test. I think I got a transfer efficiency reported as 93% or 94% regardless of a MTU of 1478 or 1500 because there were a few packets lost reported during the each test I did just now. I expect if I had zero packet loss during a test it would report 100% transfer efficiency regardless of MTU setting.
The vast majority of the overhead that the 88.2% IP profile allows for is the 5 byte ATM cell header, 48/53 = 0.906.
I did try a MTU of 1478 but found it made very little difference last time I checked, so all the above tests were done with a MTU of 1500.

[#3]

@purleigh

Re what you asked in reply #15 I've deferred that question to someone who should be able to get us an accurate answer. We'll get back to you ASAP.

[#4]

On further consideration, for 21CN at least, it may be that the impact of the Plusnet profile is the reason why a MTU of 1478 makes no difference (or even makes things slightly worse, smaller packets, more packets, more TCP/IP headers) compared to 1500.
Based on this, I'll try to represent the protocols as:
[tt]    PPPoA over ADSL          PPPoE                PPP over L2TP over IP (over E?)
Me <------------------ MSAN <-------- MSE / BRAS <---------------------------------- Plusnet
[/tt]
For 21CN, the only section that involves ATM cells is the ADSL link between the end user and the exchange. If Plusnet send packets towards the MSAN slower than what the line is capable of, it doesn't matter if the MSAN has to pad some of the ATM cells with zeroes, because the bandwidth of this section isn't being fully utilised anyway.

[#5]

I suspected the ancient dslreports tweak test java applet wasn't working well with Linux default TCP window scaling.
default:
[tt]# cat /proc/sys/net/ipv4/tcp_adv_win_scale
1
# cat /proc/sys/net/ipv4/tcp_window_scaling
1
# cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 6291456[/tt]
disable tcp window scaling and increase rwin (could not be bothered to calculate some exact supposedly perfect value:
[tt]# echo 0 > /proc/sys/net/ipv4/tcp_adv_win_scale
# echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
# echo "40960 873800 6291456" > /proc/sys/net/ipv4/tcp_rmem[/tt]
Result: zero retransmissions and 100% transfer efficiency reported by tweak test tool, with 1500 MTU.

---

Anyway, it should be fairly straightforward to test if the profile speed discrepancy is due to rounding down and then subtracting 100k. All it needs is for a couple of other people, preferably on 21CN ADSL, with different profile speeds (higher or lower) than mine of 3.5, to do some speed measurements. Just download a fairly large file, that takes at least 5 minutes to download, and watch the download to ensure it runs at full speed the whole time. Results needed:
1. IP profile
2. File size in bytes
3. Time taken to download
4. MTU if you've decreased it, or I'll just assume the default MTU of 1500 and MSS of 1460
Or someone from Plusnet could just confirm or deny that the profile is rounded down to the nearest 100k and then has another 100k subtracted (just to make double extra sure that too much data never ever gets sent down your line, of course).

[#6]

We round down to the nearest 100kbps if the speed is below 21000kbps and down to the nearest 200kbps if it's above that rate.

[#7]

Thanks for that, but I think we already knew that.
What do you think of the Plusnet profile of 3.5 having a throughput (including TCP and IP headers) of 3.4, and a profile of 3.2 having a throughput of 3.1? Just a coincidence, or is entirely expected that the throughput is always equal to 100k less than the stated Plusnet profile?
Is the "rounding down to the nearest 100k" done by rounding the profile down to the nearest 100k and then subtracting another 100k?

[#8]

No, it just rounds down to the nearest 100kbps below. So for example:
Line is sync'd at 3720kbps (ADSL2+)
BTW profile should be calculated as 3281kbps and this is passed on to Plusnet
Plusnet set the speed profile on the account at 3200kbps (which you can see in the member centre) and on the network at 3200kbps.

[#9]

I can see this thread will continue to go nowhere slowly.
How do you explain the results then? It's still 100k less after allowing for the profile rounding down.

[#10]

In the example above 3200kbps is the shaper rate on our network, 3281kbps is a policer on the BTW BRAS/MSE. These have different behaviour configured depending on the traffic going through.
On the Plusnet shaper if rate of traffic coming from the Internet to the subscriber is higher than the profile packets will be buffered, the order of the buffering is dictated by the priority of the traffic. If all traffic is in the same queue (e.g. all gold) then it will all go into the buffer, if there are multiple queues (e.g. titanium and gold) then as long as the amount if traffic in the higher queue is less than the weighting of that traffic for the shaper rate only the lower priority traffic will go in the queue.
So far example you run a speedtest and nothing else the data rate comes down at slightly above 3200kbps we will buffer some of the data.
If you run a speedtest and have ping running, the ping won't be buffered but the speedtest will.
The buffer size is quite small so the most it will add to the latency is a fraction of a second. Once the buffer reaches the maximum then packets will get tail dropped. Whenever we've tested this we've seen TCP back off the data rate just enough for the buffer to start to dequeue.
If you hit the BT policer though the behaviour is different, as soon as you hit it packets will get dropped randomly. So if you were doing ping and a speedtest at the same time there's a change it could drop either type of traffic.
It's this behaviour difference that we think is the main difference between the speedtest results. Even though the buffer size is small it's possible that a packet could sit in the buffer longer than it takes for TCP to send and receive a retransmission which ends up with the speedtest reporting a slightly lower throughput rate.
Overall we think that having the shaper and the way it behaves gives a better experience. If one person is downloading via P2P in the household and another watching YouTube we think people would rather have YouTube buffer free than a faster download.

[#11]

I wasn't disputing the wonders of your traffic management system, but since you insist on bringing it up: web browsing, watching news videos on the BBC website, watching videos on Youtube, flash (RTMP) streaming, downloading a 964MB Linux ISO over http - these are all classified exactly the same, gold, making the whole thing a bit of a farce and really not as great as what you keep claiming. But you've got to make those TBB ping graphs look good at all costs!

[#12]

Quote from: ejs

web browsing, watching news videos on the BBC website, watching videos on Youtube, flash (RTMP) streaming, downloading a 964MB Linux ISO over http

To be fair, watching news videos on the BBC/videos on Youtube/RTMP streaming are essentially the same thing anyway.

[#13]

Listening live to a local community radio station was also classified as gold.
To be even clearer, it's not a speedtest merely reporting a lower rate, the rate is actually lower.

[#14]

Just talking to Dave to try and get my head around it.  Effectively, you are downloading 100kb slower than your PN Profile because that is the time it takes to fill and dequeue the buffer.  It's a loss in performance if you've maxed your line with one sort of traffic all in the same queue over straight tcp retransmits, but improved performance if you are maxing your line with a mix of traffic types, which is specifically the experience we are trying to look after.

[#15]

I took the opportunity to measure the speeds of some slightly different profiles and line rates.
13 Jan 2015 08:18

PN profile: 3.7
Limited by PN profile: no
DSL Line rate: 3824                  BT Profile = 3.37  Mbit/s
throughput 400KiB/s - 191146160 bytes in 7m 47s = 3.274 Mbit/s
IP layer:             196383080 bytes in 7m 47s = 3.364 Mbit/s

15 Jan 2015 07:44 was just a repeat with the same PN profile of 3.7 and DSL line rate of 3824

throughput 401KiB/s - 203467587 bytes in 8m 16s = 3.281 Mbit/s
IP layer:             209042067 bytes in 8m 16s = 3.371 Mbit/s

18 Jan 2015 08:07

PN profile: 3.7
Limited by PN profile: yes
DSL Line rate: 4315                  BT Profile = 3.8   Mbit/s
throughput 425KiB/s - 203471788 bytes in 7m 48s = 3.478 Mbit/s
IP layer:             209046388 bytes in 7m 48s = 3.573 Mbit/s