Looking for long distance hyperfibre benchmarks

Forums › New Zealand Broadband › Looking for long distance hyperfibre benchmarks

1 | 2

dzh

45 posts

Geek

Trusted

#3108186 26-Jul-2023 10:54

fe31nz:

So no-one seems to have ever done much thinking about a better system than TCP already uses, because there is no point for them.

https://en.wikipedia.org/wiki/TCP_congestion_control#Algorithms

Sharesies

Trade NZ and US shares and funds with Sharesies (affiliate link).

Talkiet

4689 posts

Uber Geek

Trusted

#3108188 26-Jul-2023 11:01

https://en.wikipedia.org/wiki/QUIC

Please note all comments are the product of my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

fe31nz

1084 posts

Uber Geek

#3108605 26-Jul-2023 22:52

dzh:

fe31nz:

So no-one seems to have ever done much thinking about a better system than TCP already uses, because there is no point for them.

https://en.wikipedia.org/wiki/TCP_congestion_control#Algorithms

Congestion is not the problem being discussed, although it obviously can have a big effect on download and upload speeds. The problem is the TCP window size and getting it ramped up quickly enough so that your TCP connection is not spending most of its time waiting for the next ACK packet before any more data gets sent.

fe31nz

1084 posts

Uber Geek

#3108606 26-Jul-2023 23:06

Talkiet:

https://en.wikipedia.org/wiki/QUIC

This looks interesting as it avoids using TCP and does its own protocol, which is pretty much what is required in order to avoid the TCP window problem. But on first glance, it appears to be using multiple data streams, which should not be necessary if you do not have the TCP window problem to contend with. QUIC appears to be using multiple data streams to avoid slowdowns from packet loss. Since packet loss is fundamental to how IP routers handle congestion, any good protocol has to pay attention to how to handle packet loss well. But I am not sure that just having one data stream slow down due to packet loss and allowing other data streams to speed up to compensate is the right way to go about it - your steams might end up contending with each other at the overloaded router(s). In the specific case of the OP, when dealing with monster size files, best speed should be achievable with one stream and complex packet loss and retransmission control, as the requirement is for the entire monster file to arrive intact as fast as possible, rather than to have a stream of data arriving in a form where the data that has arrived can be used as it arrives (eg streaming TV).

dzh

45 posts

Geek

Trusted

#3108663 27-Jul-2023 09:06

fe31nz:

Congestion is not the problem being discussed, although it obviously can have a big effect on download and upload speeds. The problem is the TCP window size and getting it ramped up quickly enough so that your TCP connection is not spending most of its time waiting for the next ACK packet before any more data gets sent.

I'm far from expert here, but isn't Slow Start part of congestion protocol?

That almost seem like a key point citing marketing slide of Google's BBR
TCP vs BBR

Jase2985

12348 posts

Uber Geek

ID Verified

Lifetime subscriber

#3108756 27-Jul-2023 13:09

linux and windows 11 2h22 can apparently enable BBR

fe31nz

1084 posts

Uber Geek

#3108898 28-Jul-2023 00:09

Jase2985:

linux and windows 11 2h22 can apparently enable BBR

I have been running BBR on my Ubuntu systems for several years. I did not realise Windows 11 now could do it also - I will have to enable it there too.

concordnz

420 posts

Ultimate Geek

Trusted

EMT (R)

#3109456 29-Jul-2023 07:42

Lol, my large uploads/downloads often look exactly like that first graph, - I was puzzling as to what was causing to 'sawtoothing'

I'll have to read up on this BBR,
(can BBR be enabled on Windows 10?
And does it have to be enabled at both end?

BarTender

3530 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#3109461 29-Jul-2023 08:54

Unless you can change the speed of light living in a TCP world there isn’t much that can be done. Sometimes using a VPN somewhere in between helps as then the client to VPN server is UDP and then the latency between the server and target host is less. Also some VPNs do clever TCP assembly and continue TCP requests.
As has already been said QUIC or a multithreaded protocol is the only solution and that depends on you having control over both ends.
It’s not going to fix general internet browsing or large single threaded downloads over TCP.

and

1 | 2