Broadband dropouts

[abek42]

Hello EE Forum folks,

Just came off a fairly unhelpful support call with EE agents.

We have the copper wire broadband (can't get Fibre due to some issue between BT/EE/Property management co).

The speeds "guaranteed" are 1Mbps up and 15+Mbps down.

However, any time we are trying to upload something (e.g. a video in Whatsapp, typical size 5-10MB, OneDrive file, typical size 2-100MB), the down pipe grinds to a halt.

Everything dies and won't respond till the upload pipe is clear.

The answer I was panned off with was "your wired broadband can't handle this".

Frankly, as someone who has studied Networking 101, this sounds like hokum.

Even my 56.2K dialup modem could handle both up and down simultaneously.

So, dear community, what are my alternatives?

I would normally just switch to mobile data at least on my phone, but these days, the EE mobile data (again!, all eggs in one basket mistake), doesn't even work when I am standing with the phone held 50cm outside the window. (something to do with buildings blocking the mast yadda yadda).

Stuff that's already been checked already:

1. Wired into main access point

2. TV runs Netflix via LAN cable between router and TV (so no "2.4GHz band crowding issues")

3. The EE Brightbox is a new one (and agent confirms, fully up to date)

4. Broadband works fine with just downloads (can confirm that I can run iPlayer, Netflix x2 and Youtube@1080p simultaneously without loss of quality/buffering)

Thanks!

[XRaySpeX]

Welcome to EE's Home Broadband Forum.

If you would like help with your BB speed or connection issues, please would you carry out the following steps for starters, which will enable us to diagnose the problem and advise you further. Do not restart your router to do these tests:

1. Post your full router stats:

• For a BrightBox: login and go to Advanced Settings/ System/ DSL Status. Also post 'System Uptime' from top of System Log page.
• For a SmartHub: login and go to Advanced Settings/ Technical Log/ Information. Obscure your names & any numbers in the BB Username & also the SSIDs.

Full router stats are key to any speed & connection issues.

2. Try a wired speedtest, using an Ethernet cable supplied with the router, here http://www.thinkbroadband.com/speedtest.html . Click on the "Results Page" button at the bottom of the graph you first see and then copy to here just the "Link to this result:" link that you see below the next main graph.

[mikeliuk]

Hi @abek42 ,

In addition to the above good advice, you may want to take a quick look at the loaded latency at fast.com under its advanced functionality, compared to the unloaded latency. https://about.netflix.com/en/news/fast-com-now-measures-latency-and-upload-speed

You would be primarily interested in the loaded latency under heavy upload.

Assuming you don't have FTTC/fibre, it seems like the service adviser was claiming the ADSL connection is half duplex whereas you believe it is full duplex. Regardless of which it is, the loaded latency will give a clue as to what is happening. I've seen loaded latency worse than 2000 ms still performing better than you've described.

It is plausible that saturating your upload link will interfere with the performance and functionality of your download link but it's not at all a commonly reported phenomenon. Advanced users would be able to throttle their upload to test if leaving a little headroom makes the issue disappear. The easiest step is to see how the loaded latency looks and go from there.

[XRaySpeX]

@mikeliuk : You're talking thro' your hat yet again!

No ISP would claim their BB connection is half duplex. BB by its very nature is always full duplex. You may be confusing it with the property of TCP/IP in general where a heavy lengthy upload over a low bandwidth (1 Meg) would require & generate many frequent ACKs on the downstream so as to interrupt & stifle all downstream activity.

[mikeliuk]

For the avoidance of doubt, I believe ADSL is full-duplex, at least in the UK, although wiki says "most ADSL communication is full duplex".

https://forums.thinkbroadband.com/technical/3690441-is-my-adsl-full-duplex-or-not.html

https://en.m.wikipedia.org/wiki/Asymmetric_digital_subscriber_line

Not sure whether I believe this claim that an OpenReach VDSL2 modem can negotiate half duplex: https://community.plus.net/t5/ADSL-Broadband/Openreach-VDSL-modem-throughput-was-Profile-nudge-pleas...

This is in contrast to WiFi technology which is half-duplex.

https://wififorbeginners.com/2016/12/05/wi-fi-secrets-part-1%E2%80%8A-%E2%80%8Awired-is-faster-than-...

The V.90 standard for 56k did indeed support full duplex.

Even my 56.2K dialup modem could handle both up and down simultaneously.

https://www.techopedia.com/definition/3017/v-90

Interestingly, G.fast is half duplex. https://mental.me.uk/wordpress/index.php/g-fast-technology/

[abek42]

Thanks @XRaySpeX . I will post the details about the status in some time.

However, I have a feeling that the problem is the other way round.

Assuming that there is no other issue with the line, the down pipe could still support data, its just that the up pipe is clogged by the single connection and thus all acks that need to be sent up in response to the data coming down the down-pipe are being ignored.

I am surprised that the Brightbox tries to use the whole up pipe for a single connection instead of leaving some of the bandwidth free for other traffic.

@mikeliuk: looking at Fast.com and the linked article now. Will post results from that too.

[abek42]

@mikeliuk Ok, the first test was easy to run.

Latency:

Unloaded 33 ms

Loaded 2.0 s (that's 2000ms)  Something tells me that's bad...

@XRaySpeX: Data as requested:

Status  Configured CurrentLine StatusLink TypeOperation Mode

--	UP
--	Interleaved Path
Automatic	G.992.5 (ADSL2+)

Data Rate InformationUpstreamDownstream

1232 (Kbps)

17293 (Kbps)

Defect/Failure IndicationOperation Data Upstream DownstreamNoise MarginLine Attenuation

6.1 (dB)	2.9 (dB)
7.3 (dB)	16.5 (dB)

Indicator Name Near End Indicator Far End IndicatorOutput PowerFast Path FEC CorrectionInterleaved Path FEC CorrectionFast Path CRC ErrorInterleaved Path CRC ErrorLoss of Signal DefectFast Path HEC Error STRInterleaved Path HEC ErrorError Seconds

12.6 (dBm)	0.0 (dBm)
--	--
370761877	2006
--	--
23335	33
0	0
--	--
224839	43
3773	26

StatisticsReceived DataTransmitted Data

15977945 (Kbits)

8557616 (Kbits)

 System Uptime is: 167:05:37

Speed test results: https://www.thinkbroadband.com/speedtest/1630795194303894255

I throttled the OneDrive/Dropbox upload through their own dedicated settings, but will have to spend a bit more time figuring out how to throttle Whatsapp. This obviously isn't the full solution, because OneDrive/Dropbox are not the only things that sometimes need large uploads.

[mikeliuk]

In contrast to taking 33 milliseconds to get a reply back from the server, it took 2 seconds which is 60 times longer.

I've seen such numbers with Three 4G LTE but not uploads killing downloads. If no replies got through loaded or it exceeded 3000 ms, then it might explain. 2000 ms seems short enough that downloads should survive even if you saturate the upload link.

One thought is to deliberately run multiple of the bad uploads and simultaneously visit fast.com

According to the original report, the download bandwidth should measure near zero and the latencies should be terrible. On the other hand, if the synthetic benchmark gives a reasonably high measured download bandwidth, but you still find downloads dying, there would be a mystery.

[XRaySpeX]

@abek42 : You might need to increase your TCP Receive Window size (RWIN) in your OS to reduce the frequency/quantity of ACKs needed to be sent upstream in response to your d/loads.. What is your result from SG TCP/IP Analyzer ?

[XRaySpeX]

Sorry, @abek42 , you're right! I got it the wrong way round. I knew it was to do with ACKs but forgot in which direction after so long since I last thought about this.

It is TCP/IP in general where a heavy lengthy upload over a low bandwidth (1 Meg) saturates the upstream to such an extent as to leave no bandwidth spare to accommodate the many upstream ACKs required & generated from the downstream activity so as to delay & stifle all downstream activity in a WAIT state.

The BrightBox only does what it is asked of it at a particular time, i.e. send/receive a TCP/IP packet. It has no discretion of its own to insure any margin. However you can tell it to do so by utilising its Bandwidth Control & QoS features.