Good call on the congestion idea. FluidOne did some NUTTCP tests which showed that the line itself was ok (it could hit 300Mbps) but they enquired with Openreach about possible congestion and that has showed up a potential issue, which is getting looked into.

In reply to a post by raesene:

Good call on the congestion idea. FluidOne did some NUTTCP tests which showed that the line itself was ok (it could hit 300Mbps) but they enquired with Openreach about possible congestion and that has showed up a potential issue, which is getting looked into.

Did your peak time speed issue get resolved in the end? Luckily no such issues on my line ever since it went live.

In reply to a post by baby_frogmella:

Did your peak time speed issue get resolved in the end? Luckily no such issues on my line ever since it went live.

The call is still open with FluidOne for now, I'm guessing there might not be much progress on it now till the new year. Today I'm seeing 210Mb/s down, so somewhat below where it should be...

In reply to a post by raesene:

Today I'm seeing 210Mb/s down, so somewhat below where it should be...

Mmmmm still room for improvement but at least FluidOne are working on it. You should be seeing something like this once its fixed

http://www.speedtest.net/my-result/6922450391

It will be interesting to see what Fluidone are able to do given that Openreach wont necessarily consider congestion a fault unless your FTTPoD connection is running at less than 40Mb.

so just an update in case anyone else gets similar problems

baby_frogmella was right on target with the congestion thing. After a couple of to and fro's with Openreach, the line got moved to another VLAN and that's improved matters greatly (I was seeing speeds as slow as 30Mbps in the evenings before the move and now I'm pretty much always over 200Mbps)

Apparently the complex faults team are still looking at it as there's some undefined problem on back-end systems, but it's now largely fixed

As an aside, one technique I found useful for gathering statistics to demonstrate the problem was using iperf3 (https://iperf.fr/iperf-doc.php) on cron running every 15 minues for 10 seconds and then dumping the download speed out to a file. that let me graph speed against time, which showed the evening slowdown as a regular occurance.

In reply to a post by raesene:

As an aside, one technique I found useful for gathering statistics to demonstrate the problem was using iperf3 (https://iperf.fr/iperf-doc.php) on cron running every 15 minues for 10 seconds and then dumping the download speed out to a file. that let me graph speed against time, which showed the evening slowdown as a regular occurance.

That looks quite an interesting program. I would like a version for a Raspberry Pi.

so iperf3 is probably in the raspbian repo's if you're using that (I just installed from the Ubuntu repo's)...

In reply to a post by raesene:

baby_frogmella was right on target with the congestion thing. After a couple of to and fro's with Openreach, the line got moved to another VLAN and that's improved matters greatly (I was seeing speeds as slow as 30Mbps in the evenings before the move and now I'm pretty much always over 200Mbps)

We had a similar issue with our FTTP with BT where our 300Mbit dropped down to 45Mbits in the evening a few times.

All it took was a phone call to BT and the issues was removed, granted I was told its not classed as a fault until it drops below 40Mbits.
After about 10 to 20 mins of me complaining etc I was forwarded to the technical team and they did some checks and the next night up to now it has been fine.

Granted it still drops in the evening etc but it s never drops below 200Mbits.

Paul

Hopefully the fix will last.
I've had congestion problems with BT Wholesale back haul on Zen in the past and an SVLAN swap fixed things for a while and then congestion would return again and we'd have to do the same merry dance to get it moved again.

Edited by deleted (Tue 30-Jan-18 18:50:28)