connection graph

[#1]

router now factory restored and configured again
Uptime: 0 days, 0:18:26
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,038 / 14,332
Data Transferred (Sent/Received) [MB/MB]: 1.41 / 2.44
Output Power (Up/Down) [dBm]: 11.8 / 0.0
Line Attenuation (Up/Down) [dB]: 12.9 / 27.0
SN Margin (Up/Down) [dB]: 6.1 / 6.3
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 7 / 0
FEC Errors (Up/Down): 459 / 66,503
CRC Errors (Up/Down): 26 / 27
HEC Errors (Up/Down): 39 / 2,085

[#2]

first dropped connection of the night at 8:43.
no street lights on yet.

Info Apr 23 20:44:42 CONFIGURATION saved by TR69
Info Apr 23 20:43:58 FIREWALL event (1 of 1): modified rules
Info Apr 23 20:43:58 FIREWALL event (1 of 1): created rules
Info Apr 23 20:43:58 FIREWALL event (1 of 2): deleted rules
Warning Apr 23 20:43:58 PPP link up (Internet) [37.152.224.138]
Info Apr 23 20:43:57 PPP CHAP Receive success (Internet)
Info Apr 23 20:43:56 PPP CHAP Receive challenge from rhost PCL-AG06 (Internet)
Info Apr 23 20:43:56 PPP CHAP Receive challenge from rhost bras-red6.fk (Internet)
Info Apr 23 20:43:48 xDSL linestate up (ITU-T G.992.5; downstream: 14335 kbit/s, upstream: 1031 kbit/s; output Power Down: 21.0 dBm, Up: 11.7 dBm; line Attenuation Down: 26.5 dB, Up: 12.9 dB; snr Margin Down: 6.3 dB, Up: 7.0 dB)
Info Apr 23 20:43:22 xDSL linestate down
Warning Apr 23 20:43:21 PPP link down (Internet) [146.200.188.237]
Info Apr 23 20:42:52 xDSL linestate down
Info Apr 23 20:42:35 FIREWALL event (1 of 2): modified rules
Info Apr 23 20:42:35 FIREWALL event (1 of 2): created rules
Info Apr 23 20:42:35 xDSL linestate down

[#3]

Hi,
Error counts are crazy!  Might possibly have a duff modem given the restart problems.  If it is less than 12 months old, you should be able to get a replacement from PN.  it is worth an ask / opinion from DCT.
has the fault check found anything?  Doing whilst your line is playing up is a really good time to push it through its process.

[#4]

it dropped again, in the time it took me to read that post and try the btw test
and then dropped again within 30 seconds of being connected - now a total of 3 drops since 8:43.
Download speedachieved during the test was - 12.28 Mbps
For your connection, the acceptable range of speeds is 4 Mbps-21 Mbps.
IP Profile for your line is - 12.24 Mbps
Upload speed achieved during the test was - 0.82Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
-----
Uptime: 0 days, 0:02:34
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,029 / 13,878
Data Transferred (Sent/Received) [MB/MB]: 28.08 / 149.20
Output Power (Up/Down) [dBm]: 11.7 / 0.0
Line Attenuation (Up/Down) [dB]: 12.9 / 27.0
SN Margin (Up/Down) [dB]: 6.3 / 6.5
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 26 / 0
Loss of Signal (Local/Remote): 3 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 110 / 0
FEC Errors (Up/Down): 0 / 4,770
CRC Errors (Up/Down): 0 / 2
HEC Errors (Up/Down): 0 / 78

[#5]

This is really bad - hope you can get the fault report done - http://faults.plus.net

[#6]

interestingly, i had no dropped connections last night.
current uptime is 1 day 11 hours, but my sync speed has dropped to 11811kbps
Uptime: 1 day, 11:36:27
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,036 / 11,811
Data Transferred (Sent/Received) [MB/GB]: 368.68 / 8.15
Output Power (Up/Down) [dBm]: 11.6 / 0.0
Line Attenuation (Up/Down) [dB]: 12.9 / 26.5
SN Margin (Up/Down) [dB]: 6.5 / 11.9
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 273 / 0
Loss of Signal (Local/Remote): 31 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 1,681 / 2
FEC Errors (Up/Down): 1,914 / 170,220
CRC Errors (Up/Down): 209 / 1,020
HEC Errors (Up/Down): 277 / 20,118

[#7]

Hi,
Lower synch speed is (I suspect) related to the higher SNRM.  Error counters look not good.  Have you raised the fault report?

@DCT,
Could you please opinion my comments on posts 51 and 62 - for relevance and education?  Thank you. 

[#8]

well it lasted well until midnight last night/this morning when it dropped again.
then apparently must have dropped more times thru the night as the uptime is currently at 4 hours
sync back to 14000kbps though.
Uptime: 0 days, 4:15:12
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,033 / 14,269
Data Transferred (Sent/Received) [MB/GB]: 606.65 / 9.97
Output Power (Up/Down) [dBm]: 11.9 / 0.0
Line Attenuation (Up/Down) [dB]: 12.9 / 26.5
SN Margin (Up/Down) [dB]: 6.1 / 7.4
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 494 / 0
Loss of Signal (Local/Remote): 56 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 2,465 / 2
FEC Errors (Up/Down): 0 / 19,147
CRC Errors (Up/Down): 0 / 123
HEC Errors (Up/Down): 0 / 2,580

[#9]

@Townman - There are quite a few posts there, are you referring to the REIN testing results?
@chenks76 - Has your line remained stable since these bursts of disconnection?

[#10]

Chris,
From reply #51

Quote from: Townman

@Chris / DCT, I have seen on some line test reports two lines implying the ability to test for REIN and CROSSTALK.  I have contended for a while that these are only point in time tests and that (if it is the cause) REIN and CROSSTALK might not be present at the time of the test and can therefore be (incorrectly) discounted as the cause.  Is it possible to arrange for such tests to be scheduled at the time that the user expects to encounter the problems?  I've been there before, tests are run whenever, but not at the time the problem is manifest.  This is not untypical of problem network investigation which frustrates users - the ability to test does not align to the present presence of the problem... therefore there is no problem... at least not one that can be identified for resolution. The RADIUS graph on reply 1 has now gone.  Is it possible to generate 'back dated' radius graphs for the period after the previous BTOR repair.  It would be useful to know if the disconnections issues were completely cured or just sufficiently diminished so as to be not noticeable if not being looked for? Cheers, Kevin

From reply #62

Quote from: Townman

Error counts are crazy!  Might possibly have a duff modem given the restart problems.  If it is less than 12 months old, you should be able to get a replacement from PN.  it is worth an ask / opinion from DCT.

Sometimes Chris, trying to support users is guess work on my part - I hope informed guess work, but clearly not as authoritative as what you offer.  In such circumstances, you need to indicate what is and is not relevant, which is why I asked for your comments on the two posts above.
Kevin

[#11]

Kevin,
I appreciate the help that you do give and I apologise if we do miss something, it can be difficult to keep with everything as there are so many different threads to try and keep track of.
Any line tests that are carried out give an output based on the historical performance of the line. For example, if a connection has been dropping a lot between 9-5:30 our suppliers systems are very likely to point this issue towards REIN/SHINE issue. The results have absolutely no relevance to the issue actually being REIN/SHINE, the only way we can confirm this is by the End User/Customer checking for us or having an engineer/REIN Engineer confirm and raise a case. The testing system just gives an output based on how the connection behaves and performs.
There isn't any way that we can schedule this test to be run at a certain time, but that is a really good idea - I'll pass that on to BTw to see if there's anything we can do with that, it'd be good for REIN Cases.
Error counts can be caused by absolutely anything and it's really difficult to pin point whether it's a Local Network Fault, Router Fault or an issue within the Customers Own Domain. We can RMA a router with an issue but we'd need sufficient evidence to show that the router is at fault before progressing this.
RADIUS graphs can be back dated too, that wouldn't be a problem, these can be provided at request.

[#12]

Quote from: Chris

... if a connection has been dropping a lot between 9-5:30 our suppliers systems are very likely to point this issue towards REIN/SHINE issue.

Chris,
This is interesting insight... Most of the examples seen on the forums which appear to be REIN (or cross talk) related (step changes in SNRM) seem to be outside office hours - that is when people have returned from work / school and start using the devices which are often responsible for REIN.
Given your relationship with BTw is there any possibility of having the time limits on the judgement criteria for REIN classification changed?  For example significant marked change of a metric (e.g. SNRM) over a defined interval (say 20 minutes) happening on a regular basis could be indicative of REIN?
The SNRM plots on this thread and those of PNF seem to suggest some external impact on the service's operational profile.  If this is not REIN/SHINE, then what might it be?  (Rhetorical question  ;))
Do not worry about missing my asides - as much as anything else, they serve to confirm my understanding / expand my (and other's) knowledge.
Kevin

[#13]

It's actually a really interesting idea, something that I could run by one of the guys I work with within BTw - When I next speak to him I'll pose the question and see what he comes back with.
REIN/SHINE issues are so, so difficult, purely because there are so many different points at which it could be coming from. In a lot of instances, it's the customer equipment (Lights/Lamps/TV's for example but there are plenty of examples where a Third Party is the cause of it - the more information we can get from our testing the better. REIN is always going to be probably one of the most difficult issues to track down and to try and ease how this affects our suppliers it may be worth posing the question so I'll see what they say on the subject.

[#14]

well i don't know what the cause was, or what fixed it..... but the problem seems to have disappeared/resolve itself.
i am currently at 2 days 4 hours uptime.
i never actually got round to raising a fault ticket (as other things took priority at the time).
up until 2 days ago i was still getting disconnections at the same times every night.
Uptime: 2 days, 4:22:12
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 1,264 / 14,330
Data Transferred (Sent/Received) [MB/GB]: 311.45 / 3.51
Output Power (Up/Down) [dBm]: 12.6 / 0.0
Line Attenuation (Up/Down) [dB]: 12.7 / 26.5
SN Margin (Up/Down) [dB]: 5.8 / 6.5
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 5,048 / 0
FEC Errors (Up/Down): 0 / 3,268,417,727
CRC Errors (Up/Down): 728 / 11,353
HEC Errors (Up/Down): 1,061 / 140,148

[#15]

3 days 8 hours, and counting.