Computers & Hardware > Networking

Latency when downloading from internet flat-out

(1/4) > >>

Weaver:
When a flat-out download is in progress to my iPad, I can see, courtesy of Andrews and Arnold’s CQM graphs, that the link is being maxed-out. I’m wondering why the latency is so high during a download as measured by AA’s PPP LCP ‘pings’ (PPP LCP echo requests or whatever they’re called) is so high - eg 460 ms max even.

Is this due to bad queue management in my iPad (which is doing the downloading)? Does iPadOS need a better algorithm for managing this, or am I misunderstanding?

burakkucat:
Is it a case that as the total bandwidth is being consumed the return ACKs are being delayed (or dropped)?

Weaver:
I wouldn’t think so, as the graphs show that the uplink is not maxed out, so the TCP returned ACKs can get back up safely. I think the delay is all in the downstream with the PPP LCP pings being stuck behind a queue of stuff heading down, but I can’t be certain about this at all.

Actually, that would mean I was talking nonsense before and the queue management would need to be in the server’s OS, no?

Now I think about it again, I’m tentatively assuming that there’s no upstream ingress queue or a minimal length one to be managed by [what?] upstream-bound. Not thinking straight, tired and full of drugs. The upstream ingress queue is in the modem, yes? But I presume it could effectively be managed by an OS further back (ie nearer to the source)?

Reformed:
Delay is downstream and due to buffer bloat somewhere on the downstream path. Pretty common.

Can't really manage upstream queues on an end device as they only have visibility of what they're sending. Needs to be where the bottleneck is as that device may see all network traffic before it hits the bottleneck and may queue.

Chrysalis:
Modern internet is aggressive for high download speeds, to max out people's pipes who have multiple 100s of mbits available for downloading.

All of the following contribute to download buffer bloat.

Local CDN hosted content (low latency so easier to over saturate buffer).
Multi threading, very common on consoles, steam, uplay etc.
Modern congestion algorithm's, which again are optimised to fill fat pipes. (sender controlled so not a lot you can do other than to cap RWIN, or aggressively drop packets).

Google's BBR algorithm is new and actually better than most other's at maintaining performance whilst downloading, it's able to slow it self down without as much over buffer as other algorithm's, as always though it will likely take years for this to get adopted around the net.

Some info here regarding BBR and congestion algorithm's. https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/

Navigation

[0] Message Index

[#] Next page