@Mark07 Notice the TCP backoff- temporary speed drop - in the TCP upload. It’s presumably due to packet loss which is either natural - that is overfilling in routers that are intermediate nodes or packet loss due to corruption or badness. Whichever, the receiving end analyses what’s going on and always assumes that there’s a congestion problem in the network and that that is causing packet loss, so it slows down. This assumption, that a problem is congestion, is chosen to be one the safe side and protect the internet, even though the receiving o/s doesn’t really know exactly what’s going on. This temporary slowdown is a real damned nuisance as it takes time to recover cautiously to full speed and that really mucks up your download time. If your sending TCP implementation is too aggressive and sends way too much data, so that there’s no room to store it in all the intermediate routers or it overloads the receiving machine at the remote end, then you get penalised by the speed drop discussed before. It’s better to get the max speed right and get up to it quickly but accurately to the max rate but no more.
Sometimes with some speed testers I see a massive initial tx throughput peak, which only means that I’m filling up a huge capacity pipe, not actually getting all the data to the far end. Then the pipe becomes overloaded, a router drops packets and I get a big TCP speed drop, as discussed, which is bad news.
This is why speed testers should never test using TCP; they are testing a particular implementation of TCP’s behaviour, not the link and the ISP. A TCP test should be a secondary extra test, not a primary one.
