bandwidth issue out of ideas

By "upload power" do you mean upload rate? Who is your ISP and what package do you have from them?

Okay. The reason I asked is because you talk about signal power as if lower is better, it's the other way around. "upload power level of 54" doesn't mean much. There are two separate metrics which are important for gauging signal quality.

First is Signal Power or RMS signal amplitude. This is measured in dBmV, or a logarithmic ratio relative to 1 millivolt RMS. This ratio is logarithmic, so a 1 millivolt signal would have 0 dBmV. Why? 10Log(1mv real signal / 1mv reference signal) = 0. dB stands for deciBel, Bel indicates that it's a logarithmic value, and deci indicates that it's one tenth, 88dB = 8.8B. The output of the Log() function is multiplied by ten to convert it from Bels to deciBels.

If the signal power is too low, the receiving amplifier won't be able to make any sense of it as it will be indistinguishable from background noise. If the signal power is too high, it could damage the equipment.

For DOCSIS 1.x - 3.x (cable) the signal power has a wide valid range of +8dBmv to upwards of +52dBmv depending on the particular standard. This means that RMS signal amplitudes between 2.5 millivolts and almost 800 millivolts are valid. However, the recommended range is between 35 dBmV and 52 dBmV. Some standards allow for it to go a bit higher, so if it was at 54 dBmV you were already in a good position.

The second, and immensely more important metric is the signal to noise ratio. When the receiver amplifies the signal that was sent along the line it also amplifies the thermal, radio frequency, and electrical noise on the line. Coaxial cable is rather well shielded but it is not immune to noise entirely. specifically, RG-59 cable used to deploy most cable networks in the late 20th century is not suitable for digital transmission and should be replaced with RG-6 cable. The signal to noise ratio works a lot like the signal strength. It's logarithmic but rather than compare a real signal to a reference value, it compares the ratio of the RMS signal amplitude to the RMS noise amplitude (or the signal power to the noise power since they're directly related by a factor of two). Since SNR is a relative ratio between two values of the same unit rather than absolute value itself, it's measured in dB rather than dBmV.

In an ideal world noise wouldn't exist. This would mean that the SNR would be 10Log(Vsignal/0) which would be undefined due to zero noise. Even if the noise were present but infinitesimally small the SNR would approach infinity. This means that a high SNR is very desirable as it makes it easier to separate the signal from the noise, which reduces the occurrence of transmission errors at any particular transmission rate. Since the SNR can approach infinity there's no upper cap on the SNR but typical SNR for cable hookups is in the 30-40 range.

You can see here that when it comes to signals, higher ratios are generally better.

/Tutorial off

11 megabits per second is 1.375 megabytes per second. Decent enough to stream but it doesn't leave a whole lot of room for overhead. Have you tested this when you are the only person on the internet in your residence, or even better when you are the only person connected to the uplink? If not, please do so.

Finally, DOCSIS uses shared nodes. The upstream and downstream bandwidth to each node is quite high, that node then branches off to connect to a number of households. Cable companies usually leave a bit of overhead on each node to ensure quality of service but occasional congestion is not unheard of. If someone nearby is torrenting 24/7, they may have an impact on your quality of service, especially considering that most cable companies configure the data channels for optimal download rates rather than upload rates. Rather than having your cable company fiddle with your line, have them check the node.

Let me know if you have any further questions.

Yeah, that would be the upload signal power. 54dB is quite high, close to the maximum allowed by the standard. If the SNR is high and the cable span to the next receiver is rather short then it doesn't need to be that high. 45dB is fine, it should just be above 35dB. I don't think that there's any problem there.

If your speedtest results are consistently clean then it's not a problem with your local hookup and the techs are right in that there's nothing wrong as far as they can see. More than likely it's a problem upstream along the route from your home network to your stream provider. It's on your ISP's side, Twitch's side, or someone else in the middle, not yours. This is something that will have to be elevated to higher tier tech support, but many ISPs are loathe to make changes like that for a single residential customer. You'd have a better case for a compliant if you were paying for a business line. It's worth bringing to their attention though.

Explain that you're having connection issues with a particular service. Technicians have checked your own hookup and everything seems okay. It's most likely an upstream issue.

Speedtest selects the closest test server possible to ensure that the number of jumps between your home network and the test server is as low as possible. There are a number of Speedtest servers, often several in every major city. On average, one could expect between 4 and 6 network jumps to the closest Speedtest server. The first couple of jumps will usually be through your ISP, followed by the major internet backbones (if applicable), followed by the destinations ISP, and finally the destination itself.

From my location here in the GTA it takes 8 jumps to get to www.tomshardware.com (which is on a Content Delivery network by the looks of it), yet getting to www.tomshardware.co.uk requires 14 jumps.

www.twitch.tv uses a CDN as well. I do not know what's involved with streaming to www.twitch.tv but a traceroute showed about 14 jumps as well.

If any one of those jumps is experiencing congestion, the entire route will experience a degraded quality of service. Speedtest is fine because there's only a few network hops between your PC and the local speedtest server. Since your local hookup is a common denominator between speedtest and twitch (that is, the traffic to both flows through the same physical cable and over the same logical interface) I'd say that it can safely be ruled out. However, at some point that traffic diverges, speedtest follows one path, and twitch follows another.

Internet traffic is a lot like running a relay race. Person A runs the baton to person B, who runs the baton to person C, who in turn runs it to person D. If person C decides to be a lazy fuck or stop for a big mac in the middle of the relay race, person D won't get the baton until much later than he or should normally would have. Your local internet connection in this case would be person A, and twitch.tv's upstream provider would be person D. Both can be great competitors, but they're at the mercy of persons B and C to do their jobs properly.

This analogy can get a bit more complicated. Lets introduce persons E and F. E and F are in parallel to B and C. Person A can hand the baton to persons B or E, and persons C and F can hand the baton to person D. B can only hand the baton to C, and E can only hand it to F. There are now two possible routes that the baton can take from A to D:

A -> B -> C -> D

or

A -> E -> F -> D

In this case, both routes require the baton to be passed three times, but there's no knowledge of how fast it will be passed. If C is a slow fuck, then the second route through E and F may be faster but it's up to the sender to decide which route to use for each baton. The sender may continue to use B and C until C passes out from exhaustion, at which point the sender will fall back onto E and F. Alternatively, the sender may alternate between them, or try to estimate which one will be faster for each baton on a case by case basis.

Lets add another runner, G, inserted after F.

A -> E -> F -> G -> D

now the second route is longer, requiring 4 exchanges rather than 3. If all runners were equal, the first route with B and C would make the most sense, with the second route only being used if B breaks an ankle or C has a heart attack. However, not all runners are equal, nor are all major interconnects on the internet. However, unlike runners in a relay, NICs are blind. They don't have the ability to evaluate other nodes without being told information about them first.

Imagine if A didn't know that C was a worthless runner and just kept handing the baton to B because D kept saying that it arrived. Without knowing something about the E -> F -> G chain, or being explicitly told to use it, it'll just continue to use the busted B -> C chain until the end of time.

Anyway, that's what I mean by telling them to look upstream.

The only other alternative would be to look at your PC itself. I know next to nothing about streaming, so I can't really help you there.

Just tell them what you're doing. You're streaming high bitrate video upstream and it's having intermittent connectivity issues.

Bingo, just what I thought it was! Just a matter of time until they sort it out. Best of luck!

Yeah but now that they're aware that it's impacting customers adversely they may prioritize it higher