|
|
I just migrated from aquiss to IDNet on a cityfibre line and am regretting it. Straight away single threaded speeds were poor, they have somewhat resolved the download speed but the upload is still low. Package is 2500Mbps and single threaded on aquiss was about 1Gbps.
aquiss hours before the migration
https://www.thinkbroadband.com/speedtest/17533108983...
IDNet just afer migration, single thread download looks fine but by morning it's low they have since resolved that after pointing out they guarantee 900Mbps
https://www.thinkbroadband.com/speedtest/17533181936...
IDNet just now, single threaded download better but uploads still low
https://www.thinkbroadband.com/speedtest/17543090702...
I've been running automated iperf upload test ever 5 mins for the last 3 days and it's always around 300 Mbps average with lower speed during peak time. sometimes the first second it's high like bellow but then instantly falls.
iperf just now
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
20 | iperf3 -c speedtest.idnet.net
Connecting to host speedtest.idnet.net, port 5201[ 5] local 192.168.1.6 port 58804 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate[ 5] 0.00-1.00 sec 147 MBytes 1.23 Gbits/sec
[ 5] 1.00-2.00 sec 59.2 MBytes 497 Mbits/sec[ 5] 2.00-3.00 sec 18.0 MBytes 150 Mbits/sec
[ 5] 3.00-4.00 sec 17.9 MBytes 150 Mbits/sec[ 5] 4.00-5.00 sec 18.2 MBytes 154 Mbits/sec
[ 5] 5.00-6.00 sec 17.9 MBytes 149 Mbits/sec[ 5] 6.00-7.00 sec 8.00 MBytes 67.1 Mbits/sec
[ 5] 7.00-8.00 sec 16.2 MBytes 137 Mbits/sec[ 5] 8.00-9.00 sec 14.5 MBytes 122 Mbits/sec
[ 5] 9.00-10.00 sec 17.6 MBytes 148 Mbits/sec- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate[ 5] 0.00-10.00 sec 334 MBytes 280 Mbits/sec sender
[ 5] 0.00-10.01 sec 330 MBytes 277 Mbits/sec receiver
iperf Done. |
Multithreaded ipfer test mostly fills the upload
| Text | 1
2 | [SUM] 0.00-10.00 sec 2.56 GBytes 2.20 Gbits/sec sender
[SUM] 0.00-10.01 sec 2.56 GBytes 2.19 Gbits/sec receiver |
Single threaded download looks ok
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
| iperf3 -R -c speedtest.idnet.net
Connecting to host speedtest.idnet.net, port 5201Reverse mode, remote host speedtest.idnet.net is sending
[ 5] local 192.168.1.6 port 59243 connected to 212.69.36.111 port 5201[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 162 MBytes 1.36 Gbits/sec[ 5] 1.00-2.00 sec 147 MBytes 1.24 Gbits/sec
[ 5] 2.00-3.00 sec 140 MBytes 1.18 Gbits/sec[ 5] 3.00-4.00 sec 160 MBytes 1.34 Gbits/sec
[ 5] 4.00-5.00 sec 165 MBytes 1.38 Gbits/sec[ 5] 5.00-6.00 sec 151 MBytes 1.26 Gbits/sec
[ 5] 6.00-7.00 sec 150 MBytes 1.26 Gbits/sec[ 5] 7.00-8.00 sec 150 MBytes 1.26 Gbits/sec
[ 5] 8.00-9.00 sec 155 MBytes 1.30 Gbits/sec[ 5] 9.00-10.00 sec 147 MBytes 1.23 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1.53 GBytes 1.31 Gbits/sec 154948 sender[ 5] 0.00-10.00 sec 1.49 GBytes 1.28 Gbits/sec receiver
iperf Done. |
After a lot of back and forth to prove this issue is not on my end they said this
The fact that single stream upload speeds are so low is worrying but it could be due too much data being sent to the network which is getting rejected or your computer isn't generating data fast enough.
I would suggest the following iperf3 tests
iperf3 -c speedtest.idnet.net -R (to test download speed)
iperf3 -c speedtest.idnet.net -b 2500M (to test upload speed with 2500Mbit/s cap)
iperf3 -c speedtest.idnet.net -b 2000M (to test upload speed with 2000Mbit/s cap)
iperf3 -c speedtest.idnet.net -b 1500M (to test upload speed with 1500Mbit/s cap)
iperf3 -c speedtest.idnet.net -b 1000M (to test upload speed with 1000Mbit/s cap)
If the capped upload speed is still low then it would indicate an issue with CityFibres National Network or the local node is congested.
We can eliminate the CityFibre National Network by switching you to CityFibre via Zen, as unfortunately we can't fix a local node congestion problem.
Those test are also low but if I run a multithreaded iperf test speed is good. If feels like single threaded upload speeds are being capped/throttled. What do I do? agree to be put on zen backhaul? What about the issues I've seen with routing up and down the country, I don't want that. It looks like they are saying it might not resolve the issue as well if the problem is "local node congestion" what doesn that mean?
If I'm stuck with this for 12 months I'm not going to be happy, wish I'd gone for the monthly initially but didn't envisage this poor performance from someone so highly regarded. Thanks for reading.
|
|
|
|
I left Idnet for the problem you've described here. They were unwilling to try and resolve and claimed it was within the guarantee for the speed they would offer.
Turns out later when I've moved to Aquiss they've advised of other people having issues with anything in some cases above the 900mb/1gb mark on the cityfibre network.
Looks more like a capacity issue on cityfibres network than anything else.
|
|
|
|
My area has just been upgraded to 2.5gb XGS-PON. Had new ONT installed the other day. Upload feels throttled to me at certain times, not very happy with it tbh. If it doesnt get sorted out ill deffinatly be leaving when my contract ends.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
The old rule is if you happy dont swap ISP, people keep chasing pennies to move.
I found a post when I was investigating packet reordering, it was on a different community, where people diagnosed/accused idnet or one of their supplier were reordering packets, but bear in mind that conclusion was reached by diagnosing traffic and that the issue started when the person moved to idnet. It was never confirmed officially.
I think in your situation, I would simply move back to aquiss with tail in between your legs and consider it lesson learned.
Edited by Chrysalis (Tue 05-Aug-25 07:53:42)
|
|
|
I left Idnet for the problem you've described here. They were unwilling to try and resolve and claimed it was within the guarantee for the speed they would offer.
Was it he upload you were having issues with as well or just the download?
Turns out later when I've moved to Aquiss they've advised of other people having issues with anything in some cases above the 900mb/1gb mark on the cityfibre network.
I mentioned in passing to them speeds seem reluctant to go above 1Gbps in single threaded, they didn't comment though. It's one of the reasons I switched but as it turns out speed is even worse on idnet.
Looks more like a capacity issue on cityfibres network than anything else.
I'd agree with that if it wasn't for the fact the speed was better on aquiss or are there other differences at play?
|
|
|
My area has just been upgraded to 2.5gb XGS-PON. Had new ONT installed the other day. Upload feels throttled to me at certain times, not very happy with it tbh. If it doesnt get sorted out ill deffinatly be leaving when my contract ends.
What results do you get from iperf?
| Text | 1
| iperf3 -c speedtest.idnet.net |
|
|
|
|
[ 5] local 192.168.1.63 port 50651 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 148 MBytes 1.24 Gbits/sec
[ 5] 1.01-2.01 sec 69.8 MBytes 581 Mbits/sec
[ 5] 2.01-3.00 sec 55.0 MBytes 466 Mbits/sec
[ 5] 3.00-4.01 sec 142 MBytes 1.18 Gbits/sec
[ 5] 4.01-5.01 sec 117 MBytes 979 Mbits/sec
[ 5] 5.01-6.01 sec 78.9 MBytes 667 Mbits/sec
[ 5] 6.01-7.01 sec 145 MBytes 1.21 Gbits/sec
[ 5] 7.01-8.00 sec 77.6 MBytes 658 Mbits/sec
[ 5] 8.00-9.01 sec 151 MBytes 1.26 Gbits/sec
[ 5] 9.01-10.01 sec 165 MBytes 1.37 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 1.12 GBytes 964 Mbits/sec sender
[ 5] 0.00-10.02 sec 1.12 GBytes 957 Mbits/sec receiver
|
|
|
The old rule is if you happy dont swap ISP, people keep chasing pennies to move.
Indeed, money wasn't the motivating factor in this case though, idnet costs more.
I found a post when I was investigating packet reordering, it was on a different community, where people diagnosed/accused idnet or one of their supplier were reordering packets, but bear in mind that conclusion was reached by diagnosing traffic and that the issue started when the person moved to idnet. It was never confirmed officially.
Interesting can you link it?
I think in your situation, I would simply move back to aquiss with tail in between your legs and consider it lesson learned.
I may go back to aquiss but I might try A&A next if idnet can't improve it.. might as well try them all now. The lesson I'll take is to go for the 30 day term option initially if available regardless of rep. Certainly no need to have my tail in between my legs!
It would be good if a 24 hour trial for a small fee is offered when migrations are just a software update. At the end you can choose to go ahead and switch or stay put.
|
|
|
| Text | 1
23
45
67
89
1011
1213
1415
16 | [ 5] local 192.168.1.63 port 50651 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate[ 5] 0.00-1.01 sec 148 MBytes 1.24 Gbits/sec
[ 5] 1.01-2.01 sec 69.8 MBytes 581 Mbits/sec[ 5] 2.01-3.00 sec 55.0 MBytes 466 Mbits/sec
[ 5] 3.00-4.01 sec 142 MBytes 1.18 Gbits/sec[ 5] 4.01-5.01 sec 117 MBytes 979 Mbits/sec
[ 5] 5.01-6.01 sec 78.9 MBytes 667 Mbits/sec[ 5] 6.01-7.01 sec 145 MBytes 1.21 Gbits/sec
[ 5] 7.01-8.00 sec 77.6 MBytes 658 Mbits/sec[ 5] 8.00-9.01 sec 151 MBytes 1.26 Gbits/sec
[ 5] 9.01-10.01 sec 165 MBytes 1.37 Gbits/sec- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate[ 5] 0.00-10.01 sec 1.12 GBytes 964 Mbits/sec sender
[ 5] 0.00-10.02 sec 1.12 GBytes 957 Mbits/sec receiver |
Thanks, that looks a lot better than mine, That gives me hope it can be improved somehow. I'd be currious how it looks in the evening. Do you know if your backhaul is cityfibre or zen?
For comparison
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
20 | iperf3 -c speedtest.idnet.net
Connecting to host speedtest.idnet.net, port 5201[ 5] local 192.168.1.6 port 50127 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate[ 5] 0.00-1.00 sec 111 MBytes 927 Mbits/sec
[ 5] 1.00-2.00 sec 19.6 MBytes 165 Mbits/sec[ 5] 2.00-3.00 sec 32.1 MBytes 270 Mbits/sec
[ 5] 3.00-4.00 sec 36.1 MBytes 303 Mbits/sec[ 5] 4.00-5.00 sec 51.6 MBytes 433 Mbits/sec
[ 5] 5.00-6.00 sec 29.9 MBytes 251 Mbits/sec[ 5] 6.00-7.00 sec 33.9 MBytes 284 Mbits/sec
[ 5] 7.00-8.00 sec 46.2 MBytes 388 Mbits/sec[ 5] 8.00-9.00 sec 19.0 MBytes 159 Mbits/sec
[ 5] 9.00-10.00 sec 23.6 MBytes 198 Mbits/sec- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate[ 5] 0.00-10.00 sec 403 MBytes 338 Mbits/sec sender
[ 5] 0.00-10.01 sec 399 MBytes 335 Mbits/sec receiver
iperf Done. |
Edited by Croftie2 (Tue 05-Aug-25 14:12:51)
|
|
|
Thanks, that looks a lot better than mine, That gives me hope it can be improved somehow. I'd be currious how it looks in the evening. Do you know if your backhaul is cityfibre or zen?
Im on cityfibre backhaul that goes to Telecity. I believe zen backhaul shows redbus in traceroutes
Ill do some more perfs later during peak hours.
|
|
|
|
Thanks, appreciate it.
|
|
|
In my experience, limited single-threaded throughput is due to low-level packet loss.
TCP treats packet loss as a signal of congestion, and slows down to avoid the network collapse - as it is designed to do.
However, packet loss which is *not* due to congestion will also cause TCP to slow down. Examples include links with low level bit errors, or microbursts of packets overflowing the limited buffer space in some switch in the path.
The formula is here:
https://en.wikipedia.org/wiki/TCP_tuning#Packet_loss
The maximum throughput of a single TCP connection, in bytes per second, is MSS / (RTT * sqrt(Ploss))
If a single stream is limited to 300Mbps with 9ms round-trip time, this formula predicts your packet loss is
(1460/.009/(300000000/8))^2 = .0000187
which is about 1 in 50,000 packets dropped; a very tiny amount of loss indeed.
The TCP throughput you can get goes down as the RTT goes up. This becomes a real problem when doing inter-continental transfers.
Such tiny amounts of packet loss are very hard for the ISP to diagnose, especially as there are all sorts of places this might occur, and it's understandable that the ISP says "there's no problem".
However, iDNet do risk losing their reputation as "top class" service provider if they can't get to the bottom of it, when other ISPs demonstrably perform better. If they're serious about it, they could install perfSonar nodes at various points in their network and measure packet loss between them.
If you really need to upload or download large files at such high rates, the best way to do it is with multiple TCP streams, using a protocol designed for this application, e.g. GridFTP, or even Bittorrent.
Edited by candlerb (Tue 05-Aug-25 14:53:35)
|
|
|
I was hoping you wouldnt ask as I am pretty sure I closed the tab now, I will see if I can find it in my history.
Had a look and there is way too much in my history, I did searches to see if I could weed it out, but nothing sorry.
Bear in mind it could be a partner issue, it could be pppoe, the thread was mainly the user trying to figure things out, then near the end someone blamed idnet as it all started when they moved from one isp to another.
I remember it also saying the issue went away with windows 11, windows 11 has a network stack that resists packet reordering, as well as latest versions of linux. So if you already using windows 11 its not the same problem.
Edited by Chrysalis (Tue 05-Aug-25 16:14:34)
|
|
|
|
4:30PM Seems to be much worse now:
Connecting to host speedtest.idnet.net, port 5201
[ 5] local 192.168.1.63 port 51078 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 48.5 MBytes 405 Mbits/sec
[ 5] 1.00-2.00 sec 36.0 MBytes 302 Mbits/sec
[ 5] 2.00-3.00 sec 44.0 MBytes 370 Mbits/sec
[ 5] 3.00-4.00 sec 26.5 MBytes 221 Mbits/sec
[ 5] 4.00-5.01 sec 46.5 MBytes 389 Mbits/sec
[ 5] 5.01-6.01 sec 41.9 MBytes 351 Mbits/sec
[ 5] 6.01-7.01 sec 44.8 MBytes 374 Mbits/sec
[ 5] 7.01-8.01 sec 49.0 MBytes 412 Mbits/sec
[ 5] 8.01-9.01 sec 46.9 MBytes 392 Mbits/sec
[ 5] 9.01-10.00 sec 33.2 MBytes 282 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 417 MBytes 350 Mbits/sec sender
[ 5] 0.00-10.00 sec 416 MBytes 348 Mbits/sec receiver
|
|
|
Thanks, that looks a lot better than mine, That gives me hope it can be improved somehow. I'd be currious how it looks in the evening. Do you know if your backhaul is cityfibre or zen?
Im on cityfibre backhaul that goes to Telecity. I believe zen backhaul shows redbus in traceroutes
Ill do some more perfs later during peak hours.
I'm fairly sure I'm on Zen backhaul as I'm never affected when CityFibre National has issues, yet a traceroute looks like this:
traceroute to bbc.co.uk (151.101.128.81), 32 hops max, 3 probe packets per hop, 84 byte packets
1 212.69.63.54 <telehouse-gw10.idnet.net> 3.554 ms 3.418 ms 3.456 ms
2 212.69.63.136 <telehouse-gw8.idnet.net> 3.560 ms 3.666 ms 3.623 ms
3 212.69.63.169 <telehouse-gw7.idnet.net> 3.656 ms 3.733 ms 3.535 ms
4 * * *
5 151.101.128.81 <bbc.co.uk> 3.957 ms 3.868 ms 3.847 ms
So I don't really know.
|
|
|
I'm fairly sure I'm on Zen backhaul as I'm never affected when CityFibre National has issues, yet a traceroute looks like this:
That would be Cityfibre National backhaul that you are on.
With zen backhaul your first hop would be something like this: redbus-gw11.idnet.net
|
|
|
|
If CityFibre's business services have a different backhaul then that could explain things, but we've not been hit by any of the National outages.
|
|
|
I can conform on AA via CF I do get 900+ on TBB's upload test.
|
|
|
I can conform on AA via CF I do get 900+ on TBB's upload test.
I was with AAISP with cityfibre but i changed due to the problems they were having with their routers firmwares. Was getting lots of drops in connection, Have they sorted that out now?. If they have i might have to buy out my contract with IDnet and change back to them.
|
|
|
|
No problem thanks for looking. On W10 but will try live booting linux.
|
|
|
|
Thanks yeah that looks like mine does in the day and it's worse than that in the evening. So whatever is causing it is effecting both lines but one more than the other.
|
|
|
I can conform on AA via CF I do get 900+ on TBB's upload test.
Thanks that's good to know.
|
|
|
I was with AAISP with cityfibre but i changed due to the problems they were having with their routers firmwares. Was getting lots of drops in connection, Have they sorted that out now?. If they have i might have to buy out my contract with IDnet and change back to them.
I think those issues are now resolved.
|
|
|
In my experience, limited single-threaded throughput is due to low-level packet loss.
TCP treats packet loss as a signal of congestion, and slows down to avoid the network collapse - as it is designed to do.
However, packet loss which is *not* due to congestion will also cause TCP to slow down. Examples include links with low level bit errors, or microbursts of packets overflowing the limited buffer space in some switch in the path.
The formula is here:
https://en.wikipedia.org/wiki/TCP_tuning#Packet_loss
The maximum throughput of a single TCP connection, in bytes per second, is MSS / (RTT * sqrt(Ploss))
If a single stream is limited to 300Mbps with 9ms round-trip time, this formula predicts your packet loss is
(1460/.009/(300000000/8))^2 = .0000187
which is about 1 in 50,000 packets dropped; a very tiny amount of loss indeed.
The TCP throughput you can get goes down as the RTT goes up. This becomes a real problem when doing inter-continental transfers.
Such tiny amounts of packet loss are very hard for the ISP to diagnose, especially as there are all sorts of places this might occur, and it's understandable that the ISP says "there's no problem".
However, iDNet do risk losing their reputation as "top class" service provider if they can't get to the bottom of it, when other ISPs demonstrably perform better. If they're serious about it, they could install perfSonar nodes at various points in their network and measure packet loss between them.
If you really need to upload or download large files at such high rates, the best way to do it is with multiple TCP streams, using a protocol designed for this application, e.g. GridFTP, or even Bittorrent.
Thanks for that detailed exlpaination, is there anything I can do on my end to identify any issues? The BQM did suddenly show an increase in maximum and bouts of increased avarege latency back in april while with aquiss and about 6 weeks after a swap form GPON to XGS-PON, it's exactly the same on idnet.
It started at about 3PM and I just happened to check the graph shortly after and rebooted the router which did nothing.
April
https://images2.imgbox.com/8d/d0/wB0dJrmA_o.jpg
Live
https://www.thinkbroadband.com/broadband/monitoring/...
I do use a download manager where possible for large transfers but on the upload it's not usually possible for the stuff I use day to day, that's why it's such an issue when the single threaded performance is low, it's not something I'm looking forward to every evening for the next 12 months if it doesn't improve.
idnet is a mature company, I find it hard to believe they don't know the reason and solution for this but choose not to admit it or do anything about it. Perhaps network load for their business customers mostly dictates upgrades, if peak retail load which typically occurs outside business hours can be managed by throttling single threads, something most users wouldn't notice, then it probably saves them a lot of costly upgrades that wouldn't benefit their core business.
My last reply to support was a week ago now and I've not had a reply back. Whatever is going on I just want a resolution or to leave, don't know if I should agree to be swapped to zen backhaul, it might bring it's own problems. Paying for 2350Mbps with only 1-200Mbps actually usable doesn't seem right. It is a shared best efforts service with no guaranteed minimum but come on... that's less than 10%!
|
|
|
is there anything I can do on my end to identify any issues? The BQM did suddenly show an increase in maximum and bouts of increased avarege latency back in april while with aquiss and about 6 weeks after a swap form GPON to XGS-PON, it's exactly the same on idnet.
BQM only sends one packet per second, and can only detect 1%+ of packet loss, which is a grossly high level; it also depends on your router responding consistently to all pings, which not all do.
There's not that much you can do at your end. Well, you *could* install a perfsonar node, and also run perfsonar in a remote data centre somewhere. On the default settings, it sends 10 packets per second, so 36,000 per hour; it might see one packet drop per hour or two in your case. You can crank it up to send more packets. But it is not designed to work behind NAT; it's for network operators who have public IP addresses for everything.
And even then, all you could do is demonstrate the problem. And iDNet are likely to say "that level of packet loss is tiny, it's all working fine, go away".
Perhaps network load for their business customers mostly dictates upgrades, if peak retail load which typically occurs outside business hours can be managed by throttling single threads, something most users wouldn't notice, then it probably saves them a lot of costly upgrades that wouldn't benefit their core business.
As I said before: I think it's not network load (= congestion). I think it's packet loss. Upgrading network capacity is unlikely to make a difference. It may be a bad fibre termination that needs cleaning, or it may be a switch with insufficient buffering, or a bunch of other difficult-to-diagnose conditions.
Other ways to prove this: try a single-thread test to some servers a bit further away, say in Europe, and then further away again, say USA. If you find the single thread speed is inversely proportional to the round-trip time, that's a strong indication of packet loss.
Also, if you find the performance doesn't vary much throughout the day, then that's also a suggestion of packet loss rather than congestion - although some packet loss will be load-related (e.g. microbursts).
My last reply to support was a week ago now and I've not had a reply back. Whatever is going on I just want a resolution or to leave, don't know if I should agree to be swapped to zen backhaul, it might bring it's own problems. Paying for 2350Mbps with only 1-200Mbps actually usable doesn't seem right. It is a shared best efforts service with no guaranteed minimum but come on... that's less than 10%!
But in terms of packets they deliver, they deliver 99.998% of them.
In general it is very hard to get high throughput on TCP except on LANs where the RTT is less than 1ms.
|
|
|
That would be Cityfibre National backhaul that you are on.
With zen backhaul your first hop would be something like this: redbus-gw11.idnet.net
I'm on Zen backhaul, and my traceroute looks like this:
| Text | 1
23
45
67
8 | Tracing route to 151.101.128.81 over a maximum of 30 hops
1 90 ms 1 ms 1 ms 192.168.1.1
2 14 ms 10 ms 10 ms telehouse-gw11.idnet.net [212.69.63.20] 3 12 ms 11 ms 14 ms telehouse-gw8.idnet.net [212.69.63.144]
4 12 ms 11 ms 11 ms telehouse-gw7.idnet.net [212.69.63.169] 5 * * * Request timed out.
6 12 ms 11 ms 11 ms 151.101.128.81 |
Edited by tboorman (Wed 06-Aug-25 12:29:17)
|
|
|
Seems good now, I have had none of these issues since my CF line went live, I activated the CF service I think not long after they rolled back the firmware. There has only been the occasional planned maintenance.
|
|
|
|
Ok thanks, speed to google in london is better than to filefactory in the netherlands both have lowerr speed during the evening.
|
|
|
Your the first person I've seen on zen backhaul via cityfibre. Did you get put on zen backhaul after having speed issues?
Would you mind running iperf preferably via a cable?
| Text | 1
| iperf3 -c speedtest.idnet.net |
My tracroute for comparison in the midlands. Are you north of here?
| Text | 1
23
45
6 | 1 <1 ms <1 ms <1 ms OpenWrt.lan [192.168.1.1]
2 8 ms 6 ms 6 ms telehouse-gw11.idnet.net [212.69.63.20] 3 6 ms 6 ms 6 ms telehouse-gw8.idnet.net [212.69.63.144]
4 6 ms * 7 ms telehouse-gw7.idnet.net [212.69.63.169] 5 8 ms 6 ms 6 ms 5.57.81.59
6 8 ms 6 ms 6 ms 151.101.128.81 |
|
|
|
|
|
|
|
Brill thanks. Looks like packet reordering is the issue. It's suggested to try iperf in udp mode and sure enough speed is higher and stable. Not the best but I'd take it for the remainder of the contract rather than trying to get out of it or moaning for the next 12 months..
UDP
| Text | 1
23
45
67
89
1011
1213
1415
1617
18 | iperf3 -u -c speedtest.idnet.net -b 2500M
Connecting to host speedtest.idnet.net, port 5201[ 5] local 192.168.1.6 port 65096 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams[ 5] 0.00-1.00 sec 82.0 MBytes 688 Mbits/sec 59204
[ 5] 1.00-2.00 sec 82.7 MBytes 694 Mbits/sec 59721[ 5] 2.00-3.00 sec 83.2 MBytes 698 Mbits/sec 60090
[ 5] 3.00-4.00 sec 83.4 MBytes 700 Mbits/sec 60238[ 5] 4.00-5.00 sec 83.3 MBytes 699 Mbits/sec 60158
[ 5] 5.00-6.00 sec 83.8 MBytes 703 Mbits/sec 60500[ 5] 6.00-7.00 sec 83.5 MBytes 701 Mbits/sec 60315
[ 5] 7.00-8.00 sec 83.8 MBytes 703 Mbits/sec 60502[ 5] 8.00-9.00 sec 83.5 MBytes 700 Mbits/sec 60295
[ 5] 9.00-10.00 sec 83.8 MBytes 703 Mbits/sec 60498- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams[ 5] 0.00-10.00 sec 833 MBytes 699 Mbits/sec 0.000 ms 0/601521 (0%) sender
[ 5] 0.00-10.01 sec 831 MBytes 697 Mbits/sec 0.019 ms 1280/601521 (0.21%) receiver |
TCP
| Text | 1
23
45
67
89
1011
1213
1415
1617
18 | iperf3 -c speedtest.idnet.net
Connecting to host speedtest.idnet.net, port 5201[ 5] local 192.168.1.6 port 55753 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate[ 5] 0.00-1.00 sec 142 MBytes 1.19 Gbits/sec
[ 5] 1.00-2.00 sec 36.8 MBytes 307 Mbits/sec[ 5] 2.00-3.00 sec 21.8 MBytes 183 Mbits/sec
[ 5] 3.00-4.00 sec 31.6 MBytes 265 Mbits/sec[ 5] 4.00-5.00 sec 22.9 MBytes 193 Mbits/sec
[ 5] 5.00-6.00 sec 28.4 MBytes 237 Mbits/sec[ 5] 6.00-7.00 sec 41.2 MBytes 346 Mbits/sec
[ 5] 7.00-8.01 sec 33.0 MBytes 274 Mbits/sec[ 5] 8.01-9.00 sec 17.4 MBytes 147 Mbits/sec
[ 5] 9.00-10.00 sec 20.9 MBytes 176 Mbits/sec- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate[ 5] 0.00-10.00 sec 396 MBytes 333 Mbits/sec sender
[ 5] 0.00-10.01 sec 389 MBytes 326 Mbits/sec receiver |
Still need to try a newer OS.
I'll go back to idnet and see what they say. I wonder if the excessive packet reordering is caused when handing over from zen to cityfibre national and moving to zen backhaul would fix it. Although they still have to hand back at the FeX.
|
|
|
|
Apologies for the delayed response.
I'm not on CityFibre, unfortunately - I just wanted to mention that Zen's backhaul does route to IDNet's handover point at Telehouse.
|
|
|
Yeah sorry I couldnt find it the first time, I am curious what Idnet are doing, sadly when it comes to these type of parallel processing feature sets, binding sessions to one path is optional, and the resource gains are lower in that mode. But it also could be down to something unrelated.
How I came across that page I was investigating some reordering issues I believe were affecting me, which turned out it was my Realtek NIC, replaced it with an i210 and the problem vanished, although it was not as extreme as you are witnessing.
I just tried to run the iperf you have been testing with but I am guessing the iperf server is locked down to idnet's ip range which is sensible.
AAISP have one, but I can only run it in tcp mode, it gets 950mbps.
For clarity I am over CityFibre.
Edited by Chrysalis (Sat 09-Aug-25 16:16:30)
|
|
|
UDP Maxes out upload:
| Text | 1
23
45
67
89
1011
1213
| C:\Users\jamie\OneDrive\Desktop\iperf3.19_64>iperf3 -u -c speedtest.idnet.net -b 2500M
Connecting to host speedtest.idnet.net, port 5201[ 5] local 192.168.1.63 port 63405 connected to 212.69.36.111 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams[ 5] 0.00-1.00 sec 284 MBytes 2.37 Gbits/sec 204901
[ 5] 1.00-2.01 sec 285 MBytes 2.37 Gbits/sec 206050[ 5] 2.01-3.01 sec 281 MBytes 2.37 Gbits/sec 202723
[ 5] 3.01-4.01 sec 284 MBytes 2.37 Gbits/sec 204967[ 5] 4.01-5.00 sec 280 MBytes 2.37 Gbits/sec 202304
[ 5] 5.00-6.01 sec 285 MBytes 2.37 Gbits/sec 205616[ 5] 6.01-7.00 sec 281 MBytes 2.37 Gbits/sec 202695
[ 5] 7.00-8.01 sec 285 MBytes 2.37 Gbits/sec 205907[ 5] 8.01-9.00 sec 281 MBytes 2.37 Gbits/sec 202945 |
|
|
|
UDP Maxes out upload:
That's to be expected, bar some gross problem with your router.
However, what would be far more interesting is to run a UDP iperf test at *less* than your maximum speed - say 1Gbps - and measure how many packets arrive compared to the number sent - but I'm not sure if iperf3 will tell you that.
If those are 1500 byte packets then 1Gbps is about 83K packets per second. If you see around 1 packet dropped per second, this is strong confirmation of low-level packet loss at a level which will cause a single TCP stream to back off to the levels you've been seeing.
Then try reducing the packet size to 750 bytes, so you get double the packets per second (~167K packets per second; note that this is increasing the load on your host and router).
If the packet loss doubles, then this implies a packet-level problem, e.g. microbursts overflowing fixed size buffers. If the packet loss stays about the same, then it implies a problem with bit error rate, e.g. a dirty fibre connection (the packets are half the size, so the chance of an individual packet being corrupted is half).
|
|
|
Update: yes, it does tell you packet loss.
Here's a test done at 10M upload (my link is 330/50) on a public iperf3 server:
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
20 | # iperf3 -4 -c speedtest-mer-a.mythic-beasts.com -p 5201-5205 -u -b 10M
Connecting to host speedtest-mer-a.mythic-beasts.com, port 5201[ 5] local 10.12.255.13 port 59431 connected to 93.93.134.56 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams[ 5] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 867
[ 5] 1.00-2.00 sec 1.19 MBytes 9.99 Mbits/sec 866[ 5] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 867
[ 5] 3.00-4.00 sec 1.19 MBytes 10.0 Mbits/sec 867[ 5] 4.00-5.00 sec 1.19 MBytes 10.0 Mbits/sec 867
[ 5] 5.00-6.00 sec 1.19 MBytes 10.0 Mbits/sec 867[ 5] 6.00-7.00 sec 1.19 MBytes 10.0 Mbits/sec 867
[ 5] 7.00-8.00 sec 1.19 MBytes 10.0 Mbits/sec 867[ 5] 8.00-9.00 sec 1.19 MBytes 9.99 Mbits/sec 866
[ 5] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 867- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams[ 5] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.000 ms 0/8668 (0%) sender
[ 5] 0.00-10.04 sec 11.9 MBytes 9.96 Mbits/sec 0.037 ms 0/8667 (0%) receiver
iperf Done. |
Zero lost datagrams is the key indication here, although I don't know why sender and receiver don't exactly agree on the number of datagrams.
I suggest you use the IDNet test server, crank it up to 1G, and see what you get.
|
|
|
No problem thanks for looking. On W10 but will try live booting linux.
Have you tested it using a Linux distro yet?
|
|
|
Post deleted by jalzoo
Edited by jalzoo (Tue 26-Aug-25 00:18:31)
|
|
|
|
Always nice to see my posts elsewhere make it onto other forums.
Yes, the resolution for me was to install Windows 11, as Microsoft never ported the improvements to the TCP stack back to 10, and never plan to.
|
Pages in this thread: 
Print Thread
