Superzoom speed problem
OK, I'll go through the fault reporter, then, if that's what you need.
It isn't a problem with the line, though. It's an issue either with equipment in the exchange or the connection from there onwards, and is clearly affecting BT retail connections as well. None of that stuff is visible to me, however.
It doesn't seem to be specifically congestion-related, unless to the extent that temporary BTw routing changes have forced everything down one too-narrow pipe.
EDIT: Fault raised. Surprisingly enough, changing the microfilters didn't help
It isn't a problem with the line, though. It's an issue either with equipment in the exchange or the connection from there onwards, and is clearly affecting BT retail connections as well. None of that stuff is visible to me, however.
It doesn't seem to be specifically congestion-related, unless to the extent that temporary BTw routing changes have forced everything down one too-narrow pipe.
EDIT: Fault raised. Surprisingly enough, changing the microfilters didn't help
Thanks both. Much appreciated.
I've just replied to your ticket update, Dave. Thanks for the graph, it does look telling.
The forum just timed out again getting in here to reply...
I do hope it can all be fixed before it becomes quicker to ask ThinkBroadband to send me their download zip files by courier!
I've just replied to your ticket update, Dave. Thanks for the graph, it does look telling.
The forum just timed out again getting in here to reply...
I do hope it can all be fixed before it becomes quicker to ask ThinkBroadband to send me their download zip files by courier!
Run the first test connected wirelessly to the router using 802.11b?
Love the impressively creative circumvention suggestions!
PlusNet have very efficiently arranged for an Openreach engineer to come tomorrow morning. I doubt that will help in itself, but it is apparently necessary to progress things...
Some might be interested to take a look at the attached TCP stream summary, which is just the HTML of a web page being downloaded. Note that the delay before getting the 200 OK response may not be significant here - it isn't the interesting feature, and could easily be down to the server in this case (although other testing has suggested that that is a point in the transfer at which latency is highly variable when it is very unlikely to be the remote server causing the effect).
PlusNet have very efficiently arranged for an Openreach engineer to come tomorrow morning. I doubt that will help in itself, but it is apparently necessary to progress things...
Some might be interested to take a look at the attached TCP stream summary, which is just the HTML of a web page being downloaded. Note that the delay before getting the 200 OK response may not be significant here - it isn't the interesting feature, and could easily be down to the server in this case (although other testing has suggested that that is a point in the transfer at which latency is highly variable when it is very unlikely to be the remote server causing the effect).
The engineers visit was certainly 'interesting'...
A small Openreach error prior to the engineer's arrival (totally unrelated to the issue) led to a complete loss of internet connectivity for basically the whole of Saturday!
It should have been straightforward to recover from, but it seems the FTTP specialists at the BT engineering call centre don't work weekends, so the swtich-it-off-and-on-and-off-and-on-and-replace-all-the-equipment-even-if-there-is-no-indication-it-is-faulty method of troubleshooting applied to getting service restored. Comforting to know that Openreach engineers have to suffer that sort of thing themselves, I suppose. Four hours of being told to switch the router off an on again even though the log clearly said "Timeout waiting for PADO" is enough to drive a very patient engineer mad, I can tell you.
Anyway, as a result of all this, the ONT has now been swapped for a brand new one (unnecessarily in the sense that it wasn't faulty, it was just the easiest way to get a new serial number to build against) and the VLAN rebuilt entirely from scratch (multiple times!)
So we can definitively say that there is no fault whatsoever with the line. Not that there ever was. Except that latency has gone up by 1ms since the connection was restored. That's probably BTw fiddling around with something else, though. Not so long ago I was getting 3ms to the BBC. Then it went to 4ms. Now it's 5. Where does all the time go, hey?
I've got a little tidbit for you, though, Andy. The engineer was able to tell me that the optical loop loss for our fibre path is currently 14.14dB. Miles within budget and entirely irrelevant to the problem, but a juicy stat nonetheless
Throughput today is back up to 89.69Mbps and cached DNS lookups from PlusNet's servers 7.something ms - reflecting the increased base latency.
Not terribly revealing metrics re. www responsiveness, but may as well post it for the record. It's useful to be able to review how things develop.
Rumour has it that if BT need to add a bit of latency into the path for whatever reason, they are not above connecting up a few thousand metres of extra fibre in a corner of the exchange! So you never know what's really going on.
A small Openreach error prior to the engineer's arrival (totally unrelated to the issue) led to a complete loss of internet connectivity for basically the whole of Saturday!
It should have been straightforward to recover from, but it seems the FTTP specialists at the BT engineering call centre don't work weekends, so the swtich-it-off-and-on-and-off-and-on-and-replace-all-the-equipment-even-if-there-is-no-indication-it-is-faulty method of troubleshooting applied to getting service restored. Comforting to know that Openreach engineers have to suffer that sort of thing themselves, I suppose. Four hours of being told to switch the router off an on again even though the log clearly said "Timeout waiting for PADO" is enough to drive a very patient engineer mad, I can tell you.
Anyway, as a result of all this, the ONT has now been swapped for a brand new one (unnecessarily in the sense that it wasn't faulty, it was just the easiest way to get a new serial number to build against) and the VLAN rebuilt entirely from scratch (multiple times!)
So we can definitively say that there is no fault whatsoever with the line. Not that there ever was. Except that latency has gone up by 1ms since the connection was restored. That's probably BTw fiddling around with something else, though. Not so long ago I was getting 3ms to the BBC. Then it went to 4ms. Now it's 5. Where does all the time go, hey?
I've got a little tidbit for you, though, Andy. The engineer was able to tell me that the optical loop loss for our fibre path is currently 14.14dB. Miles within budget and entirely irrelevant to the problem, but a juicy stat nonetheless
Throughput today is back up to 89.69Mbps and cached DNS lookups from PlusNet's servers 7.something ms - reflecting the increased base latency.
Not terribly revealing metrics re. www responsiveness, but may as well post it for the record. It's useful to be able to review how things develop.
Rumour has it that if BT need to add a bit of latency into the path for whatever reason, they are not above connecting up a few thousand metres of extra fibre in a corner of the exchange! So you never know what's really going on.