Hi Steve - good to read that it’s “sorted” - at least from the point of regaining your original / required performance.

Also it appears that the Openreach side of things is in the clear and it’s down to whatever Zen have altered in their own backhaul. That’s a win really as you can do without any finger pointing in getting to a resolution.

I hope you and Jake keep us in the loop, especially Jake as to how it’s eventually resolved. It’s a very, very unusual issue in how it’s manifesting.

All the best - the crazy /tasty poultry guy 😎🤣

In reply to a post by Pheasant:

the crazy /tasty poultry guy 😎🤣

Seems like we have both been designated new names, yours sounds so much better than mine, the little willy guy 🤣🤣

😜🤣

I'm already not real, so I'll be keeping my name hopefully 👍

I will keep you all informed. Latest news is that they're changing a bit of kit in my exchange on Wednesday night.

No ETA on the following but they're happening ASAP:
Test line at the Openreach lab
Test CPE (presume a fritzbox) with Samknows box in my local exchange, but plugged directly into the Zen end, avoiding Openreach

Update:
Work seems to have taken place last night as scheduled, but speeds are still the same.

In reply to a post by FakeJake:

Test CPE (presume a fritzbox) with Samknows box in my local exchange, but plugged directly into the Zen end, avoiding Openreach

So just a customer router in the handover exchange plugged into their backhaul?

I guess they’re trying a process of elimination, to find where the dropping packets, throttling is occurring. Still not representative of the end to end.

In reply to a post by Pheasant:

I guess they’re trying a process of elimination, to find where the dropping packets, throttling is occurring. Still not representative of the end to end.

Is pathping any use in finding out where packets are being dropped?

There's a PPPoE tunnel that skips out all of the Openreach infrastructure, so it wouldn't show you at what point the problem was.

So, probably less than surprised. I don't know what the common points between us are, but as Brandon Says:

We don’t believe many people are affected, though FakeJake from the forums for sure. There are very few speed complaints into our Tech Support .

Zen therefore believe our problems are at least similar. Could take a time ! I still believe that how the different OS's and TCP stacks handle the errors is interesting, NOT the problem, but pointing us somewhere. Perhaps if we knew WHY they behave so differently, it may guide us forwards?

I also wonder if we are entheusiasts, and maybe other people DO in fact have problems, but just assume it's 'them' perhaps?

Not saying anything more here, but monitoring it all. My connection is now solid, and fine.

Have you tried enabling TCP timestamps. MAC OS I think has this enabled by default, Windows doesn't. The timestamps help TCP update its retransmission timer, and can improve speeds when there are transmission errors, especially on faster connections.

From a command prompt as admin:

Text
1	netsh int tcp set global timestamps=enable

Reboot and see if it can cope with the errors better? You can switch back by running the same command with disable.