Print

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

[banger]

My setup with TTB is a Zyxel VMG-1312B10A connected to an Asus RT-AC68U router. My sync down is 69384kbps my speedtest is https://www.thinkbroadband.com/speedtest/1671422070721580955 61.9mbps as seen in the link. Why is my download roughly about 8mbps lower than sync. Have rebooted router and modem. Any ideas?

[dee.jay]

There are overheads associated with any connection - Some here will know better is it retx_low and high that makes the difference in that overhead?

I forget offhand, but there is a good reason for it and not an awful lot you can do about it if you are already in retx_low.

[tubaman]

Depending if you are on Retx-high or Retx-low you should get about 96% or 92% of the sync speed. If you are losing circa 10% then that suggests you are on Retx-high. You may be able to move it to Retx-low by capping your speed for a while to reduce errors but there's no guarantee it'll work or that your line will be able to sustain it.

[Alex Atkin UK]

I've been on fastpath most of the time and its always been more like 92%.

Even when I was on Digital Region at 99Mbit sync, real-world was only 90% and that was without PPPoE overheads.

You'll lose almost 4% to TCP/IP itself before all the other overheads you need over DSL.

[Weaver]

I would be happy to do the overhead calculations but others have pretty much already said it all. There are other variables, IPv4 vs IPv6, the latter being very slightly slower on large packets because the headers are bigger, but with small packets these overheads are very significant. With TCP there’s also the option of having added overhead in the form of ‘timestamps’ - 12 bytes appended to the TCP header which is used to improve TCP performance by allowing precise time measurement of the messages’ end-to-end transit time.

A much more significant thing can be the slowness inherent in some TCP connections either due to outdated TCP software in one end or the other, or problems with packet loss over the link including packet corruption which causes loss. Packet loss temporarily slows some versions of TCP down enormously and it takes a certain amount of time to recover to full speed. Some new software is much better in this respect. If you have problems somewhere between the two ends when you’re transferring stuff with TCP then this will usually ruin you speed.

Finally some speed testers are horrendously inaccurate, either because of bad design, intentional lying, or congestion, with too many users competing for the same links into the speed tester servers, or too many users overloading the servers themselves. The servers’ readings can be miles out in either direction, under- or over-reading. One server says my upstream is 20Mbps, when in fact it is about 1.65 Mbps upstream TCP payload throughput. So it’s vital to test with several different servers and I recommend testing in the small hours. Unless a server is known to be an exaggerating liar, then take the highest readings as that will usually be due to that server having the best path to/from your ISP. If your ISP has an on-network speed test server then that’s probably always the one to go for. If you have done the overheads arithmetic above, then you’ll be able to rule out impossible TCP throughput figures for your sync rates down/up, and will know when a server is an exaggerating liar. (The server won’t know anything about sync rates though. It will just be exaggerating for reasons best known to themselves.)