Internet > General Internet
Tuning of downstream rates
Weaver:
In another thread I talked about how sensitive upstream speed tester numbers have become in respect of changes in the egress (upstream) rates set in my Firebrick.
I am now seeing the same thing I think with Amazon downloads and the indidual download rates that I can set using AA’s clueless.aa.net.uk control panel server.
I have had a lot of trouble if the rates are set too high, with something like 4-6Mbps TCP payload rate downstream instead of 10Mbps. I reduced some of the rates on the fastest lines to 99% or 975 tried various figures and got the throughput way back up, to something like 8Mbps. However unless I am really careful with the tuning I doubt I shall get any better download rate with Amazon and four links compared to with three links in parallel. I am assuming this could be because Amazon uses just a single TCP connection. I get the feeling that Netflix uses four TCP connections in parallel, although I cannot say for sure without looking at a traffic capture of it.
Netflix on the other hand indicates that it is downloading four episodes at the same time, but this could just be suggestive, it does not guarantee that there are four TCP connections in parallel. Although not doing so would make the whole four-episode thing rather pointless, indeed it might make the io bad if it has to be seeking all the time on mechanical media, but assuming sanity you really would think they would want to keep things really easy and get the performance benefit of doing four TCP connections in parallel.
jelv:
When you run the thinkbroadband speed test is there a big difference between the x1 and x6 downloads?
Weaver:
A few tests:
downstream: 9.3; Tbbx1: 7.7; bursting: 9.9 | Upstream 1.4; bursting 1.7
downstream: 9.3; Tbbx1: 8.8; bursting: 9.8 | Upstream 1.4; bursting 1.6
downstream: 9.3; Tbbx1: 6.6; bursting: 9.8 | Upstream 1.4; bursting 1.6
—
Using the straight IPv4 test file download time to download 100MB file gave:
TCP payload throughput = 8.08Mbps.
This comes to an IP PDU throughput (if IPv4 without timestamps) = 8.3 Mbps, or
if it was with timestamps = 8.37 Mbps.
The first would equate to 9.38 Mbps downstream sync rate and the second to 9.46 MBps sync rate.
Weaver:
A bit of further tuning and it seems that setting a downstream rate of 96% of 0.884434 of sync rate is the best for performance, according to the AA speedtester, at least. The 0.884434 figure = 1500 / ( 32 * 53 ) is for ATM 32 ATM cells, assuming in my case PPPoEoA rfc2684 VC-MUX with 32 bytes of one-off overhead per packet on top of a 1500 byte IP PDU and then the ATM per-cell bloat.
Increasing the rate above 96% seems to have a negative effect. A bit surprising to me. I just thought it would hit a wall and there would be no improvement, not a reduction in performance.
With those settings the AA speedtester gives a reading of ~9.8 Mbps downstream, occasionally nearly 10Mbps, and 1.53Mbps upstream - whatever that is supposed to be a measure of - it could be claimed to be maybe TCP payload, or maybe IP PDU rate.
Perhaps somehow those figures that I am getting for sync rate are a bit optimistic, or I have forgotten some other overheads or something, but it really seems as if perhaps the 0.88 limit is higher than the reality possible, or the sync rate quoted is too high.
Or maybe there is something else going on that is concerned with optimising the effect of interactions with the behaviour of TCP, or the behaviour of the speedtester.
Other practical tests: IP PDU rate when doing downloads from Amazon is 9.6-9.8 Mbps very roughly, so superb. The benefit here in getting the additional line is quite startling.
Sometimes Netflix goes very fast indeed when downloading a series of 45 min programmes but on other occasions for reasons that are unclear Netflix IP PDU rate can be up and down, dropping as low as 6 Mbps then up to 8 or 9 Mbps and basically all over the place sometimes so don’t know what they are up to but it does rather seems they have certain problems. How hard is it to simply download a file? I thought we had this one sorted about 40 years ago. They seem to keep introducing bugs then fixing them and then going round the cycle again. Netflix need to have a change freeze while they just observe, measure and test, and then they either carefully fix core bugs, or else get ruthless, throwing bad code out and replacing it from scratch.
Weaver:
Netflix again really awful, with IP PDU rates going up and down, from 1.8 Mbps up and down to 2.4Mbps per line. Suggests crazy retransmissions due to either stupid packet dropping or else due to out-of-order handling idiocy.
have discovered that increasing the downstream rate factor from 0.96 to 0.98 completely stabilises everything, with each link maxed out staying constantly where it should be, with IP PDU at 2.6Mbps on the faster lines and 2.4Mbps on the slower lines but no time variation.
So despite the AA speedtester’s 0.96-is-best result, we stick with 0.98 as real world performance is what counts, not the figures reported by artificial speedtesters, with their choices of implementation and presentation, and their quirks.
It remains to be seen what an Amazon download will be like with the 0.98 higher rate; can just hope that it is ok with that too.
Navigation
[0] Message Index
[#] Next page
Go to full version