FAO managers - appalling uptime, logged 7 times with no fix.
Hello Ian, as you've mentioned that spike on the last two graphs doesn't tie-in with anything in the HH WAN log then as ejs has already mentioned this likely to be the RS not managing to get any data which is what I was already thinking for the same reasons as ejs, not at that time having seen your comment about the log.
As far as the logs go, rather than post those externally on another server - a pain to load on slower connections, also if they get deleted at any point, then someone reading the thread at a later time will find missing info - just do a copy and paste into a post - enclose in the "code" rather than "quote" markers if there's a problem with formatting, that usually sorts it.
As far as the other comments today, the errors are fine, and and there's nothing in the info today that would account for any slowness in connection.
I'm going to take a longer look at some of the SNRM graphs and will post back a bit later.
One quick observation though on your comment in your reply #14
The "repair" (or likely poor repair) is probably top of the suspect list for this problem (subject to spotting anything else when I have a good look at all the data). Plusnet use a BTw product and are therefore connected to the same equipment at the exchange as BT Retail so this won't be anything that's down to an issue at Plusnet - apart from incorrect scripted responses to tickets
As far as the logs go, rather than post those externally on another server - a pain to load on slower connections, also if they get deleted at any point, then someone reading the thread at a later time will find missing info - just do a copy and paste into a post - enclose in the "code" rather than "quote" markers if there's a problem with formatting, that usually sorts it.
As far as the other comments today, the errors are fine, and and there's nothing in the info today that would account for any slowness in connection.
I'm going to take a longer look at some of the SNRM graphs and will post back a bit later.
One quick observation though on your comment in your reply #14
Quote from: ruana62 ........ We had BT in place prior to plusnet, and no issues were experienced. Something I did advise plusnet on several occasions, but failed to specify in my initial forum post, is that the issue started occurring after one particular incident. This was when some local contractors accidentally cut the overhead telephone wires, which was shortly after provisioning plusnet. Openreach resolved the issue after 48 hours. The cut took place around 300 meters down the road and ever since the cut and subsequently, the repairs took place, the issue started occurring.
The "repair" (or likely poor repair) is probably top of the suspect list for this problem (subject to spotting anything else when I have a good look at all the data). Plusnet use a BTw product and are therefore connected to the same equipment at the exchange as BT Retail so this won't be anything that's down to an issue at Plusnet - apart from incorrect scripted responses to tickets
OK, I've had a good read through and looked at the graphs, with multiple interruptions , so I hope I haven't missed anything. I guess the best place to start maybe to recap and try and get an overview of how things are currently.
In your OP you mentioned that the DSL doesn't drop very much since the Target SNRM has been raised. Just for the record, as far as you know, did all/most of the periods of non-usability end up with or coincide with a drop of sync previously?
Are the current periods of non-usability as frequent now as before, you mentioned several times a day previously, but are they as infrequent as the PPP losses shown on the Vis.Radius graph (reply #17)?
Are the drops in sync now consistent with the drops shown on the PPP Vis.Radius? As far as I can tell from the HH logs, that seems so.
If I've understood things correctly, I believe 4 different modem/routers have been tried, the original Plusnet TG582n?, your N55U, a HH4 and now an HH3 and the issue been seen by your mother was a significant slowdown or cessation in webpage loading ability, and your investigations showed that when this occurred you had very long pings, speedtest.net not loading, and losses of sync on most occasions?
Looking in more detail at the graphs - the large spikes on the Upstream noise - first those spikes down appear to be exactly the same value each time, and the spikes up appear to be one of two (close) values each time (might be able to confirm that from the RS log).
My inclination, also noting the comment by ejs, is that these could well be some data gathering issue.
As mentioned by Townman, we don't have experience with how RS works with HHs, but as also mentioned RS can have other data gathering issues when the graphs will drop to zero momentarily - this often occurs when your computer CPU has very high or 100% usage on other tasks.
You can usually confirm these instances by looking at both the SNRM and Sync speed graphs where the drops will be simultaneous and the sync speed plot then carries on with no change of speed.
In cases of a real loss of sync it's very unusual for the sync on both US and DS to resync at exactly the same previous speeds and the gap will be longer because of the time taken to resync.
Don't despair with these bugs, a lot of monitoring tools have pluses and minuses. The RSHub uses a different engine from the other versions, so we aren't familiar with it. Is it possible to plot any of the sync speeds on the same graphs as the SNRM? A right click on the graph usually shows the options (I haven't read the Help for the HH version).
Is it possible to get the graphs to save with a relevant name eg Rx_Sync_Speed_(Kbps)-2015Jan27-0200.jpg ? Makes it easier to relate to especially when looking at a selection. (Check the graph configuration tabs).
Where there may be spikes or steps in the SNRM it can often be useful to see the effect (if any) on the sync speed, or at least state there was none. Also when posting stats, posting a complete set gives a better overall picture eg. Uptime, Speed, SNRM, Attenuation & any error data, rather than just selected extracts.
Looking at graph PS10.jpg and the event at ~1106 to ~1111, whether this is down to Cross-Talk or REIN of some sort, is difficult to say at this point - it certainly is something switching on or being used and then switching off or stopped. It could be anything like a phone being used on another line on the same DP, maybe a mobile being used nearby, a TV set or monitor being used for a short period, or any number of electronic or electrical devices.
Just a hint or two when you are trying to check if any household items may be causing SHINE - things like fridges & freezers - it won't usually be the motor starting that causes an issue (unless faulty) it's normally the thermostat that doesn't make or break cleanly or failing suppression, same with immersions - not that there's any evidence of this type of SHINE at present. As far as REIN is concerned there is all sorts of discharge lighting, anything running off a switch-mode PSU including low-voltage halogen lighting, LED lighting, TV sets, Monitors, Set-top boxes, motors that have brushes to name but a few.
As mentioned, posting graphs and full stats gives a more complete picture. Unless you are seeing a prolonged period (more than a few seconds) ie minutes + where webpages aren't loading then pings and tracerts are unlikely to yield anything useful but when it is prolonged a tracert and/or ping to one of Plusnet's DNS/NTP servers could be handy - ntp.plus.net - this minimises the risk of delays due external routers, but also run the BTw Performance test (DON'T REBOOT, ignore the red preamble except make sure no other programs are using the Internet).
At the moment I'm guessing that you may have been seeing some REIN previously as Townman was also thinking, also that it was initially seen when using the TG582n? and with the lower Target SNRM at that time, REIN could have reduced the SNRM so low that the CRC count would have risen dramatically and with the repeated retransmission of data, pings would increase and throughput drop.
I have a few further ideas depending on how its all progressing, but a couple of closing thoughts at this time -
To avoid any confusion, sorry if it seems to be nit-picking, you referred to "calls" on several occasions, when clearly you have called Plusnet, but you are actually "Raising a Fault" as a consequence, and this results in a "Ticket" as they are commonly called (formal name is a "Question"). These Tickets, when passed back to the end-user, ie not waiting a Plusnet response, will automatically close within 14 days if no further response is made -so you need to keep putting some sort of update on them to keep them running in these circumstances.
I also noted in the HH log the following entries during the PPP authentication (similar on other days/times) -
11:17:54, 28 May. (402188.970000) ETHoA is up - VPI: 0, VCI:35
eventually followed by
11:17:58, 28 May. (402193.240000) PPPoA is up - VPI: 0, VCI:38
How weird that it should do so in that manner - another reason for me to dislike HHs
Edit: due to a gremlin, most of the above got posted before I'd finished, but I've now added what I'd originally intended..
, so I hope I haven't missed anything. I guess the best place to start maybe to recap and try and get an overview of how things are currently.In your OP you mentioned that the DSL doesn't drop very much since the Target SNRM has been raised. Just for the record, as far as you know, did all/most of the periods of non-usability end up with or coincide with a drop of sync previously?
Are the current periods of non-usability as frequent now as before, you mentioned several times a day previously, but are they as infrequent as the PPP losses shown on the Vis.Radius graph (reply #17)?
Are the drops in sync now consistent with the drops shown on the PPP Vis.Radius? As far as I can tell from the HH logs, that seems so.
If I've understood things correctly, I believe 4 different modem/routers have been tried, the original Plusnet TG582n?, your N55U, a HH4 and now an HH3 and the issue been seen by your mother was a significant slowdown or cessation in webpage loading ability, and your investigations showed that when this occurred you had very long pings, speedtest.net not loading, and losses of sync on most occasions?
Looking in more detail at the graphs - the large spikes on the Upstream noise - first those spikes down appear to be exactly the same value each time, and the spikes up appear to be one of two (close) values each time (might be able to confirm that from the RS log).
My inclination, also noting the comment by ejs, is that these could well be some data gathering issue.
As mentioned by Townman, we don't have experience with how RS works with HHs, but as also mentioned RS can have other data gathering issues when the graphs will drop to zero momentarily - this often occurs when your computer CPU has very high or 100% usage on other tasks.
You can usually confirm these instances by looking at both the SNRM and Sync speed graphs where the drops will be simultaneous and the sync speed plot then carries on with no change of speed.
In cases of a real loss of sync it's very unusual for the sync on both US and DS to resync at exactly the same previous speeds and the gap will be longer because of the time taken to resync.
Don't despair with these bugs, a lot of monitoring tools have pluses and minuses. The RSHub uses a different engine from the other versions, so we aren't familiar with it. Is it possible to plot any of the sync speeds on the same graphs as the SNRM? A right click on the graph usually shows the options (I haven't read the Help for the HH version).
Is it possible to get the graphs to save with a relevant name eg Rx_Sync_Speed_(Kbps)-2015Jan27-0200.jpg ? Makes it easier to relate to especially when looking at a selection. (Check the graph configuration tabs).
Where there may be spikes or steps in the SNRM it can often be useful to see the effect (if any) on the sync speed, or at least state there was none. Also when posting stats, posting a complete set gives a better overall picture eg. Uptime, Speed, SNRM, Attenuation & any error data, rather than just selected extracts.
Looking at graph PS10.jpg and the event at ~1106 to ~1111, whether this is down to Cross-Talk or REIN of some sort, is difficult to say at this point - it certainly is something switching on or being used and then switching off or stopped. It could be anything like a phone being used on another line on the same DP, maybe a mobile being used nearby, a TV set or monitor being used for a short period, or any number of electronic or electrical devices.
Just a hint or two when you are trying to check if any household items may be causing SHINE - things like fridges & freezers - it won't usually be the motor starting that causes an issue (unless faulty) it's normally the thermostat that doesn't make or break cleanly or failing suppression, same with immersions - not that there's any evidence of this type of SHINE at present. As far as REIN is concerned there is all sorts of discharge lighting, anything running off a switch-mode PSU including low-voltage halogen lighting, LED lighting, TV sets, Monitors, Set-top boxes, motors that have brushes to name but a few.
As mentioned, posting graphs and full stats gives a more complete picture. Unless you are seeing a prolonged period (more than a few seconds) ie minutes + where webpages aren't loading then pings and tracerts are unlikely to yield anything useful but when it is prolonged a tracert and/or ping to one of Plusnet's DNS/NTP servers could be handy - ntp.plus.net - this minimises the risk of delays due external routers, but also run the BTw Performance test (DON'T REBOOT, ignore the red preamble except make sure no other programs are using the Internet).
At the moment I'm guessing that you may have been seeing some REIN previously as Townman was also thinking, also that it was initially seen when using the TG582n? and with the lower Target SNRM at that time, REIN could have reduced the SNRM so low that the CRC count would have risen dramatically and with the repeated retransmission of data, pings would increase and throughput drop.
I have a few further ideas depending on how its all progressing, but a couple of closing thoughts at this time -
To avoid any confusion, sorry if it seems to be nit-picking, you referred to "calls" on several occasions, when clearly you have called Plusnet, but you are actually "Raising a Fault" as a consequence, and this results in a "Ticket" as they are commonly called (formal name is a "Question"). These Tickets, when passed back to the end-user, ie not waiting a Plusnet response, will automatically close within 14 days if no further response is made -so you need to keep putting some sort of update on them to keep them running in these circumstances.
I also noted in the HH log the following entries during the PPP authentication (similar on other days/times) -
11:17:54, 28 May. (402188.970000) ETHoA is up - VPI: 0, VCI:35
eventually followed by
11:17:58, 28 May. (402193.240000) PPPoA is up - VPI: 0, VCI:38
How weird that it should do so in that manner - another reason for me to dislike HHs
Edit: due to a gremlin, most of the above got posted before I'd finished, but I've now added what I'd originally intended..
Hi Ian, I assume from what you've said that there's no matching SNRM graph to PS13 which is odd.
A bug with the non-HH version of RS often shows 0 on the plots & logs for everything except Uptime and Attenuation if for some reason it stops plotting properly. The usual cure is to press the black Stop/Pause button and then straight away press the Green Start Arrow button. Sometimes it restarts at some random time later by itself.
The offline 0445-0630 might have been BT maintenance somewhere on the backhaul if it was simply you couldn't access the HH?
I also assume from what you are saying that the "no connection" means you can't browse or connect to Plusnet, because there would seem to be sync from what the graphs and logs are showing.
But looking at the logs, the WAN one being very limited, but it shows some unusual behaviour -
From 1748 to 1753 there seems to be issues with 'PPP IPCP Receive Configuration Request' , 'PPP IPCP Send Configuration ACK' and 'PPP IPCP Send Configuration Request' and then eventually 'PPPoA is down after 6 minutes uptime [Disconnected]'
Then at 1755 'PPP LCP Send Configuration Request' (twice) and a similar pattern to previously interspersed with 'Starting CHAP authentication with peer' and 'CHAP Receive Challenge'
Eventually 'PPPoA is up - VPI:0, VCI:38' but goes down again 'PPPoA is down after 1 minutes uptime [Reconnecting...]'
And the whole lot repeats with minor variation until 1811 when there is nearly a 5 minute gap before the next entry at 1816
Obviously some issues trying to establish a PPP session. Meanwhile the RS log stopped at 1805 (restarted at 1832 different DS sync speed).
A further different sync speed appeared to be present at 1817 from the WAN log. I don't know if you will subsequently have any graphs showing all that.
Clearly sync dropped sometime between 1817 and 1832.
On the assumption that nothing was being done to the HH (rebooting or whatever) during that time, then clearly this demonstrates an exchange issue (from the PPP evidence as well as the sync) or the HH3 is faulty. That said, if this particular pattern from your mother's point of view, is similar to what's been seen before, that puts the balance towards an exchange issue. (Leaving aside the fact that it appears to have been down all day).
The RS logs support what its sync speed graph (PS13) is showing earlier in the day.
As far as the logs (I can see the size issue - 50000 characters limit) and Pastebin are concerned, although I had no trouble downloading this time (different machine & browser - have to check the other out) Pastebin is still a problem in that the information will probably disappear at some future point. What I've done is copy each log from Pastebin (obviously you can do it direct from RS or the HH) and pasted in a text file which I've then printed to a pdf and attached to this post. Perhaps you could try that another time?
One point, probably not worth printing/posting the whole RS log (especially where there's graphs of the same data) but edit out the lines where there's no (significant) change in data - sync speed especially but jumps in SNRM - and replace with a few dots. That'll reduce the size as well as improved readability when looking for key changes. (btw I sent you a PM - see 'My Messages' in the middle of the forum menu bar).
Back to the actual events and graphs, the first thing I noticed from your last post, was the change in US SNRM - that made me immediately think the US sync was now capped/banded and checking it certainly is (440kbps). The fact that the DS sync speed has not got worse suggests that maybe the line has been reset with a capped upstream
- I'd suggest you go and check your ticket for any update from the faults team to see what they may have been upto.
In view of all that appears to have gone on with RS and the connection and some of this weird behaviour, I'm not quite sure what data I'd put total trust in at present, apart from sync speed and SNRM values.
If you could check (if that's possible) that you haven't set RS to reboot the HH if it sees an alarm event or anything just to be certain RS isn't causing an issue.
Also if you are satisfied this behaviour is similar to previously, the TG582n gives better stats data and RS graphing capability than appears to be the case with the HH3, so the next time you go to your mothers if you could put it back online and re-setup RS for it, further similar evidence would certainly prove the issue. (One tip on that, rename the current Routerstats.ini file so it will start with a fresh one - sometimes when changing modem/routers an old file can get in a mess and cause gremlins).
A bug with the non-HH version of RS often shows 0 on the plots & logs for everything except Uptime and Attenuation if for some reason it stops plotting properly. The usual cure is to press the black Stop/Pause button and then straight away press the Green Start Arrow button. Sometimes it restarts at some random time later by itself.
The offline 0445-0630 might have been BT maintenance somewhere on the backhaul if it was simply you couldn't access the HH?
I also assume from what you are saying that the "no connection" means you can't browse or connect to Plusnet, because there would seem to be sync from what the graphs and logs are showing.
But looking at the logs, the WAN one being very limited, but it shows some unusual behaviour -
From 1748 to 1753 there seems to be issues with 'PPP IPCP Receive Configuration Request' , 'PPP IPCP Send Configuration ACK' and 'PPP IPCP Send Configuration Request' and then eventually 'PPPoA is down after 6 minutes uptime [Disconnected]'
Then at 1755 'PPP LCP Send Configuration Request' (twice) and a similar pattern to previously interspersed with 'Starting CHAP authentication with peer' and 'CHAP Receive Challenge'
Eventually 'PPPoA is up - VPI:0, VCI:38' but goes down again 'PPPoA is down after 1 minutes uptime [Reconnecting...]'
And the whole lot repeats with minor variation until 1811 when there is nearly a 5 minute gap before the next entry at 1816
Obviously some issues trying to establish a PPP session. Meanwhile the RS log stopped at 1805 (restarted at 1832 different DS sync speed).
A further different sync speed appeared to be present at 1817 from the WAN log. I don't know if you will subsequently have any graphs showing all that.
Clearly sync dropped sometime between 1817 and 1832.
On the assumption that nothing was being done to the HH (rebooting or whatever) during that time, then clearly this demonstrates an exchange issue (from the PPP evidence as well as the sync) or the HH3 is faulty. That said, if this particular pattern from your mother's point of view, is similar to what's been seen before, that puts the balance towards an exchange issue. (Leaving aside the fact that it appears to have been down all day).
The RS logs support what its sync speed graph (PS13) is showing earlier in the day.
As far as the logs (I can see the size issue - 50000 characters limit) and Pastebin are concerned, although I had no trouble downloading this time (different machine & browser - have to check the other out) Pastebin is still a problem in that the information will probably disappear at some future point. What I've done is copy each log from Pastebin (obviously you can do it direct from RS or the HH) and pasted in a text file which I've then printed to a pdf and attached to this post. Perhaps you could try that another time?
One point, probably not worth printing/posting the whole RS log (especially where there's graphs of the same data) but edit out the lines where there's no (significant) change in data - sync speed especially but jumps in SNRM - and replace with a few dots. That'll reduce the size as well as improved readability when looking for key changes. (btw I sent you a PM - see 'My Messages' in the middle of the forum menu bar).
Back to the actual events and graphs, the first thing I noticed from your last post, was the change in US SNRM - that made me immediately think the US sync was now capped/banded and checking it certainly is (440kbps). The fact that the DS sync speed has not got worse suggests that maybe the line has been reset with a capped upstream
- I'd suggest you go and check your ticket for any update from the faults team to see what they may have been upto.In view of all that appears to have gone on with RS and the connection and some of this weird behaviour, I'm not quite sure what data I'd put total trust in at present, apart from sync speed and SNRM values.
If you could check (if that's possible) that you haven't set RS to reboot the HH if it sees an alarm event or anything just to be certain RS isn't causing an issue.
Also if you are satisfied this behaviour is similar to previously, the TG582n gives better stats data and RS graphing capability than appears to be the case with the HH3, so the next time you go to your mothers if you could put it back online and re-setup RS for it, further similar evidence would certainly prove the issue. (One tip on that, rename the current Routerstats.ini file so it will start with a fresh one - sometimes when changing modem/routers an old file can get in a mess and cause gremlins).
It seems that after today issues, plusnet are sending an engineer out.
RADIUS: NOT CONNECTED
17 drops in last 24 hours
39 drops in last 72 hours
0 of 164 (0%) User Req Drops in last 7 days
WBC 160K - 24M Medium delay (INP 1) 6dB Downstream, 448 Medium delay (INP 2) 6dB Upstream (ADSL2+)
xDSL Status Check
Circuit ID: CBUKxxxxxxxx Service ID: BBEUxxxxxxxx
Telephone NO.: NA Test Executed On: 02-06-2015 12:15:27
xDSL Status Test Summary
Sync Status: Circuit In Sync
General Information
NTE Status: NTE Power Status: PowerOn Bypass Status:
Upstream DSL Link Information Downstream DSL Link Information
Loop Loss: 15.6 27.5
SNR Margin: 29.0 6.0
Errored Seconds: 0 1
HEC Errors: 0
Cell Count: 6996 7102
Speed: 440 15748
Maximum Stable Rate (KBPS): 14752 Fault Threshold Rate (KBPS): 11802
Mean Time Between Retrains (Seconds): 86400 Mean Time Between Errors Upstream (Seconds): 298
Indicative Line Quality: G Mean Time Between Errors Downstream (Seconds): 1042
CLT - pass
Raised.
RADIUS: NOT CONNECTED
17 drops in last 24 hours
39 drops in last 72 hours
0 of 164 (0%) User Req Drops in last 7 days
WBC 160K - 24M Medium delay (INP 1) 6dB Downstream, 448 Medium delay (INP 2) 6dB Upstream (ADSL2+)
xDSL Status Check
Circuit ID: CBUKxxxxxxxx Service ID: BBEUxxxxxxxx
Telephone NO.: NA Test Executed On: 02-06-2015 12:15:27
xDSL Status Test Summary
Sync Status: Circuit In Sync
General Information
NTE Status: NTE Power Status: PowerOn Bypass Status:
Upstream DSL Link Information Downstream DSL Link Information
Loop Loss: 15.6 27.5
SNR Margin: 29.0 6.0
Errored Seconds: 0 1
HEC Errors: 0
Cell Count: 6996 7102
Speed: 440 15748
Maximum Stable Rate (KBPS): 14752 Fault Threshold Rate (KBPS): 11802
Mean Time Between Retrains (Seconds): 86400 Mean Time Between Errors Upstream (Seconds): 298
Indicative Line Quality: G Mean Time Between Errors Downstream (Seconds): 1042
CLT - pass
Raised.
Just an update with graphs from this afternoon/evening - This last incident is rather extended compared to normal.
Anotherone - the HH version of RS doesn't seem to have the option to reboot the router if it shows downtime - you actually have to navigate manually to the connection page within the app to get the stats running - seems oldschool
The issue with the connection in the morning was spotted by my mother when she realised there was no internet access at 4:45AM (what was she doing up so early!? )
The end of the WAN log where it reads 'Limit of wan log' is in the HH itself - It would appear that it had so many of those repetitive logs every couple of seconds/minutes that it ran out of flash space!
There are no notes on the ticket that suggest the upstream has been capped - I remember specifically requesting it to be uncapped when the line was provisioned - not sure why they cap it in the first place?
I'll put the tg582n in next time I'm there (Saturday) - I'm going to get an earful as despite there being no other WiFi networks in range, that router only covers 50% of the property. They did quite like the signal quality of my N55U but there's no chance they're getting to keep that I'll need it for when I upgrade my HOME connection to a GIGABIT line in a few weeks - yeah you heard right!! GIGABIT! 
Thanks
Ian
Anotherone - the HH version of RS doesn't seem to have the option to reboot the router if it shows downtime - you actually have to navigate manually to the connection page within the app to get the stats running - seems oldschool
The issue with the connection in the morning was spotted by my mother when she realised there was no internet access at 4:45AM (what was she doing up so early!?
)The end of the WAN log where it reads 'Limit of wan log' is in the HH itself - It would appear that it had so many of those repetitive logs every couple of seconds/minutes that it ran out of flash space!
There are no notes on the ticket that suggest the upstream has been capped - I remember specifically requesting it to be uncapped when the line was provisioned - not sure why they cap it in the first place?
I'll put the tg582n in next time I'm there (Saturday) - I'm going to get an earful as despite there being no other WiFi networks in range, that router only covers 50% of the property. They did quite like the signal quality of my N55U but there's no chance they're getting to keep that
I'll need it for when I upgrade my HOME connection to a GIGABIT line in a few weeks - yeah you heard right!! GIGABIT! Thanks
Ian
Quote from: ruana62 I'll need it for when I upgrade my HOME connection to a GIGABIT line in a few weeks - yeah you heard right!! GIGABIT!
I'll post back a bit more shortly
Kevin, apart from the fact that we could wait all day for CRT to answer some of those queries, it's pretty obvious that the chart is misrepresenting the the PPP connection status where is says "No connection for 15 days".
The "Close" marker does not mean a clean / controlled session close message was received, it simply means that the PPP session ceased. They need to look at the detail Radius log to see if it states the precise reason - I know it can log the "user request" but that's not what we have here
Do "gracefully dying gasph session close out" signals actually exist?
I've never known "session close being generated somewhere in the BT Infrastructure?" to ever have happened. When the "backhaul" or other parts of the network are taken down for maintenance, it just goes down. Depending on the precise way it went down, in quite a few instances, it has required a reboot to get a connection established again - I've experienced that with a few different modem/routers (all BCM based FYI but not necessarily relevant).
To repeat, the "Plots" do NOT indicate "graceful PPP session closures".
Nor do they necessarily indicate a loss of sync, and conversely there can be losses of sync without there being a loss of PPP session when sync has been lost by the momentary loss of US sync and then sync being re-established.
I don't know what additional "evidence" Ian may have, but I'd guess from his "remoteness" to the connection and from what he has posted, including his comments, there's probably not much more. Most of it is based on his mother's and his own experience with the connection using a variety of modem/routers.
As I pointed out in reply #37, the WAN log and sync speeds in the RS log (as well as the graphs) show changes in sync speed and so quite obviously losses of sync.
Also as I pointed out in reply #37, the problems associated with establishing a PPP session as well as the sync issue suggest an exchange problem or with the specifics in this recent example, a problem with the HH3. However, I'm very mindful of the fact that problems were seen with the other modem/routers and therefore inclined to suspect the fault lies at the exchange.
@ian
I'd guess you are unlikely to be present when the engineer comes, so it would be best to ensure that your mother makes it crystal clear to the engineer that the problems with not being able to browse have been seen with 4 different modem/routers and the most recent evidence shows a problem not being able to get a PPP session established even when there hasn't been sync loss which also occurs.
IMHO, a full Lift and Shift is what should be tried (but depending on when the engineer is coming a Port reset - remote job - could be tried first to see if it solves things).
Edit: I guess I could have made it clearer in terms of additional evidence Plusnet will have PPP/Radius logs as well as Delta Reports & xDSL status checks. My brain is a bit addled with other issues at the moment but there's other info you can get from KBD.
The "Close" marker does not mean a clean / controlled session close message was received, it simply means that the PPP session ceased. They need to look at the detail Radius log to see if it states the precise reason - I know it can log the "user request" but that's not what we have here
Quote from: Townman Does this imply that routers are getting a gracefully dying gasph session close out or is session close being generated somewhere in the BT Infrastructure?
Do "gracefully dying gasph session close out" signals actually exist?
I've never known "session close being generated somewhere in the BT Infrastructure?" to ever have happened. When the "backhaul" or other parts of the network are taken down for maintenance, it just goes down. Depending on the precise way it went down, in quite a few instances, it has required a reboot to get a connection established again - I've experienced that with a few different modem/routers (all BCM based FYI but not necessarily relevant).
To repeat, the "Plots" do NOT indicate "graceful PPP session closures".
Nor do they necessarily indicate a loss of sync, and conversely there can be losses of sync without there being a loss of PPP session when sync has been lost by the momentary loss of US sync and then sync being re-established.
Quote from: Townman "Do the records point to a cause?"
"Is there evidence of associated resynchs?"
A PPP drop without a loss of synch rather points away from a line issue, but I do not know where - and you might need to get the engineer to think about that too!
Kevin
I don't know what additional "evidence" Ian may have, but I'd guess from his "remoteness" to the connection and from what he has posted, including his comments, there's probably not much more. Most of it is based on his mother's and his own experience with the connection using a variety of modem/routers.
As I pointed out in reply #37, the WAN log and sync speeds in the RS log (as well as the graphs) show changes in sync speed and so quite obviously losses of sync.
Also as I pointed out in reply #37, the problems associated with establishing a PPP session as well as the sync issue suggest an exchange problem or with the specifics in this recent example, a problem with the HH3. However, I'm very mindful of the fact that problems were seen with the other modem/routers and therefore inclined to suspect the fault lies at the exchange.
@ian
I'd guess you are unlikely to be present when the engineer comes, so it would be best to ensure that your mother makes it crystal clear to the engineer that the problems with not being able to browse have been seen with 4 different modem/routers and the most recent evidence shows a problem not being able to get a PPP session established even when there hasn't been sync loss which also occurs.
IMHO, a full Lift and Shift is what should be tried (but depending on when the engineer is coming a Port reset - remote job - could be tried first to see if it solves things).
Edit: I guess I could have made it clearer in terms of additional evidence Plusnet will have PPP/Radius logs as well as Delta Reports & xDSL status checks. My brain is a bit addled with other issues at the moment but there's other info you can get from KBD.
AFAIK the Vis.Rad was designed to be a simple graphical tool to show whether a PPP session was present or not, when a session started and when one ended. I think you as trying to read more into what it currently gives. I'm not clear though, on when the "Connection Failed" flag is designed to appear and the above VR is one of the few where I've seen it crop up, but certainly not as many times as on that one 
It should also be noted that in a lot of instances the drop shown on the VR is also accompanied by a loss of sync, but not always and further data should be checked.
That is certainly a very valid point, but it's been raised before but I don't see any evidence that indicates things have changed by en large. On too many occasions losses of sync have not been checked because the VR hasn't shown a drop. As I mentioned in a previous post eg., if the loss in sync is due to an initial loss of upstream sync and the US & DS sync is re-established well within normal sync times, then there's usually no loss of PPP session and hence no change of IP address or change of Gateway. Too many inexperienced CSC agents do not check things like Delta reports etc to see if sync was lost when a user has reported drops in connection. I'm not suggesting that has been happening here - insufficient evidence.
(I look forward to hearing about the billion elsewhere).
It should also be noted that in a lot of instances the drop shown on the VR is also accompanied by a loss of sync, but not always and further data should be checked.
Quote from: Townman The question to CRT (whenever answered) is a prompt for a reflection on the potential to mis read a diagnostics report by which a great deal of "store" is made.
That is certainly a very valid point, but it's been raised before but I don't see any evidence that indicates things have changed by en large. On too many occasions losses of sync have not been checked because the VR hasn't shown a drop. As I mentioned in a previous post eg., if the loss in sync is due to an initial loss of upstream sync and the US & DS sync is re-established well within normal sync times, then there's usually no loss of PPP session and hence no change of IP address or change of Gateway. Too many inexperienced CSC agents do not check things like Delta reports etc to see if sync was lost when a user has reported drops in connection. I'm not suggesting that has been happening here - insufficient evidence.
(I look forward to hearing about the billion elsewhere).