Poor single thread performance fixed.

I've been with Zen for something like 10 years, and recently (November) upgraded to FTTC (from ADSL). Inevitably I did a number of speed tests after the fibre was activated and, being very close to the cabinet (about 20 metres), I was seeing overall download speed of around 75Mbps, and have done since. I did notice that the single thread part of the test was around 30Mbps but thought nothing of it, just thought that was to be expected. 'Logic' being that a single thread is always going to be slower then the HTTP x6 one.

My download speeds, in real life, have been okay - often seeing around 8.5 MB/s when downloading large file etc.

It was only when doing another speed test that I noticed one of the thread titles in the 'Latest 10 active forum discussions', this being spudgun's 'Poor single thread performance' thread.

After reading through it all I came to realise that what I was experiencing maybe wasn't normal, so I rang Zen Support, who I've always found efficient, and explained the situation and referring examples of people's experience in that thread, plus that one of their engineers (JonGreen) had posted in the thread as being aware of the issue. The support guy said that as far as he was aware the issue that may have affected people had been resolved a little while back. We went through some speed tests (same results as I'd always had) but as my router wasn't plugged into the master socket (on an extension) he wanted me to do a test in that (which meant I'd be cut off the phone) so he left me to do that as and when and call back with the results. I did, and the speed tests were the same, but I decided to PM Jon Green on here just to see if there was anything on his side that he was aware of, given his familiarity with the issue.

He promptly replied and said he would have a look into it. The following day I had another update to say that my exchange was actually due to have some work done on it this evening (by Zen) which should resolve the single thread issues I was having. I should expect to see an improvement around 10pm tonight.

They obviously finished the work earlier as I did a speed test a short while ago and the single thread speed test has jumped from being around 30Mbps to around 63/64Mbps!, quite a significant increase. So thanks Zen, particularly Jon Green, for resolving this for me and to spudgun, as without your thread I would have been none the wiser of the relevance of my single thread speed tests.

On that note, can someone explain exactly what the significance is of the single thread speed? I always had around 75Mbps overall speed, on the HTTP x6 part, so thought all was good. Is it a case that not all sites/servers can connect on multiple threads?, so downloading from some sites would be slower if the single thread speed is slower?

I downloaded an Nvidia driver this afternoon (around 380Mb) and noticed that it was only downloading at around 3 MB/s, but when I downloaded it again a moment ago (post exchange work) it zipped along at 8.5MB/s. Yet in the past I've seen downloads of around that same speed (8.5MB/s) yet my single thread speed was around 30Mbps then, so I'm just unclear as to what the impact is on and real life usage with a much slower/reduced single thread speed compared to the multiple HTTP x6 speed?

Edited by LightFantastic (Wed 25-Jan-17 22:02:53)

A lot depends on the way the file is being downloaded, single thread is a good test for looking at video streaming performance

The test itself if using flash is a single download over a socket, if the newer flash test its a single file download in the browser

The significance of the single thread speed is that is the way most (but not all) protocols work. For example, a video stream. Typically (to keep it simple) the media player on your computer, or tablet, or smart TV will have opened one stream for the content and it will be delivered as one continuous stream of video data, albeit with a local buffer so you don't see any interruptions if the stream glitches. The same thing is true of most regular downloads. The client machine asks for the data and it is delivered as one continuous stream.

In contrast, some protocols allow for multiple parallel streams to be established. For example, a web page will often contain dozens, sometimes hundreds, of different elements, some from the same server but others from different ones. Rather than waiting for each element (like a picture, of a block of text) to be loaded one after another, the browser will download several in parallel.

The assembly of web pages naturally lend themselves to this as they are so often made from many different elements. Downloads of things like large files are a different matter. They aren't naturally broken into parts and to do so requires a specially defined protocol which essentially splits the files into parts and downloads those parts independently with the client computer reassembling them later. Protocols like bittorrent do this and even go a bit further; they can download different parts of the files from different locations so even if the upload bandwidth of each of those locations is limited, the combination will be much higher.

The reason why the single thread vs multiple thread test is interesting from a network point of view is due to the way that TCP handles contention (not everything over IP uses TCP, but it's the majority). Contention management in TCP only works on each individual stream and it works on an end-to-end basis (ignore ISP traffic shaping - that's another issue). If the TCP protocol detects contention (typically by packet losses/delays), then it will slow the rate of transmission. That's because the TCP flow control is designed on a "good neighbour" basis. All streams are considered equal so all ought to back off equally to be fair. If it was otherwise, and they just tried harder when contention was detected, then things would rapidly get worse.

