You must feel like a kid at Christmas

I'd love an excuse to setup a network like that, maybe I'll switch from software development

The DSL Checker for my address has been updated today, now showing stage 1 like another member had, so hopefully not too long now!

Mine was roughly two weeks from that stage for the appointment (although it said 2 stage for me I presume that was related to four port ONT I had installed).
Should be just one more visit.

In reply to a post by F00tS0re:

Mine was roughly two weeks from that stage for the appointment (although it said 2 stage for me I presume that was related to four port ONT I had installed).
Should be just one more visit.

Pretty sure that type of ONT provided wasn�t anything to do with the reported number of stages required for the final installation.

This was most likely to be a database error with Openreach systems believing your infrastructure was blown fibre to a CSP rather than connectorised.

My audit step was completed yesterday so now in commissioning phase - I guess I am just waiting for an appointment now to install the ONT? DSL checker updated today to show FTTPoD 1000/220 - still saying FTTP is not available though.

In reply to a post by brookheather:

My audit step was completed yesterday so now in commissioning phase - I guess I am just waiting for an appointment now to install the ONT? DSL checker updated today to show FTTPoD 1000/220 - still saying FTTP is not available though.

Yup. Last stage but due to a twist in the time space continuum the last stage takes forever. Every second of buffering seems like an hour or more. But essentially yes, one appointment most likely to install ONT.
If you watch the ADSL tracker it should change to 1-stage, and then they can arrange an appointment.

Definitely start planning the fibre party (it involves inviting no-one round but do select a playlist of favourite speed test apps!). Tried a Sky Q UHD film yesterday and within 3-seconds it said ready to play. Whole 17GB film took 25minutes to download at a rate of 85Mbps to 105Mbps, which presumably was Sky's limit. Everything else on our network was still running fine, streaming radio, email, surfing etc.

I already have 80/20 FTTC so the jump won't be as noticeable for me as it was for you! I now have my pfsense box up and running on my FTTC connection - took a couple of days to copy over all of the configuration from my Asus router - I found OpenVPN particularly tricky to get working due to a mismatch on a name on the user certificate - no error messages just hanging on connection - anyway sorted now.

Once live on FTTP my plan is to move my phone number from PlusNet FTTC to VOIP (probably sipgate) and then terminate the FTTC contract. I already have a Cisco adapter working with a temporary number.

Well that's just greedy! Lol.

In reply to a post by F00tS0re:

Whole 17GB film took 25minutes to download at a rate of 85Mbps to 105Mbps, which presumably was Sky's limit.

At these speeds, you'll start to discover some new factors which probably weren't an issue before.

TCP has an exponential back-off algorithm which reduces its throughput in response to packet loss. If packet loss is due to congestion, this is an important mechanism to prevent network collapse. But if there is packet loss due to any other cause, it can limit the throughput of a TCP stream; and it is remarkably sensitive to tiny amounts of packet loss, especially as the round-trip time increases.

The formula is here.

Given a standard MTU, a round-trip time of 15ms and packet loss of 0.01% (that's just 1 in 10,000 packets!) the maximum throughput of a single TCP stream is

1460 / (0.015 * sqrt(0.0001)) bytes/sec = 9.73MB/sec = 77.9Mbps

If you experiment with this formula you'll see RTT is the most important factor. On a LAN with a RTT of 1ms or less, you're unlikely to notice any problem. However if you're transferring files from Europe or the US, the throughput is severely affected by tiny amounts of packet loss.

So if your file transfer from Sky was over a single TCP stream (e.g. HTTP/FTP), this is most likely the limiting factor.

When you have lots of TCP streams - for example lots of people browsing the web concurrently - it's not an issue in practice, since each TCP stream is independent. When you use file transfer protocols that open many concurrent streams and/or use UDP (e.g. Bittorrent) then you'll also get higher throughput.

Last time I checked, speedtest.net runs 6 streams concurrently, to the node with the lowest RTT. This is because it's designed to make your ISP look good, rather than identify these sorts of problems.

Measuring low-level packet loss directly is not easy. perfSonar toolkit does a pretty good job - in its default configuration it sends 10 packets per second (36,000 packets/hour), and measures packet loss in each direction separately. You need a remote node to test to though. The public community of nodes is mostly intended for Research & Education networks.

Enjoy your new service!

Congratulations. You're nearly there!

My latest update is sadly more bad news. a Precision Testing Officer is now required as exchange issues have been discovered which requires their skills. The UG allocator is organising it to be resolved as soon as possible.

In reply to a post by candlerb:

1460 / (0.015 * sqrt(0.0001)) bytes/sec = 9.73MB/sec = 77.9Mbps

If you experiment with this formula you'll see RTT is the most important factor. On a LAN with a RTT of 1ms or less, you're unlikely to notice any problem. However if you're transferring files from Europe or the US, the throughput is severely affected by tiny amounts of packet loss.

So if your file transfer from Sky was over a single TCP stream (e.g. HTTP/FTP), this is most likely the limiting factor.

Wow, awesome to know, everyday is a school day. Ping time is 11ms but understand that won't be the same across a continuous download. I did a quick Google to see if it is single or multi-thread. I think the issue lies with the fact that SkyQ ethernet port is 100MB!. 5MB between app reporting and port speed reality I can cope with.

But the above formula might explain why Sky saw no benefit in putting a 1Gbps capable port in. Although if downloading and streaming to another box in the house the extra bandwidth could be useful.

At 1 in 100,000 packet loss it would hit 246 Mbps in theory and 335Mbps at 11ms. So as you said it is heavily dependent on RTT. I'll not upgrade to 1Gbps this week then. Interesting stuff and will be useful to explain to people when they complain they can't download;oad at max speed.

Cheers
Dave