'Normal' evening SNRM drop/flat twisted pair RJ11 cable.

[#1]

Quote from: Anotherone

Having the Modem/Router where you can see it is a far better idea than having it remote

Only someone obsessed with watching the router lights would need the router near them. My router is downstairs and I'm upstairs and I've no need to look at the lights - 99% of the time looking the router status via its web pages tells me far more than the lights do.
If you need multiple Ethernet sockets at the remote end of an Ethernet cable 5 port switches are well under £10 (or use an old ADSL router with the DHCP turned off).

[#2]

You don't have to be obsessed, and sometimes the lights tell you things the web page doesn't (the 1%) and in any event, it's everybody's own preference, but apart from which, the position of his 582 will be decided by his wireless coverage as JayG mentioned earlier in the thread

[#3]

Quote from: JayG

Just had an unprompted resync which presumably is the DLM deciding to have another go at a 3dB SNRM - the 'proper' twisted pair extension cable is still in the post, so I don't think there's much chance these stats will still be valid in about 6 hours time!  Uptime: 0 days, 0:05:13    DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 1,171 / 13,035 Data Transferred (Sent/Received) [MB/GB]: 507.57 / 6.34 Output Power (Up/Down) [dBm]: 12.5 / 0.0 Line Attenuation (Up/Down) [dB]: 20.6 / 37.0 SN Margin (Up/Down) [dB]: 5.2 / 2.6 In the event that the new extension cable does enable me (and my pal DLM) to operate reliably at a 3dB SNRM I'll let you know - I'm certainly having a much more entertaining ride with the TG582n than the 'tweaked' old Netgear!.

6 hours turned out to be over-optimistic - lost sync two hours after that post, and resynched at...........3dB down SNRM target again! 
New twisted pair RJ11 extension cable arrived yesterday (great service!) and connected up - recynched at 3dB again, but this dropped almost to zero during the evening although it doesn't appear to have dropped the connection, but the number of errors made it almost unusable.
Tried disconnecting and resynching during the evening night and connected at 3dB, which more or less held at that figure until bedtime.
This morning, no overnight drops, but now that we're off-peak and in daylight hours the reported margin has now risen to 6.2dB.
So, jury still out on the twisted pair cable, but I certainly now have an awareness that if you have a setup which as far as the DLM is concerned is on the cusp of a 3dB or 6dB target SNRM you have to be careful when you resync to avoid either repeated changes of target or a SNR which drops so low in the evening it makes even surfing almost impossible.
Wish I could still tweak the target from 3 to 5 as I did with the Netgear - it ran trouble free for years like that, even with the 'wrong' extension cable!

[#4]

Have a look at your incoming BT cable and describe it's size, colour, cross-section, profile etc.

[#5]

1) Drop wire looks very similar to cable to pole i.e. black, round, similar diameter (less than co-ax TV cable.)
Difference is that the pole cable was replaced about 5 years ago after a lightning strike on the old pole, whereas the drop wire is at least 15 years old to my knowledge, and probably much more than that.
2) DLM appears to have given up trying a 6dB SNRM target now, despite high numbers of errors at 3dB.
Router stats @ 1505 this afternoon:
Uptime: 0 days, 22:21:44
DSL Type: ITU-T G.992.5   
Bandwidth (Up/Down) [kbps/kbps]: 1,214 / 12,395
Data Transferred (Sent/Received) [MB/MB]: 15.67 / 164.03 
Output Power (Up/Down) [dBm]: 12.6 / 0.0   
Line Attenuation (Up/Down) [dB]: 20.8 / 37.5   
SN Margin (Up/Down) [dB]: 5.7 / 3.9 
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): 18,248 / 0   
FEC Errors (Up/Down): 418 / 138,386,273   
CRC Errors (Up/Down): 62 / 56,000   
HEC Errors (Up/Down): 104 / 200,520
Looks pretty horrendous to me, but Routerstats data shows that 192k of the 200k HEC errors came in the overnight period from 2030 (reboot) to 0845 this morning (restarted PC, router on continuously) so there have 'only' been 8k in the 7 daylight hours.so far today. Connection not dropped though despite the errors and SNRM dropping to as low as 0.8dB at 2017 yesterday evening.)
Have gone through all the electrical items in my house which aren't on during the day anyway - none cause any change in either SNRM or HEC's, and as it happens the nearest street lamp has been on 24/7 for weeks now so presumably can be ruled out.
Rather eccentrically my extensions are hard-wired via a splitter in the main socket, so it's easy to take them out of the equation without using the test socket. Bell wire not connected.
2) Have changed too many variables at once (new TG582n router, so no upwards SNRM target tweaking, changing to twisted pair RJ11 extension and back again, to follow what's going on now, so am currently sticking with the twisted pair extension cable and keeping my hands to myself to see what happens when left alone, although I am baffled as to why the DLM has not tried a 6dB margin again as it did earlier in this saga.
As I mentioned earlier the DG834v4 provided a very stable connection with the target tweaked from 3 to 5dB, which is why I didn't take much notice of the error rates (unfortunate - would have been a useful comparison.)
3) Probably of no consequence, but I couldn't help comparing my stats with those of Probedb in his 'very high FEC error' thread, who may be a near neighbour or live in the opposite direction, but we have similar attenuation, same type of ADSL, and are both connected to the Sharrow exchange.

