Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Upstream sync rates are currently: #1 570 kbps, #2 505 kbps, #3 445 kbps, #4 537 kbps

I get 1.37 Mbps upstream result from the thinkbroadband speedtest and speedtest2.aa.net.uk is roughly the same. I’m running the modems at 96.5% of the maximum ATM payload rate (that is, having reduced performance to allow for all ATM overheads including cell headers and protocol stack above.

I make that (bps) actual IP PDU ingress rates :
486482
431006
379798
458318

Total 1755604 IP PDUs (ie need to subtract an allowance for the IP headers and then also anything else as desired to get an IP payload or better TCP payload figure. I make that 1.67 Mbps TCP/IPv6 theoretical payload rate (TCP / IPv6 SDUs) with TCP timestamps assumed, which is the worst case, max overhead option.

So I am as usual losing quite a bit, from 1.67 Mbps to 1.37 Mbps TCP/IPv6 SDU rate. This is presumably due to the jitter, possible packet reordering for all I know and problems due to the fact that the speeds are so unequal.

I’m not getting the actual speed I used to out of these speed tests. I used to indeed get 1.5 - 1.6 Mbps numbers out of them.

I’m wondering about possibilities for tuning performance to see if I can get some of this 20% back as uploading photos and doing backups to the internet takes an age.

One problem, which has been mentioned before, is line 3 highly variable upstream rate. Depending on what time of day the modem trains up you can easily lose 100k. The SNR varies by nearly 5dB ! over the course of the day, with a sharp jump between high and low noise levels, and no smooth change from one level to the other. As it is right now, this is from when the modem synced up in the low noise (high SNRM) state and the upstream SNRM right now is about 1.9 dB [!] not 6dB, the target. That’s the only way this line gets this 445k sync rate, otherwise it would be ~350k instead. If we sync up in the other state the noise margin goes from its target of 6dB up to say ~10.5 dB in the low noise half of the day.

I’m wondering if I am pushing things too hard and slowing things down with upstream errors. I can soon post some detailed stats for line 3 or the whole lot if that will be helpful.

I need to do another actual performance test and see how it compares when I intentionally sacrifice some of the line 3 sync rate by training up at the wrong time of day, so I lose rate on that line, make the inter-line differences even worse, but possibly lose the errors associated with line 3 upstream if there even are any much. But could that possibly be anything other than a loss of performance? Unless errors are really bad that plan won’t gain back the effect of a 100k loss of sync rate plus the additional bad effect of higher inter-line difference (well, 80k when reduced down to take overheads out) on TCP.

I was doing better in the past, so I must be missing something, unless the error situation was not bad before and is indeed mucking things up now.

[d2d4j]

Hi

I hope you don’t mind as I could be wrong sorry, but I thought your lines were been investigated for issues

If so, I would not change anything

Many thanks

John

[Weaver]

Looking back at my notes and looking at previous sync rates and speed test results, in the past I was getting a TCP [?] speed test result of 1.6 Mbps say and now it’s only 1.28 Mbps from the same speed test. I have used four different speed tests and I’ve compared current upstream sync rates with those that used to be obtained. What seems to be going on is that the ratio of speed test result / sum-of-sync-rates seems to have gone down. I’ve lost around 20% somewhere.

Six months ago, I lost a lot of upstream sync rate when I changed modems. The ZyXEL VMG 1312-B10A modems that I am using now are 10 about 10% slower upstream than the DLink DSL 320B-Z1 devices I used before. This is a pain.

However the speed loss I am talking about is more recent, well after the change of modem models. And that ratio I referred to seems to be the culprit now.

What would reduce effective throughput like that? Say if sync rates do not change but speed test results worsen?

I’m thinking of things such as packet reordering, out-of-sequence, increased jitter, greater differences between the slowest and fastest lines. If the sum of sync rates stays the same but say one line is doing all the work while a slow line is not pulling its weight, what will the effect then be on the effective speed test figure as a fraction of the sum-of-sync-rates?

I uploaded a picture of the brown tabby cat Thomas to the imgbb web server and it took absolutely forever - like going back to dialup. Upload does seem to be truly awful.

[Weaver]

Just now I did an experiment.

1. The upstream rate limiters per line were set to the following (bps)
    450849
    428773
    377830
    448301
which in each case is 96% of the sync rate × 0.8844, which is my fudge factor accounting for protocol overheads.

In this scenario the Ookla speed tester gave an upstream speed figure of 1.28 Mbps.

2. Now just for the hell of it, I set all links to be the same as the slowest, so all were at 377830.

So now the Ookla speed tester read 1.06 Mbps.

Now the ratios are (1) 1.28 / 1705753 = 75.04% and (2) 1.06 / ( 377830 * 4 ) = 70.14%. So I get an extra 4.9% efficiency by allowing differing rates, and the speed tester figure goes up from 1.06 Mbps to 1.28 Mbps, so an extra 20.75% more speed by increasing the sum of the IP egress rates by 12.865%.

So it is not more efficient to level the speed rates.

Allowing for TCP and possibly TCP timestamps with IPv4 or IPv6 that means that about ~11-13% of TCP payload speed has gone astray somewhere in between theory and the speed tester. So that is not too bad.

However, I did get 1.4 Mbps speed tester results before and in September I recorded just over 1.6 Mbps, but I reckon that the lowest sync rate was better back then. Even so, I have lost between 9% and 20% performance somewhere.

[Weaver]

The upstream efficiency problem seems to have mysteriously gone away, according to the AA speedtester. This is despite the fact that currently line 3 is being slow as it’s in the bad-performance half of its day and its sync rate is lower than in the good half. Also line 3 is a lot lower than the other links and one might expect this to cause problems at least with some correspondent servers’ protocol stacks?

* Speed test results from AA speed tester http://speedtest2.aa.net.uk
    IPv4 tests: test #1 | test #2 | test #3 | test #4
    Download: 10.68 Mbps | 10.67 Mbps | 10.65 Mbps | 10.69 Mbps
    Upload:     1.51 Mbps | 1.45 Mbps | 1.51 Mbps | 1.51 Mbps
    Latency:    48.36 ms | 48.27 ms | 48.23 ms | 48.32 ms
    Jitter:        5.80 ms | 3.04 ms | 2.51 ms | 6.14 ms

* Ookla Speedtest iOS app:
    Downstream: 10.4 Mbps / Upstream: 1.6 Mbps
    ( best results, server: “HostYourNet”, Middlesbrough )

Right now the sync rates are :
    Link #1: down 3085 kbps, up 537 kbps
    Link #2: down 2982 kbps, up 525 kbps
    Link #3: down 3055 kbps, up 376 kbps
    Link #4: down 3220 kbps, up 550 kbps

Need to apply the following :
    * protocol efficiency factor = 0.8844339622642
    * chosen modem load factor = 97%
ie. the sync rate is multipled by each of these in turn.

So the chosen rate limiter values set in the Firebrick for the ATM rates are :
    Link #1: 460692
    Link #2: 450397
    Link #3: 322570
    Link #4: 471845

[Weaver]

Thinkbroadband hates me today, in IPv6 and in IPv4 both

This is IPv4:



One thing to notice there is the latency, which is huge, which shows that thinkbroadband is rubbish, because this test was done at 00:46 and so it’s hardly a busy time.


But one IPv6 test was ok on upstream (others were really bad on some downstream test types, and not great on upstream):

[Weaver]

After the latest bad joint has been fixed yesterday (Tue),  for some reason the upstream performance has been transformed. The upstream sync rate of line three 445kbps has not gone up (not significantly) so this is a mystery. In fact on one very rare occasion it was higher a while back.

The upstream good/bad daily cycle appears to still be present as the SNRM jumped up by 4dB - as usual - at around midnight. Now if this is some source of noise going on/off there is still the mystery of why other lines are not picking it up too. Anyway that would be independent of the bad joint, aside from the possibility of sensitivity to interference pickup, but anyway the bad joint can’t explain the daily cycle so it’s hardly surprising if fixing the joint doesn’t remove the odd cycle behaviour. It’s a bit soon to pronounce on this as all I have seen is one single up-step.

The speedtest2.aa.net.uk result has jumped up from 1.3 Mbps to 1.61 Mbps, which is about where it should be.

Thinkbroadband has gone from ~1.0 Mbps to ~1.6 Mbps too on IPv6 and IPv4 both.

* I just have no idea at all how this is even possible, as the upstream sync rate hasn’t improved much. Does anyone have any opinions?

This means an end to my whinging about upstream bonding efficiency being less than ideal, when compared with downstream. The predicted upstream maximum payload throughput for TCP+IPv6+timestamps is 1.732Mbps.

Just hoping that this improvement is sustained long-term.

Here are the thinkbroadband pretty pictures, IPv4 then IPv6:




In the above tests, the downstream is temporarily reduced because line 3 is being run at 6dB downstream target SNRM for the moment. The second test, with its lower downstream speed test value, is clearly bogus and is imho due to traffic spoiling the test, as other runs don’t agree with it.

[Weaver]

According to my soreadsheet, ~1.68 Mbps is the ideal expected for TCP+timestamps IPv6 payload throughput and so ~1.6Mbps might be realistic for TCP payload after subtracting some allowance for overhead related to bonding, especially four lines, lines with unmatched speeds, out-of-order packets and latency variation. That’s the most pessimistic TCP/IP overhead scenario, using IPv4 or no time stamps would of course give better payload throughput due to reduced overheads.

The only thing I could think of is that line 3 has been dropping upstream packets because of corruption. Perhaps this would happen at an upstream SNRM of 2.0 dB. The modem resyncs with a target of 6dB and then the conditions worsen as part of the good-half/bad-half of the day diurnal cycle where SNRM jumps down and up by 4dB every day. Then having been initialised at 6dB because the resync happened to be during the good half-day, the SNRM drops to 2dB during the bad half. However I tested this. Did a speed test with upstream SNRM of only 2.0dB and the upstream speed is the same, still excellent, at 1.66Mbps. So that’s ruled out.