Openreach can, on remote testing, see if there is or isn�t a BBU connected.

In reply to a post by Zarjaz:

Openreach can, on remote testing, see if there is or isn�t a BBU connected.

Oh dear

Keep an eye out for the Openreach Detector Vans

Removed my BBU almost a year ago without any complaint, although I assume that if you had problems then it would show up during any diagnostics.

http://forums.thinkbroadband.com/fibre/t/4558043-ont...

The BBU doesn't look bad as it's part of one unit now. It actually managed to fit perfectly in the space I had reserved for it.

Regarding the download speeds when uploading I was speaking to a friend of mine who is a network engineer and he said it's expected because when you download your device still needs to send a confirmation packet back to the server you are downloading from.

Therefore if the upload stream is being maxed out these confirmation packets will take longer to get back to the server and therefore slow down the download.

I'm just not sure if it should be as dramatic as what I am seeing. The way the router handles things probably does make a little bit of a difference. I was uploading to you tube for my test.

I must admit downloading a gig in 27seconds is really cool. It's definitely been worth the wait. So far my line seems very stable too at 310 mbs.

All I have left to do now is get my replacement cat5e cable from amazon and then tidy up my comms cupboard and screw things back into place to cover wires etc.

Try enabling QoS so that you don't absolutely max out your upload.
Set it about 95% of your upstream throughput and test it again.

You should really be able to download/upload at near maximum levels on FTTP.

I thought one of the advantages of fibre was that the upload and download channels don't interfere with each other like dsl does.

That's not how dsl works either. The downstream/Upstream bands are completely separate and you can max out both simultaneously.

Edited by j0hn83 (Sat 16-Jun-18 14:15:11)

TCP Acks

Post deleted by ferretuk

In reply to a post by MrSaffron:

TCP Acks

Delays in acks would reduce throughput if the round-trip delay is longer than the TCP window size. Modern TCP stacks tend to use a large window size; you can see with wireshark/tcpdump what window size has been negotiated (including the window scaling factor).

For example, on a test from macOS to TBB speedtest:

Text
1 2	08:35:01.591036 IP 10.12.255.240.64115 > 80.249.106.133.443: Flags [S], seq 3179489571, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1257357607 ecr 0,sackOK,eol], length 0 08:35:01.602209 IP 80.249.106.133.443 > 10.12.255.240.64115: Flags [S.], seq 863049753, ack 3179489572, win 14480, options [mss 1460,sackOK,TS val 3404316022 ecr 1257357607,nop,wscale 7], length 0

Window size in the return direction is 14480 * 2^7 = 1853440 bytes; that translates into about 50ms at 300Mbps. Packet loss can also reduce throughput, because dropped packets reduce the separate congestion window.

If there are multiple TCP streams running concurrently, then each one has its own window. Speedtest.net offers me a larger window (28960 * 2^7); and it also runs six TCP streams concurrently as opposed to TBB's one, to reduce the visible affects of packet loss. In other words, it's tuned to make your ISP look good!

It's also possible that the home router is the bottleneck, as it's doing all that forwarding and NAT.

Hi Mumba,

Congrats on getting to the finish line.

I also have the complete Unifi setup. I originally had the USG gateway, then I got the USG pro. The pro cpu handle's the connection a lot better especially when doing speed tests. Just an FYI.