Hmm, an interesting ramble into stuff I wasn't talking about above the DOCSIS layer.

It is also interesting that you assert that these few milliseconds here and there have no real effect but I've yet to see a TBB test showing single-thread speed anywhere close to multi-thread speed, e.g. within 1%.

Maybe I'm wrong and DOCSIS isn't having an effect, unfortunately that would seem to imply the fault lies with TBB's test.

I have no idea what is causing the specific issues at the moment. My comments were intended to be more general and highlight the fact single-thread tests on cable never seem to get close to multi-thread tests and that the causes of a single single-thread test being bad can be many and several.

In reply to a post by Daemon66:

Hmm, an interesting ramble into stuff I wasn't talking about above the DOCSIS layer.

It is also interesting that you assert that these few milliseconds here and there have no real effect but I've yet to see a TBB test showing single-thread speed anywhere close to multi-thread speed, e.g. within 1%.

Maybe I'm wrong and DOCSIS isn't having an effect, unfortunately that would seem to imply the fault lies with TBB's test.

All these bar selective acknowledgement and ack suppression are part of DOCSIS.

Are you familiar with selective acknowledgement, DOCSIS scheduling, Payload Header Suppression, ack suppression and per-service flow upstream burst parameter/buffer configuration?

Ack suppression is incorporated into cable modems and has been since the mid-2000s to reduce upstream requirements. Selective acknowledgement, alongside cumulative acknowledgement, is what allows ack suppression to work.

Regrettably I can't test any of this out to try and find the root cause. I would expect the experience seen in the TBB test to mirror that of single threaded downloads.

EDIT: Reading my post back apart from those references to TCP functionality all the rest was pretty solidly DOCSIS and cable system implementation All MAC and PHY.

Edited by deleted (Fri 26-May-17 12:59:07)

Regrettably I can't test any of this out to try and find the root cause. I would expect the experience seen in the TBB test to mirror that of single threaded downloads.

I still cannot figure out why the TBB tester gives me such poor single threaded speeds but downloading the test files on TBB network with single thread connection gives me full speeds.

TBB test (~100mbps single thread):
https://www.thinkbroadband.com/_assets/speedtest/but...

TBB test file on single thread (>200mbps):
http://virgin.i.lithium.com/t5/image/serverpage/imag...

What could be the problem here?

I've just downloaded the 1GB file from TBB in 53.1 seconds, with an average speed of 160Mbps.

This ties in with the results given by testmy.net and dslreports:

http://testmy.net/db/VtPJI2cT7
http://www.dslreports.com/speedtest/13947144

However the TBB x1 test is only showing 60-84Mbps

https://www.thinkbroadband.com/_assets/speedtest/but...

It seems to be underestimating the single thread speeds, especially as test file downloads from TBB are so much faster. than the test results.

In reply to a post by thinksingle:

I still cannot figure out why the TBB tester gives me such poor single threaded speeds but downloading the test files on TBB network with single thread connection gives me full speeds.

Many many years ago when I was on cable, NTL used to run their network incredibly hot, and then installed transparent proxy caches to reduce external traffic for HTTP. These then became the point of failure and broke.

I suspect they still run the network hot, and you get asymmetric routing around the VM consumer network (note, this is on the TCP/IP side, before it gets to DOCSIS physical) and it is seen as 'good enough' by the money people.

So its possible there is a network issue that means single streams are handled quite well, and multiple streams expose a weakness in a design. VM has to have a lot of capacity to sell 200 and 300 mbps services; and managing that capacity is incredibly complicated.

This isn't a corporate network with 1,000 people's 100mbps to the desk connections.

In reply to a post by cje85:

I've just downloaded the 1GB file from TBB in 53.1 seconds, with an average speed of 160Mbps.

This ties in with the results given by testmy.net and dslreports:

http://testmy.net/db/VtPJI2cT7
http://www.dslreports.com/speedtest/13947144

However the TBB x1 test is only showing 60-84Mbps

https://www.thinkbroadband.com/_assets/speedtest/but...

It seems to be underestimating the single thread speeds, especially as test file downloads from TBB are so much faster. than the test results.

Ok I've found a way to compare the TBB speedtester and TBB test files:

http://imgur.com/a/j1xeE

I wonder if there is perhaps a bug in the ack suppression? I dont know how ack suppression works but it sounds like something that has the potential to harm throughput if it suppresses the wrong acks? There is a surpress ack option on my asus wifi router, and if I enable it sometimes I get slow downstream throughput. But I dont know if that works the same way as the docsis version.

Also as far as I know selective ack's dont reduce the ack traffic, but they do allow you to get away to a degree with dropped packets by allowing only part of a chunk of data to be need to be re transmitted instead of the whole chunk in the event of dropped packets.

Nagle algorithm reduces ack traffic and is on by default in all versions of windows, freebsd, ios. For linux (including android) nagle algorithm is used on large packets but not small packets.

Given the recent posts from multiple people that show dslreport single threaded tests and tbb http downloads been full speed, that shines a new light on the situation.

Edited by Chrysalis (Sat 27-May-17 02:11:20)

You're thinking of cumulative acknowledgement. Nagle is used to reduce packet count by having applications fill more of an MSS before the payload is put into a packet and sent on the wire.

I was thinking of cumulative and selective. The suppression as mentioned is done at the modem and a cumulative acknowledgement produced when required.

Without selective acknowledgement suppression breaks in a big way

Not aware of it being broken. Would expect to see variations between different CPE.

Until we can be confident that the Virgin Media core network is not playing around in terms of limiting performance almost possible to do anything conclusive.

The volume of people posting poor speeds with a wide range of speed testers and doing so in response to services not working does point to their being ongoing issues.