![]() ![]() ![]() ![]() |
|
Happy to help. No idea why it reverted but you're about the 20th case of whom it has happened to - always the same problem, fine locally (eg - ACSData) however really rubbish the further away you get. Merry Christmas to you too!
Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)
Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.
Tcp/ip stacks are rather finicky things... Sadly Microsoft seems to make a point of taking a giant 💩 on it..
Depending on how your provider, LFC and the networks your packets transverse handle queuing, shaping etc the impact of this can be far greater.
Pays to always remember classical nature for tcp...
Sometimes I do wonder if its a ploy to release Windows 11 with faster networking!
edit: mobile never shows how big images are...
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
genegeney:
My apologies, seems it had reverted back for me too. Now I'm getting the right SpeedTest results for Auckland and Sydney. I really cannot fathom the logic - why was there no problem to a Wellington server? Surely that setting should've affected all my traffic? Pleased it's now working, but very confused!
My guess would be that Windows is not opening up the window size (number of packets transmitted before an ACK for one of them must be received) so that when the ping time is greater, it is spending most of its time waiting for an ACK before sending another packet. Linux TCP/IP stacks are very good at this, but apparently it is not done well by Windows TCP/IP stacks. So here in New Zealand where most international servers are a long way away and have big ping times, we are badly affected by this. People who live within 30 ms of most of their servers do not notice the problem as small window sizes are all they need. So in your case, a local Wellington server was only maybe 2-5 ms away if the packets did not have to go to Auckland. Getting to Auckland is probably around 10 ms, but Sydney is 30-35 ms or so. At nearly 1 gigabit/s, 35 ms is a lot of bytes, so a lot of packets need to be outstanding at any one time to use the full speed of the connection - 35 ms is over 4 Mbytes worth of packets.
This problem is why quite a few people use downloader software that runs multiple TCP streams at once - that way, even if each stream is waiting for ACKs most of the time, the total download speed can still approach the available connection speed even with small window sizes.
You could use Wireshark to see if a window size problem is was what was actually happening.
|
![]() ![]() ![]() ![]() |