Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: xreyuk on December 14, 2018, 11:04:50 AM
-
Hi All,
For around the past year or so, my FTTC connection has been running at an SNR on the downstream of 21.9dBm, with speeds of 41Mbps. I ended up having to reboot the modem the other night (I still use a HG612) and to my surprise resynced at 51Mbps and an SNR of 6dBm.
My connection stayed stable for 24 hours, no problems, minimal errors (although some) and I was enjoying the speed increase. Last night the line decided to resync itself (I assume to DLM) at resynced around 41Mbps, with an SNR of 21.9dBM again, so I would suggest for some reason this is what my target is set at.
I am with Plusnet, is there anything they, or I can do regarding this?
As a side note, I'm thinking about getting a new updated modem (or router for bridge mode), can anyone advise if it's worth it, and I'm likely to see any gain from it?
-
Have you been monitoring the errors?
-
Have you been monitoring the errors?
Yes, there were some errors on the downstream, but nothing ridiculous. Even with the 22 SNR, I have a few errors, but there's hardly anything between the 6dBm SNR and 22dBm SNR.
The upstream errors like crazy, because for some reason the SNR is 0.
-
Have you checked the phone line using the quiet line test?
-
The only target SNRM values on FTTC are 6, 5, 4 and 3 dB. The DLM can also apply rate caps to make your line connect at a lower speed and with higher SNRM than those target SNRM values. If the DLM is not capping the rate, then there must be some cause other than the DLM.
-
It's hard to tell without detailed stats, and the Plusnet Hub is very limited with its stats.
Can you post all the stats that it does give, exactly as it gives them.
It could be that the line was banded (capped), this was removed, then reapplied, but I find that extremely unlikely.
Can you follow this guide here
FTTC cab - How to lookup location & type of DSLAM (https://forum.kitz.co.uk/index.php/topic,15409.0.html)
and check what type of DSLAM you are connected to, ECI or Huawei.
Alternatively tell us the cabinet and exchange and we can look it up for you.
-
Hi all,
Thanks for the replies.
I hadn't done the quiet line test, so did one today and it reveals faint buzzing and popping noises.
What other causes than the DLM could be causing the 22dBm SNR?
I am not using the plusnet hub, I am still connected using an unlocked Huawei HG612. Here are the current line stats. As for cabinet, I am connected to a Huawei cab. Plusnet have said that I am not banded.
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 10800 Kbps, Downstream rate = 51480 Kbps
Bearer: 0, Upstream rate = 10800 Kbps, Downstream rate = 41031 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.0 6.5
Attn(dB): 21.9 0.0
Pwr(dBm): 12.0 6.6
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 237
M: 1 1
T: 0 48
R: 10 16
S: 0.1767 0.7004
L: 10773 2901
D: 4 1
I: 238 127
N: 238 254
Q: 4 0
V: 0 0
RxQueue: 100 0
TxQueue: 20 0
G.INP Framing: 18 0
G.INP lookback: 20 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 212441
OHFErr: 677 18
RS: 1931391808 3850590
RSCorr: 252967 184
RSUnCorr: 0 0
Bearer 1
OHF: 5333665 0
OHFErr: 0 0
RS: 32001619 0
RSCorr: 4 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 216107069 0
rtx_c: 4061965 0
rtx_uc: 370050 0
G.INP Counters
LEFTRS: 967 0
minEFTR: 41027 0
errFreeBits: 701718282 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2463921243 0
Data Cells: 43592669 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 150 53
SES: 62 0
UAS: 128 77
AS: 85673
Bearer 0
INP: 55.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 8.43
OR: 0.01 30.33
AgR: 41120.78 10830.73
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 58220/58220 1383/1383
*edit*
Looking at these stats it appears I'm connected with an SNR margin of 8 (which is still high) however, it appears the numbers may have been showing in the incorrect places on the GUI. So don't I feel like a tool.
However, the main issue is that I've been having problems with gaming and some streaming, and by the looks of it I'm running errors on my line. Couple that with the noisy quiet line test, could there be a fault on my line?
-
These are the stats after doing a reboot this evening, I can update these after around 24 hours to see how things are going if that's a good idea? As you can see, sync speed jumped massively.
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 10819 Kbps, Downstream rate = 55168 Kbps
Bearer: 0, Upstream rate = 10819 Kbps, Downstream rate = 55378 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.3 6.5
Attn(dB): 21.9 0.0
Pwr(dBm): 12.8 6.7
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 237
M: 1 1
T: 0 48
R: 10 16
S: 0.1309 0.6992
L: 14540 2906
D: 4 1
I: 238 127
N: 238 254
Q: 4 0
V: 0 0
RxQueue: 135 0
TxQueue: 27 0
G.INP Framing: 18 0
G.INP lookback: 27 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 19671
OHFErr: 0 0
RS: 4990084 944114
RSCorr: 37862 0
RSUnCorr: 0 0
Bearer 1
OHF: 10272 0
OHFErr: 0 0
RS: 81680 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 216107941 0
rtx_c: 745 0
rtx_uc: 136 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 55353 0
errFreeBits: 139236 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 17531469 0
Data Cells: 26503 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
AS: 165
Bearer 0
INP: 56.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 8.42
OR: 0.01 30.39
AgR: 55499.50 10849.39
Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01
Bitswap: 120/120 6/6
#
-
at an SNR on the downstream of 21.9dBm, with speeds of 41Mbps.
21.9dBm is the attenuation.
I note one of your recent sync's shows SNR (dB): 3.3 which indicates that DLM could have moved you to Target SNRM of 3dB. This would account for the jump to 55Mbps.
The alternative is you are still on a Target 6dB but one of your crosstalkers could have been offline when you did a resync. If all lines on the DSLAM are forced to resync it's not uncommon if your modem comes up before theirs to get a speed boost, but the SNRM will shoot back down when they come online.
If I sync before my neighbour then I get a speed boost of circa 12Mbps, but as soon as their modem syncs then my SNRM drops to 3.2dB.
-
21.9dBm is the attenuation.
Huh? ??? Something expressed as decibels relative to one milliwatt is the power. I suspect that there was "eye-on-line slippage" when initially reading the values.
Down Up
SNR (dB): 3.3 6.5
Attn(dB): 21.9 0.0
Pwr(dBm): 12.8 6.7
Considering those three lines it looks, to me, as if the value on the second line was taken as the value of the first line with the units of the third line!
-
21.9dBm is the attenuation.
I note one of your recent sync's shows SNR (dB): 3.3 which indicates that DLM could have moved you to Target SNRM of 3dB. This would account for the jump to 55Mbps.
The alternative is you are still on a Target 6dB but one of your crosstalkers could have been offline when you did a resync. If all lines on the DSLAM are forced to resync it's not uncommon if your modem comes up before theirs to get a speed boost, but the SNRM will shoot back down when they come online.
If I sync before my neighbour then I get a speed boost of circa 12Mbps, but as soon as their modem syncs then my SNRM drops to 3.2dB.
Yeah for some reason the GUI reports the attenuation value as the SNR value (I was checking the GUI first, this is the first time I’ve actually used the telnet stats in a while!).
Thanks for the info about crosstalk. This reboot this evening was caused by me (power at home) so all of the others would have been synced (unless I got really lucky). However what I tend to find is the line will hold sync perfectly fine at those stats (with errors) then DLM will cause a resync after 24 hours when it hits midnight (so I resync at 9PM manually then DLM does it 27 hours later). I can pretty much guarantee this is what will happen in this case.
I wouldn’t mind the speed drop from 52Mbps to 41Mbps if I actually gained any stability out of it but I don’t. I’m suffering frequent disconnections whilst gaming, and struggle with live IPTV services.
My thinking is, if I’m going to have the problems regardless what speed I’m at, I’d rather be at the faster speed.
I’ve tried raising a fault with plusnet before about the problems with service, but they just quote that I’m still running at the expected numbers (between 36-54Mbps) and seem to ignore the stability issues.
I’ve ruled out all local equipment because these issues have been going on so long, all my equipment has changed (apart from the modem).
-
that is an error prone line.
It isnt fast path yet has accumulated dozens of SES. Hard for me to comment much further then that tho. As very limited info.
You can see from stats in my sig I am on fast path and have 0 SES. So those are possibly related to your resyncs, you may be getting bursts of instability which causes the modem to drop out.
When you contact plusnet, dont go on about your speed, concentrate on the disconnections. The former is a complaint they probably hear every day from many people and are trained to absorb it, the latter is a real problem that needs dealing with. Exaggerate if you have to, tell them it drops out when watching netflix etc.
-
Yeah for some reason the GUI reports the attenuation value as the SNR value (I was checking the GUI first, this is the first time I’ve actually used the telnet stats in a while!).
If you are still using the HG612, the GUI looks perfectly OK to me.
-
I hadn't done the quiet line test, so did one today and it reveals faint buzzing and popping noises.
You need to repeat the quiet line test using a corded phone plugged in to the test socket (without a filter and modem). If there is an issue that needs reporting as a voice line fault. If it is clear you need to gradually put things back together checking the line at each stage to identify what causes the popping.
If there are audible issues with the line it's pointless worrying about sync speed, target noise margin, error rates, resyncs etc - they are just the symptoms.
-
Attached is what I see when using the GUI, as you can see the values are in the wrong place. Software version is: V100R001C01B030SP08, and firmware version is A2pv6C038m.d24j. From what I understand this is the latest firmware?
Thanks, I'll repeat the quiet line test, as I did use a normal handheld phone, but didn't unplug the filter.
With regards to limited information, is there anything I can do to get better information for you guys? I did use to run DSLStats but stopped.
-
that is an error prone line.
It isnt fast path yet has accumulated dozens of SES. Hard for me to comment much further then that tho. As very limited info.
There are absolutely zero timers to tell how long those errors have been over.
Also there is no fastpath... the line has Retx.
If you are still using the HG612, the GUI looks perfectly OK to me.
You have a special HG612.
The GUI has always been buggy for me with values mixed up.
These are the stats after doing a reboot this evening
Can you please use the xdslcmd info --stats command and not the info --show command.
The additional error timers provide huge value.
The line is running at 3dB, that's not late syncing crosstalkers. The attainable drops below sync when that happens.
My theory is this isn't DLM like you think.
I think you have something (noise) that knocks roughly 5dB off your SNRM. This is causing the line to drop sync.
The noise remains when the line syncs back up resulting in lower sync.
Eventually the noise passes increasing the SNRM by 5dB, to the 8dB you had.
The only way you can confirm what is causing your issues is to run DslStats and catch the changes in SNRM.
-
Thanks.
I will try and get DSLStats setup. However, all of my resyncs occur between 00:00 and 00:10, I wouldn't think this would be interference, more likely DLM.
-
Then you have the only FTTC line in the UK where DLM has a set time.
DLM used to have a fixed window, once upon a time. That was when FTTC was new.
DLM no longer takes action just after midnight but at ANY time of day.
More likely a piece of electrical equipment on a timer, causing the noise I was describing.
edit: to add... there is no DLM features I'm aware of that raises SNRM by 5dB on a temp basis, without banding.
I'll bet my right nut it isn't DLM related at all.
-
Then you have the only FTTC line in the UK where DLM has a set time.
DLM used to have a fixed window, once upon a time. That was when FTTC was new.
DLM no longer takes action just after midnight but at ANY time of day.
More likely a piece of electrical equipment on a timer, causing the noise I was describing.
edit: to add... there is no DLM features I'm aware of that raises SNRM by 5dB on a temp basis, without banding.
I'll bet my right nut it isn't DLM related at all.
No worries, DSL stats is now running so we'll see what happens.
-
restart dslstats as it shows the behaviour of the line overtime.
Did you concentrate on the disconnections with plusnet?
-
There are absolutely zero timers to tell how long those errors have been over.
Also there is no fastpath... the line has Retx.
I said that, I said there is no fastpath on the line.
The timers isnt needed to determine the SES is high, my uptime before my power cut was several months and I still had 0 SES, and my line has no error correction enabled on it.
His line has error correction and has dozens of SES, even if his uptime was a year thats high. Of course we know it isnt a year as he has been getting resyncs. So short uptime and dozens of SES equals an error prone line.
-
....
His line has error correction and has dozens of SES, even if his uptime was a year thats high. ...
??
If that's true then my line is awful.
I gets up to 10 SES every day and many hundreds of ES too. It's running with G.INP at 3dB on the DS and stays in sync for weeks on end.
Thing is it's always been like this so I assume that's just the way it is.
The issue here is the resyncs, not the actual number of SES.
Hopefully the dslstats data will throw some light on this one.
:)
-
Thanks for the additional info, for sure dslstats may help, I am curious to see if the line is stable for periods of time, but you then getting bursts of noise that generates the SES, and these bursts may also be possibly knocking out the sync, my theory is actually similar to john's I dont know why he commented the way he did on my previous post.
-
The timers isnt needed to determine the SES is high, my uptime before my power cut was several months and I still had 0 SES, and my line has no error correction enabled on it.
His line has error correction and has dozens of SES, even if his uptime was a year thats high. Of course we know it isnt a year as he has been getting resyncs. So short uptime and dozens of SES equals an error prone line.
I couldn't disagree more.
Every single DLM initiated resync gives me 12 ES and a few SES.
They DON'T count towards the DLM daily limit but they show on the modem until rebooted.
Without timers we have no idea if those errors were over an hour or over a month.
If you think 150 ES/60 SES in a YEAR is high then you need to reevaluate that.
The DLM limit for ES is upto 2880 per day.
How on Earth can 150 in a year be high.
Half the country probably gets those kind of error figures everyday.
??
If that's true then my line is awful.
It absolutely isn't true so don't worry about it.
edit: to add
Of course we know it isnt a year as he has been getting resyncs. So short uptime and dozens of SES equals an error prone line.
Those stats don't reset with resyncs but are from the entire modem uptime.
I wasn't trying to pick a fight but simply trying to reassure the OP that those figures aren't necessarily high as was previously pointed out to him.
Without relevant timers those error stats are pretty meaningless and telling OP they are high for a year when his modem may have a short uptime will cause a panic.
-
I agree with j0hn, if its of any use:
Total time = 53 days 21 hours 21 min 44 sec
FEC: 2221661739 0
CRC: 26617 1167
ES: 4284 979
SES: 406 0
UAS: 149 149
LOS: 0 0
LOF: 0 0
LOM: 0 0
So roughly 80 ES & 8 SES a day. Perfectly stable line.
-
i never said anything about his ES, so thats twice you have misinterpreted me.
since when is 4 million divided by 50 equals 80
Also i think its rude the way you have just spoken to me i have been helping diagnose problems on here via stats for years and i have never reacted to someone else advise the way you have.
now if you think me calling a line error prone is going to cause someone to panic i dont know what to say.
i would be interested to see a 53 day ping plot for that line johnson to see what the packet loss is like
-
Cool beans.
You said the SES were high.
I said
If you think 150 ES/60 SES in a YEAR is high then you need to reevaluate that.
I didn't misinterpret anything, I simply expanded on your statement.
Also i think its rude the way you have just spoken to me i have been helping diagnose problems on here via stats for years and i have never reacted to someone else advise the way you have.
I disagreed with you.
Please point out where I was rude.
The fact you have been helping people for years on these forums does not mean nobody is allowed to correct you or disagree with you.
i would be interested to see a 53 day ping plot for that line johnson to see what the packet loss is like
I'm going round in circles here but why do you think 80 ES per day and 8 SES would cause packet loss?
since when is 4 million divided by 50 equals 80
What? I'm lost. Where's the 4 million coming from.
He had 4284 ES in 53 days.
That's 80.8 ES/day.
I regularly received about 1000 ES and about 20 SES every single day while fastpath.
My BQM didn't show any packet loss.
You're only going to get packet loss with hundreds/thousands of ES an hour.
-
Ding ding
End of round one.
-
I agree with j0hn, if its of any use:
Total time = 53 days 21 hours 21 min 44 sec
FEC:22216617390
CRC:266171167
ES:4284979
SES:4060
UAS:149149
LOS:00
LOF:00
LOM:00
So roughly 80 ES & 8 SES a day. Perfectly stable line.
Take these figures...
ES:4284979
SES:4060
do a basic divide by 53 gives you...
ES: 80848/day
SES: 76/day
That ES rate is not that far off one per second so I think packet loss is a certainty.
I am no expert but assuming the modem is reporting the stats correctly this is not a stable line by any stretch of the imagination.
The maximum ES/day the line may experience before DLM intervention the following day is around 2880 (1440 in some cases). Not sure about the rules for SES but from my experience if you get several bursts in a short period of time the DLM usually intervenes immediately.
-
Ding ding
End of round one.
No need for round 2 guys please :)
----
My uptime is 8 days, 3hrs, 49 min (Modem was switched off all day so totals were reset)
ES: 297 153
SES: 53 0
UAS: 27 27
AS: 704939
Also no G.INP, but it depends on the type of noise as to how effective retransmission is. G.INP can work well with low level REIN. Sharp random noise bursts (eg SHINE lasting more than 10ms) can be problematic even with re-tx and start to accrue SES.
-
Take these figures...
So apparently the tab spaces do not show on some folks browsers, really sorry for the confusion. Looks like this on mine:
(https://i.imgur.com/Z0IHh4V.png)
-
Take these figures...
do a basic divide by 53 gives you...
ES: 80848/day
SES: 76/day
That ES rate is not that far off one per second so I think packet loss is a certainty.
I am no expert but assuming the modem is reporting the stats correctly this is not a stable line by any stretch of the imagination.
The maximum ES/day the line may experience before DLM intervention the following day is around 2880 (1440 in some cases). Not sure about the rules for SES but from my experience if you get several bursts in a short period of time the DLM usually intervenes immediately.
Your browser is showing the stats incorrectly.
Johnson has provided a screenshot of what he wrote, and it's what I saw.
If others browsers show it different and they want to argue over it that's up to them.
-
That’s guys,
I’ll post the graphs when I get home but I had a disconnection around 8PM yesterday. DSL stats saw a burst of 100CRC errors, whatever happened cause the line to resync (whether it was DLM or not). When I resynced, I dropped from 51Mbps sync to 39Mbps sync. SNR jumped from 3.3dB to 8.8db, and attainable dropped from ~55Mbps, to 51Mbps. I did a manual modem reboot at 1:45am to do some power work at my house (I’m on a funny schedule) and resynced at 56Mbps with 3.2dB SNR.
Whilst synced at 39Mbps I still saw errors, but a lot lower FEC count.
Since the resync the line has stayed up, but has seen CRC errors around 5-7PM above the norms for the day, but stayed in sync.
Does anyone know how long it takes plusnet/BT line profile to update? When it resynced last night the profile updated almost immediately to 36Mbps, but hasn’t updated since he manual resync around 17 hours ago. (Which makes me think it was a DLM triggered resync)
-
I also forgot to mention I spoke to plusnet and they’re talking about it being a REIN issue.
They were trying to blame something in my house switching on and off between 11PM and 1AM but given that I’ve seen other disconnections (especially last night when no one was home), I’m certain it’s not something in my house.
-
. . . but given that I’ve seen other disconnections (especially last night when no one was home), I’m certain it’s something in my house.
I suspect you have missed out that important three letter word, "not". ;)
-
I suspect you have missed out that important three letter word, "not". ;)
Yes, I've now changed it! ;D
-
Yes, I've now changed it! ;D
Purrfect.
-
I'm still of the opinion it is something knocking 5dB off the SNRM.
With a 3dB SNRM it knocks you offline and returns the line to 8dB.
What you could do is leave the line alone when it resyncs at 8dB SNRM with the lower speed and leave DslStats monitoring the line.
It should catch the event happening and show a 5dB drop in SNRM from 8dB to 3dB, then back up again.
Keep a note of the time(s) this happens.
-
So I’ve had 3 resyncs in the past few days, all at different times. Around 10am, 8pm and 11pm.
Each resync as actually synched at around 54Mbps but what you can see is that it’s basically massive short bursts of CRC errors causing it to drop.
It will run along for hours on end with little to no errors, and the errors that do come always come in bursts. Eventually there is a massive burst which causes the resync
-
Have you checked if the error bursts coincide with use of the phone or the ringing for an incoming call (even if no handset is connected)?
-
Have you checked if the error bursts coincide with use of the phone or the ringing for an incoming call (even if no handset is connected)?
They don’t, I have a phone connected all the time but never get any calls 😂
-
Okay so I have kept monitoring this.
Basically I keep getting masses of CRC bursts which cause a disconnect, when the service reconnects, it connects about 10Mbps slower, with the attainable also 10Mbps slower, so still at a 3.3db SNR.
I will try and attach some graphs but these bursts are all at different times of day. Some around 1am ish, so around 4am ish and others anytime between 6am and midday.
I can force a resync 10 minutes later and all is fine again. I am error free before these events.
On top of this, when I am connected I seem to be suffering bufferbloat either due to congestion or packet loss, I have reduced the bufferbloat using QOS on my router but it’s still there.
-
Update on this. I ended up getting fed up and took the socket off the wall, tidied it up and determinated it.
So far have had 7 days uptime (the longest since about October) and better stats than I’ve ever had.
I still see a 1-4 ES a day with a few CRCs but no bursts whatsoever. The CRCs I’m seeing are maybe 1-5 at a time, where as before I was seeing 100s causing a dropout.
-
. . . took the socket off the wall, tidied it up and determinated it.
I am not too sure exactly what you intended to state . . . possibly "reterminated it"?
Just to satisfy my curiosity, what is the type of socket? :-\
So far have had 7 days uptime (the longest since about October) and better stats than I’ve ever had.
I still see a 1-4 ES a day with a few CRCs but no bursts whatsoever. The CRCs I’m seeing are maybe 1-5 at a time, where as before I was seeing 100s causing a dropout.
That is a most definite improvement.
-
I am not too sure exactly what you intended to state . . . possibly "reterminated it"?
Just to satisfy my curiosity, what is the type of socket? :-\
That is a most definite improvement.
Yes I meant reterminated, silly autocorrect!
I think it’s a 5A, it fits a mk3 faceplate but has screw terminals, I believe the 5C has punchdown?