The other night we had a power cut over a large part of the island for an hour or so, two thousand households knocked out. When service was restored, I found that all of my modems’ upstream sync speeds had gone up, two of them dramatically so. The combined total measured upstream throughput was around 0.9 Mbps before, afterwards it was 1.34 Mbps, I make that 46%. One line improved its sync rate slightly, going from 510kbps up to 534kbps, but the other two went from ~400k each to 547k and 537kbps.
Any ideas why this sudden pleasing jump in sync rates should have happened?
The only thing I can think of is that a lot of neighbours’ kit had not come back on yet, perhaps all kinds of electrical items, not just DSL, so the neighbourhood had be electrically quieter. Can only pray that the improvement is sustained. The downstream speed hasn't changed much, whatever that means. Speculating, if we assume that the improvement is about reduced levels of low frequency noise, then that would be consistent with the idea that it’s mains equipment-related, as opposed to crosstalk and external RF from say radio stations
I'm using a Firebrick router to split the upstream load between the lines. I’m assuming that ATM overhead reduces upstream throughput so that it equals 87% of the sync rate quoted, and I've set the Firebrick to rate limit upstream to 99% of the 87% * sync_rate for each individual modem, slightly below 100% so that the Firebrick is control rather than the modems, if I've done my sums correctly. So according to my spreadsheet, we are achieving a TCP payload throughput (assuming that is what the speed tests are reporting, although they could have corrected for IP and TCP headers, to give a much more meaningful reported figure) that equals 96% of the combined 99%-rate-limited ATM payload rate.
To convert a speed test-reported modem throughput figure to something that I can meaningfully compare with ATM payload rates, I possibly have to adjust the speedtest-reported figure to account for overheads of TCP and IP headers, and I certainly have to adjust for overheads due to PPP + PPPoE + Ethernet + RFC2684 sec 5.2 + AAL5 trailers. Leaving aside TCP and IP for the moment, the PPP + PPPoEoA etc stack overhead of 44 bytes added to the ATM payload means an overhead of one extra ATM cell for a 1500 byte IP PDU, therefore that overhead alone accounts ~3%, so ~97% is the ideal maximum, which means that at 96% the Firebrick is doing a very good job.
However, before the power cut I never used to get such a high efficiency figure, so perhaps the Firebrick doesn't like a situation where lines differ greatly in their speeds, as one line used to be ~25% faster then the other two. Or alternatively, it could be a false result if the speed tester has improved somehow.