Quote from: probedb

So I decided after reading the guide to check it with the test socket and here's the results: Uptime: 0 days, 0:09:21 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 1,172 / 9,727 Data Transferred (Sent/Received) [MB/MB]: 3.62 / 24.40 Output Power (Up/Down) [dBm]: 12.7 / 0.0 Line Attenuation (Up/Down) [dB]: 21.6 / 41.5 SN Margin (Up/Down) [dB]: 6.7 / 6.4 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): 2 / 0 FEC Errors (Up/Down): 0 / 589,241 CRC Errors (Up/Down): 0 / 3 HEC Errors (Up/Down): 0 / 87

[#6]

Quick initial response, yes that does look horrible, I suspect this street light may have a bearing on things, I'll come back on that - meanwhile I think your speed may now be banded. I also wonder by chance if you are on the same DP as probedb.

[#7]

I was ruling out the street lamp because it's on 24/7 and doesn't seem to be having any impact during daylight hours.
If it's banded it must surely be a pretty high band because at a sync of over 12Mbps it's well over most ADSL2+ estimates for the attenuation?
Edit, if I 'disappear' it will be because the SNRM is already dipping below 1dB and it looks as if the HEC errors are preparing for take off!! 

[#8]

Quote from: Anotherone

meanwhile I think your speed may now be banded

Nope, WBC 160K - 24M so it's allowed the full range of speeds. No banding there.
I could try and reset the target back to 6db, but continually doing this is masking any potential underlying problem.

[#9]

Not a good idea Chris, I think there's a lot of interference / REIN - probably this street light.
Well at least it's not banded but I thought I'd mention "graceful disconnects".
It's always best to do a graceful disconnect when you have line &b error problems rather than doing a straight reboot etc.
Log in to the modem/router and click Disconnect to drop the PPP Internet session, wait about a minute and then pull the power plug. Leave say another minute and unplug from the line if you want to/need to swap anything etc., but irrespective stay off-line for a minimum of 10 minutes. When you've powered up again an boot is complete, login and click Connect. Don't do this more than 5 times (in an hour) and then leave it for the rest of the day.
The sensor on the street light is undoubtedly faulty and may not be switched on "hard" and hence the thing could be generating a lot of interference which would account for all the horrendous errors. I would contact your local council and tell them it's been on 24/7 for a while now and you've suddenly realised that you are getting lots of interference to your broadband and MW radio since this which you believe is responsible.  Hopefully that will get a speedier response than they may otherwise, and at least we'll solve the problem or eliminate it from the possible causes.

[#10]

All my experiments and resyncs have been preceded by the 'graceful disconnects' you describe.
Surely if the 24/7 street lamp was responsible for REIN this would be detectable during daylight hours as well, but that doesn't seem to be the case as far as SNRM and HEC counts are concerned?
Being Sheffield based, PlusNet may have some information about whether the on-going replacement of street lighting by LED versions has had any effect on noise levels for their customers, although my road has yet to feel the 'benefit' of the new technology anyway.

[#11]

I wouldn't have expected change over to LED to have much of an impact. Normally functioning street lighting doesn't usually give any issues.
Depending on the nature of the "noise" it may not have a significant direct impact on the errors in the day, more just on the SNRM and consequently the achievable speeds. The combination of the "noise" from the street light and the onset of night-time propagation effects may have a far greater impact. These things are never clear cut. Best just to get the street light fixed and out of the equation (the slight porky may help speed up a repair).

[#12]

Well, REIN from 24/7 street lights or otherwise, after flat-lining during daylight hours today the HEC errors have jumped from around 200k at 1653 to over 260k now (1835) - connection still not dropped despite SNRM of 0.8dB currently.
Must admit I never expected such an 'interesting' ride from merely changing to a TG582n router to accommodate my Hudl tablet's Wifi requirements, and experimenting with a 'proper' RJ11 twisted pair extension cable having discovered that the previous one was below spec. 
Thanks for all your contributions - hard to know what my next move should be because I mainly use my connection for surfing and don't put it under much pressure, but it would be nice to think I could do so without causing it to fall over a cliff, and there is clearly something amiss here.

[#13]

I'll come back and make some more suggestions later, just catching up on some other stuff.

[#14]

TG582n SNRM still reporting as about 1dB or less, still not dropped connection this evening, HEC errors up from around 200k at 1738 to around 465k now (2103.)
Uptime now 28 hours, but as previously mentioned I've not felt confident enough to really test my connection to the limit because I'm trying to see what the current set up (and DLM) make of it without me tinkering with anything.
Appreciate your help Anotherone, but would also appreciate whether the CRT team have any comments to make tomorrow ('your connection is actually performing quite well' would be good, although I'd take some persuading on that score!  ::))

[#15]

Judging by your obvious knowledge, I'd be surprised if they could add anything to what you already know, subject to some test data. A quick look at the DLM history may be of interest. If it gives the ILQ as Amber then things could be better.
I think it's pretty obvious that the reason the errors increase so much after dark is because the SNRM gets so very low This is not inconsistent with what I've said about the "noise" that could be being generated by the faulty street light.