Multi-streaming protocols (at their worst) can disrupt this model. Imagine you are downloading a single stream at the maximum rate your line can sustain (let's say 60mbps). Then imagine somebody else is downloading another large file using 6 streams but has the same maximum line speed (60mbps). That means they will have 6 streams each of 10mbps. Fair enough, everybody is happy. Now imagine congestion kicks and that only 20mbps per stream can be maintained. Then your single stream will be running at 20mbps yet the multi-threaded downloader will still be getting 6 x 10mbps. So you are only getting one-third of the bandwidth of your multi-threading network neighbour.

Draw that picture over many tens, hundreds, or thousands who might be sharing elements of the network, then the same picture emerges. Because of the way TCP flow control works the effects can even be much worse than the example I've given. In extremes, the throughput can be cut by much larger factors as multi-threads crowd out the single threads. With bittorents it can amount to hundreds of streams.

Multithreading has its place, but when abused, it can be a major menace as it subverts the "good neighbour" basis on which the TCP end-to-end flow control mechanism was based.

Edited by deleted (Thu 26-Jan-17 14:10:32)

Thank you for that lucid explanation.

Been looking for something like that for a long time.

In reply to a post by MrSaffron:

A lot depends on the way the file is being downloaded, single thread is a good test for looking at video streaming performance

Right, thanks. So my jump in single thread speed has made the difference from being borderline/just about manageable for 4K streaming to being well covered - not that I currently have any 4K streaming services!, but in time I'm sure I will.

TheEulerID - thank you for such a detailed an informative post. That really explains it and I now understand the whole significance of the single thread speed tests. Thanks again.

indeed, and bittorent is not alone either.

both battle.net and steam downloaders use many streams as well and as such abuse the good neighbour motto of TCP.

Further speed tests since my last post are showing the single thread speeds to be still averaging around 65Mbps, the odd one dropping to around 60, the odd on just shy of 70 - with the multiple thread remaining consistent at around 75Mbps.

In an ideal world the single thread speed should be pretty much the same as the multiple, but we don't live in an ideal world! I don't know what other people are getting on their services in terms of how close single thread speed is to multiple thread speed. Is what I've got pretty good and a case of being happy with, or should I be looking at contacting Zen Tech Support again?

I had some further PM correspondence with Jon Green as I'd noticed the single thread had dropped a bit after I first started this thread. He replied...

"I've double checked, and the config change has been successfully applied. I've checked the utilisation on the link between our Exchange PoP and the street cabinets in your area (Openreach GEA Cablelink), and can confirm it is very low, and not causing congestion. I've also checked the utilisation on our backhaul link from your exchange into our central PoP, which is also very low, and not causing congestion."

..and as above I'm seeing an average of 65Mbps single thread and 75Mbps multiple in the most recent tests.

Obviously there are other potential reasons for the difference - the behaviour/performance of the router itself being one. I have the ZyXEL VMG8924-B10A supplied by Zen. Without having another one to hand I can't do any tests/comparison.

I'm not hell bent on getting that extra 10 or so Mbps on the single thread!, so I'm not going to start getting into the extra costs and faff of buying other routers. When I first contacted Zen they did say that being sent another router to try was an option. Although this was when I was getting the 30Mbps single thread and they (tech support I spoke to) were of the understanding that the network issues had been resolved some time in the past, so is it worth trying another of the same ZyXEL routers?, or am I likely to just get the same result?

Edited by LightFantastic (Mon 30-Jan-17 14:17:30)

I suspect that 65mbps is not low enough on single thread to be considered a fault. As far as single thread vs multiple thread goes, then I never see more than a small difference - perhaps 5% - in a BT Infinity link, but then I'm only on Infinity 1 (55mbps nominal).

I suppose the obvious thing is to say if it isn't causing you a problem, then don't worry too much about it, but do keep and eye on it. Andrew publishes single vs multithreaded results by ISP from time to time. The most recent was in the December speed results, although the table wasn't comprehensive enough to show a large number of ISPs (and not ZEN). I think differences between single and multi-threads varied from a very few percent up to about 25% on the median values, although that will have hidden a lot of regional variation for any one ISP.

As far as equipment is concerned and wired connections then I would have thought that the hub or modem/hub combination would not be that significant at those sort of speeds. However, WiFi is another matter - there are serious differences there.

In reply to a post by TheEulerID:

I suppose the obvious thing is to say if it isn't causing you a problem, then don't worry too much about it, but do keep and eye on it.

Yep, exactly - and it's not causing me any problem that I'm aware of, just something to monitor. It's certainly a big jump, post exchange work, from the 30Mbps that I was seeing initially, so I'm basically happy.

In reply to a post by TheEulerID:

As far as equipment is concerned and wired connections then I would have thought that the hub or modem/hub combination would not be that significant at those sort of speeds. However, WiFi is another matter - there are serious differences there.

Right, probably not worth pursuing with Zen then (a router swap). Regarding Wi-Fi - yes, of course. I'm getting slower speeds on Wi-Fi, but that's obviously to be expected.

it could be an RWIN issue if it happens 24/7 not just at peak.

But either way a single threaded performance you are getting is fine, just personally would annoy me wondering why it is slower as I am a perfectionist at times but its not experience breaking at that level.