Ric, What follows is a *gross* oversimplification that glosses over some of the finer details...and it's a long answer to a short question. But in general, the higher the latency, the slower the measured TCP throughput. Reasonable good transfer rates even in the face of high latency are still possible, but only if the adjustments are made to TCP window/buffer size. For a relatively fast network like HamWAN, 80ms rtt delay has a noticeable negative effect on throughput. If you are able to reduce latency, then throughput increases, all other things being equal. High latency makes it challenging to take advantage of the raw speed of an otherwise fast network. It's sort of like driving a Ferrari that needs to make a pit stop every 1,000 ft. -- it's hard to get very far, very fast. I saw "Ford versus Ferrari" last night, so forgive the metaphor... A factor in play here is called BDP or Bandwidth Delay Product. BDP is the amount of data that can be "in transit" at any time on the network. BDP is calculated as Bandwidth times round trip time. The reason BDP is significant is that as it goes up, the demand on TCP window/buffer space goes up--and computers these days don't always do a real good job of adjusting to this. When they don't, throughput suffers, sometimes badly. There's a handy tool you can use to predict throughput and BDP of networks at: https://www.switch.ch/network/tools/tcp_throughput/ For example, using this tool and plugging in the values from your post of approx 50Mbps and approx 80ms rtt, and assuming a Windows 10 computer with starting value of 64KByte TCP window size, the best you would be able to achieve is 6.5Mbps or so. If your TCP window size was 32Kbytes, then your throughput would drop to around 3.3 Mbps. The tool has another interesting output: It tells you how large your TCP window must be in order to achieve the full 50Mbps transfer rate, given the latency (rtt) you indicate. In this case, it's 488KBytes, which is far bigger than the 64KByte TCP window size that Windows allocates initially for fast (1GB or 10GB) connections. Here's an interesting bit of trivia: Unless told otherwise, Windows will choose an initial TCP receive window size based on the speed of the interface you are plugged into, and it does so in a rather stingy manner. So if your laptop is connected to an older 10Mbps switch, then Windows 10 is likely choosing a feeble 17Kbyte TCP window size. Windows is set by default to increase the TCP windows size to respond to needs, but it can be told to do so more aggressively. Other than reducing and stabilizing network latency, bumping up the TCP window size (using whatever means) is one of the only "knobs" that can be turned to boost throughput on a "fat" network (i.e. Fast, but high latency). Modern operating systems like Windows and Linux have implemented a technique called "scaling" of the TCP window, which chooses a larger TCP window size (potentially higher than 64KBps) during TCP handshake at the start of a TCP session. The stock settings for scaling up the size of the TCP window don't perform well however when the latency changes significantly (a.k.a. "jitters") unpredictably. In my spare time I've doing some testing with two linux hosts (and two Windows 10 computers also) on two different HamWAN connections, one on Gold Mt, and one on Triangle Mt, to see what effect various system settings make on the effective management of TCP window size--the intent being to maximize throughput. Windows 10 also has a variety of settings and adaptive algorithms that can be activated and adjusted in an attempt to make it more adaptive to jitter prone networks such as HamWAN. Settings on Linux like minimum TCP socket buffer sizes (irrespective of system load), minimum default TCP send and receive buffer size can potentially improve the baseline performance of systems in terms of throughput. All versions of Windows 10 have had taken away some of the TCP tuning settings that used to be available through Windows registry tweaks, but now are only available in Windows Server 2019. Shame on you Microsoft! But there are other new Windows 10 TCP knobs to tweak, such as new congestion control algorithms like CTCP (Compound TCP) which promise to increase throughput and reduce packet loss on higher latency broadband networks by monitoring latency variations, and aggressively growing the TCP window. We'll see. I still have a fair bit of testing and experimenting to do, but I plan to share findings with the group, focusing on Windows 10 and Linux settings. John KX7JM ---- On Fri, 22 Nov 2019 21:11:03 -0800 Ric Merry <mailto:ricmerry@gmail.com> wrote ---- I added a switch today and did some subsequent speed testingOn speed web sites I'm getting <Mbps down and about 3 Mbps up with a latency around 80 ms. Seems awfully slow, am I fooling myself here? _______________________________________________ PSDR mailing list mailto:PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr