Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: William Grimsley on July 13, 2016, 10:58:54 AM
-
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 4.2 5.2
Attenuation (dB) 26.1 0.0
Output Power (dBm) 12.1 6.4
Attainable Rate (Kbps) 43063 8155
Rate (Kbps) 45677 8159
B (# of bytes in Mux Data Frame) 243 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 43
R (# of redundancy bytes in the RS codeword) 10 0
S (# of data symbols over which the RS code word spans) 0.1701 0.9348
L (# of bits transmitted in each data symbol) 11946 2054
D (interleaver depth) 8 1
I (interleaver block size in bytes) 254 120
N (RS codeword size) 254 240
Delay (msec) 0 0
INP (DMT symbol) 47.00 0.00
OH Frames 0 0
OH Frame Errors 0 0
RS Words 6980432 1279891
RS Correctable Errors 282 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 26263977 0
Data Cells 1564122 0
Bit Errors 0 0
Total ES 0 0
Total SES 0 0
Total UAS 29 29
-
and ?
-
Sorry?
-
What do you mean by posting some line stats with the subject of "Thank you power cut!" ?
-
Sorry, obviously it's not clear. ::)
Basically, we just had a power cut and because the Billion BiPAC 8800NL has a very quick DSL sync time, when the power came back on, it synced quicker than the other routers, so the line synced at a higher rate! :)
-
How would anyone know it was a higher rate?
-
Agreed. @Dray. "Power cut gave higher sync rate" would be better expressed.
Seems it's a click bait topic, I see this on a forum I'm Admin of.
1) I don't believe you'll notice in real world terms.
2) it'll settle
-
Ok, it shows it in the line stats, if you look carefully. Oh, and it's not best to start advertising that you're an admin on another forum.
-
I can't see anywhere in the line stats that indicates it synced at a higher rate than before :shrug2:
-
Sorry, thought you knew what my line stats were before the power cut, apologies... ::)
-
Better keep an eye on this William as already you don't have a lot of spare SNR.
-
So your posting to say that you've got yourself a temporary couple/few thousand kbps sync due to a power cut, and that now you line will be clocking up a number of errors which will make your connection unstable and end in DLM kicking in and applying extra error correction...
Yes Thank You Power Cut :cool:
I recommend you do a power down for 30 minutes when possible... you could see a bunch of issues when you SNR dips in the evening and from what I saw when you had MDWS a short time back your SNR wasn't the most stablest at any point, never mind the busy times.
-
Well, actually no. I've had no Downstream ES yet and the SNR Margin is very stable, of course if the line became unstable it would resync and connect back at a SNR Margin of 6 dB, but I have no intention of performing a manual power down for 30 minutes. The line is perfectly stable currently and the SNR Margin has always been stable, just has the normal swings day-to-day.
Seems good currently:
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 4.9 5.2
Attenuation (dB) 26.1 0.0
Output Power (dBm) 12.1 6.4
Attainable Rate (Kbps) 44039 8159
Rate (Kbps) 45677 8159
B (# of bytes in Mux Data Frame) 243 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 43
R (# of redundancy bytes in the RS codeword) 10 0
S (# of data symbols over which the RS code word spans) 0.1701 0.9348
L (# of bits transmitted in each data symbol) 11946 2054
D (interleaver depth) 8 1
I (interleaver block size in bytes) 254 120
N (RS codeword size) 254 240
Delay (msec) 0 0
INP (DMT symbol) 47.00 0.00
OH Frames 0 0
OH Frame Errors 0 73
RS Words 191001312 536289
RS Correctable Errors 7464 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 716337324 0
Data Cells 101196216 0
Bit Errors 0 0
Total ES 0 33
Total SES 0 0
Total UAS 29 29
-
OK if you say so.
-
Sorry, obviously it's not clear. ::)
You don't say :doh:
I've had no Downstream ES yet and the SNR Margin is very stable,
BTW. My experience is that errors start to creep up when SNR goes below 4dB, and even more so below 3dB. Your first post shows you just getting to that threshold.
With no CRCs (and no ES), the stats you need to watch instead become the FEC and the retransmission counters.
-
It was clear to me, but I apologise.
Still no Downstream ES, but there have been 21924 Downsteam FEC's since the resync, so not worrying at all.
-
OK if you say so.
-_-. kitz has commented on the SNR Margin and she said it was perfectly normal for it to act the way it always has been, I can't see anything wrong, but will let you know what happens this evening.
-
Can only say when my downstream SNRm falls just below 4.5 dB it's hammer time the modem resyncs no extra errors before hand, some lines seem more sensitive to SNRm changes than others it would be hard to put a ball-park figure on who's line will remain stable at lower levels of SNRm below 4.5 dB
You will gain more knowledge of your lines thresholds by just letting it do it's own thing and the DLM will intervene when it gets to a point and says that's it mate time to take control.
-
Yeah, I'm not getting the issue you've experienced, I was concerned I would face it but haven't.
-
Did a quick wee check on MDWS and out of 80 FTTC online user only 7 have an SNRm below 4.5dB and one user has it still running at 1.9dB with an up time of 3 day 13 hours.
I think we have all done it at sometime or another to gain back some sync from are disturber when the opportunity arises even though it meens a hit to our SNRM.
I am to wise to it these day and don't take the bait and just wait until the disturber resyncs there modem.
-
Downstream FEC's rising but no ES yet, web page loaded slow a minute ago though...
-
Downstream FEC's rising but no ES yet, web page loaded slow a minute ago though...
It's a pity we can't see this happening in real time on MDWS :(
-
Honestly, there's nothing to see. We've got through the evening with no Downstream ES, obviously my line is very good quality these days. :)
-
Honestly, there's nothing to see. We've got through the evening with no Downstream ES, obviously my line is very good quality these days. :)
are you uploading to MDWS?
-
Honestly, there's nothing to see. We've got through the evening with no Downstream ES, obviously my line is very good quality these days. :)
DLM won't intervene immediately, it will let it count up first... also consider that when my line was impacted by REIN that FEC's run up into the 100,000's I think even clocked up to a million in one sync... however I only ever saw 1-2 Errored Seconds per hour...
ES's only really clock up for lines without G.INP, like upstream when in Fast Path...
I high count like mine did cause some issues, specially with online gaming and Skype for a little bit,
The first thing DLM will do is increase the amount if G.INP applied, currently your's is on 8... mine went up to 16...
I think that's currently the max amount of G.INP applied by DLM.
What's your stats at the moment now its busy time?
EDIT: PS. Consider that my line also doesn't have SNRm swings like yours and other do... it's no unusual for some lines to have swings in SNRm, specially those at a distance from the cabinet.
-
My line is perfectly stable.
To add to that, still no Downstream ES.
-
The first thing DLM will do is increase the amount if G.INP applied, currently your's is on 8... mine went up to 16...
The only thing I can see in the stats posted that's 8 is the interleaving depth, but that's not really the amount of G.INP, the size of the retransmission queue is given elsewhere (not in the stats posted). The total amount of INP provided by the retransmission maybe can go a little higher than 47.
-
True, but I can't see any real difference in the line's state after the power cut...
-
I see exactly the same effect with my Billion - we get quite a few power cuts hence the rather low noise margin specially on the upstream
Connection speed (kbps): 46350 11039
SNR margin (dB): 4.9 3.0
-
Ahh, nice one! Yeah, the Billion BiPAC 8800NL's chipset has a very quick DSL sync time, a lot quicker than the BT Home Hub 5 hence the advantage.
-
Still not as fast as the HG612 but it's very close, these new all in one modem and routers seem to spend more time setting up the router side and then start setting up the modem so 3-4 minutes has passed before you can get online compared to 20-30 seconds on HG612 then 8800NL
-
Yeah, I've noticed that.
-
Just out of curiosity what was the lowest DS & US SNRM value you have seen since the power cut ?
-
The ones in the line stats I think.
-
Sure you know that changes over 24 hours due to RFI/Noise, William I am just interested but if you want to be evasive that's up to you mate just don't find it easy these days to get blood out of a stone.
-
Evasive? No. I'm saying that I've regularly checked my line stats and there's no real change in the SNR Margin!
-
This is the change in noise margin over a day
-
Thank you power surge! :D
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 2.7 4.7
Attenuation (dB) 26.1 0.0
Output Power (dBm) 11.7 6.4
Attainable Rate (Kbps) 43647 8103
Rate (Kbps) 49172 8270
B (# of bytes in Mux Data Frame) 243 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 44
R (# of redundancy bytes in the RS codeword) 10 0
S (# of data symbols over which the RS code word spans) 0.1580 0.9222
L (# of bits transmitted in each data symbol) 12860 2082
D (interleaver depth) 8 1
I (interleaver block size in bytes) 254 120
N (RS codeword size) 254 240
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
OH Frames 0 0
OH Frame Errors 0 0
RS Words 4791128 828388
RS Correctable Errors 8931 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 18060237 0
Data Cells 1770285 0
Bit Errors 0 0
Total ES 0 0
Total SES 0 0
Total UAS 29 29
-
Enjoy it mate ;D . Unfortunately it won't last forever... I had the same situation and synced much faster than normal with a low SMRM after a local power outage (I have a UPS). DLM will re-sync after a week or so and then you will be back to normal... But like I say enjoy it now! Do some speedtests and imagine what your line would be like with vectoring ;D
-
Now that should trigger something in the error counts...
if nothing else, you'll find what happens with a 3dB target.
-
No, still no Downstream ES yet! Yes, if vectoring was enabled, the line would be syncing at nearly the maximum for our BT Infinity 1 package (55/10)! The Downstream SNR Margin is hovering between 1.9 - 2.3 dB currently but still going strong! Crazy! There have been 654291 Downstream FEC's though! :D
-
If I currently have a Downstream SNR Margin of 10 dB with a Downstream Attainable Rate of nearly 45 Mbps, then at 3 dB will I get about 50 - 55 Mbps?
Well, I finally found out my answer to this! Not far off!
Just done a quiet line test and it sounds as if there's a gale on the line! Like a whooshing noise on and off! :O
-
The out-of-hours person saying "quiet line test" must be somewhere noisy. :P
-
Haha, well whatever it is it's making no impact on the line itself. :lol:
-
Hows the stats looking now?
-
No, still no Downstream ES yet!
There have been 654291 Downstream FEC's though! :D
If lots of FECs are happening, the next place to look (before ES's happen) is at the retransmission counters.
-
A few errors have got through, but I'm not concerned:
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 2.1 4.7
Attenuation (dB) 26.1 0.0
Output Power (dBm) 11.7 6.4
Attainable Rate (Kbps) 42663 8080
Rate (Kbps) 49172 8270
B (# of bytes in Mux Data Frame) 243 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 44
R (# of redundancy bytes in the RS codeword) 10 0
S (# of data symbols over which the RS code word spans) 0.1580 0.9222
L (# of bits transmitted in each data symbol) 12860 2082
D (interleaver depth) 8 1
I (interleaver block size in bytes) 254 120
N (RS codeword size) 254 240
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
OH Frames 0 0
OH Frame Errors 62 48
RS Words 1144448992 3595934
RS Correctable Errors 9896978 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 4291149537 0
Data Cells 49209045 0
Bit Errors 0 0
Total ES 4 34
Total SES 2 1
Total UAS 29 29
-
Back on MDWS now, ID is WilliamG. Will be interesting to see what happens. :)
-
Hmmm, SNR is definetly not rising... 2.0db at this time of day is rather alarming.
-
Might be alarming, but the line is quite happy.
-
I'm not sure what gives you that idea but you can carry on as you are, not one way to find out I suppose.
-
Well, it's interesting to see what will happen, though right now the line doesn't look any more unstable than at a SNR Margin of 6 dB...
-
Just having another look now any your upstream certainly don't look too stable...
Also are you using the connection to its fullest extent... You may find when you try and download a large file like a movie that your SNR will dip too low and that's when errors and potentially a drop will happen.
-
Not at all, how would downloading something effect SNR Margin?!
-
Not at all, how would downloading something effect SNR Margin?!
I don't know, I thought that when I first saw it but it can.
-
-_-. kitz has commented on the SNR Margin and she said it was perfectly normal for it to act the way it always has been, I can't see anything wrong, but will let you know what happens this evening.
Did she? Ive not been around much this week and only just seen this thread :-\
Admittedly Ive always said SNRm dropping if you're one of the first to sync up after a power cut is normal.
However, I've always advocated that running a line below 3dB is not good. Especially one that has daily SNR swings.
You're opening yourself up to increased risk of errors and DLM intervention.
Even when on LLU with no DLM and a very short line with no SRM variance I never run my line at less than 3dB.
iirc you have g.inp back? (havent checked). If so it perhaps doesnt matter quite as much, but it could only take one more disturber to be added or SNR blip when youre not around for the DLM gods to kick in.
Look whats happened to my own (good) line this week when I wasnt around to notice something happening and now Im stuck with Interleaving and ~14Mbps off my headline rate. :(
-
Hi, kitz.
Check MDWS as I'm uploading to it now, as you can see the line is very stable and yes G.INP is active on the line.
I will monitor it, but I think what your line experienced is a seperate issue, that's very unlikely to happen on my line.
-
As you can see the line is very stable
Your definition of stable is very different to mine!
Your line is correcting a hell of a lot more errors than it used to be also looks like some of the tones on your line have either lost connection or are sittings a 0db snr...
Also noticing how your SNRm is starting to fall too, currently its flicking between 2.5db and 2.4db
-
Look, it's fine, there are no Downstream ES and the SNR Margin is stable. It's always been at that SNR Margin since the resync!
-
No Will, the SNR margin is not stable and no the SNR is lower than when you resynced.... and I'm not even poking fun at the fact when you resynced your target 6....
-
No, you're incorrect. When the modem resynced the Downstream SNR Margin was nearly 3 dB not 6 dB. :lol:
-
I very much doubt it. You probably synched at the normal target of 6 and then quickly dropped to 3 as other users connected.
-
Yeah, that's a point. My apologies. :-[
-
Is this going to be another thread where the OP laughs at all the advice from people with vast knowledge on the subject. Then when DLM dicides to band and/or add additional interleaving proclaim that all the above people are idiots?
-
Unbeliveable! Are you crazy? DLM will not make any changes to the line as it's in the green state, it will only resync to get the SNR Margin back to 6 dB at some point. Sorry, but please watch your words, you've come over very offensive! Oops!
I've also got a very good knowledge of this subject, thank you very much!
-
Did she? Ive not been around much this week and only just seen this thread :-\
Admittedly Ive always said SNRm dropping if you're one of the first to sync up after a power cut is normal.
However, I've always advocated that running a line below 3dB is not good. Especially one that has daily SNR swings.
You're opening yourself up to increased risk of errors and DLM intervention.
Even when on LLU with no DLM and a very short line with no SRM variance I never run my line at less than 3dB.
iirc you have g.inp back? (havent checked). If so it perhaps doesnt matter quite as much, but it could only take one more disturber to be added or SNR blip when youre not around for the DLM gods to kick in.
Look whats happened to my own (good) line this week when I wasnt around to notice something happening and now Im stuck with Interleaving and ~14Mbps off my headline rate. :(
O_o :( not good kitz.
/me trots of to MDWS to check.
30k ES out of nowhere, any idea what happened jul 12?
-
I don't know, I thought that when I first saw it but it can.
Well, I just tried that and it didn't make any difference, thought it was absolute rubbish!
-
Hi, kitz.
Check MDWS as I'm uploading to it now, as you can see the line is very stable and yes G.INP is active on the line.
I will monitor it, but I think what your line experienced is a seperate issue, that's very unlikely to happen on my line.
Because youre not continually uploading stats then its hard to see the wider view and the exact stats at time of resync.
Having just looked at your graph, I will confirm that the daily variance of 1.5 dB is within normal range. This is fine.
The 0.1dB jitter is also perfectly normal behaviour. This is fine.
As far as DLM is concerned then your CRC and E/S error rate is fine.
Without doubt its G.INP that is keeping your line stable - look at how many Retransmits there are compared to other lines which average 1 or 2 retransmits. Youre averaging about 20+ per min and also some increased spikes. I cant see any period in the graph where ReTx are nil. Your LEFTRS counter is also racking up. This is not so fine.
G.INP works in the background only when needed. Continual G.INP retransmits mean that your router will be having to work harder and there will be some increased (but small) amount of latency whilst ReTX is happening. Basically they are like silent CRCs that are being corrected between the modem & dslam, rather than PC and remote server.
Yes you are stable, but that line is working hard without much margin for error, as I mentioned above it could just take one slight thing to risk the wrath of DLM. Letting a line that is known to have daily swings run at 2.5 dB is IMHO not always a good idea. You're sailing very close to the wind. Ive just had a look at some other G.inp lines and cant see one that looks quite like yours. There's some that show expected spiking but yours is continual. I dont have a clue what is acceptable for ReTX, but for CRC anything above 60 is bad.
-
O_o :( not good kitz.
/me trots of to MDWS to check.
30k ES out of nowhere, any idea what happened jul 12?
See thread here (http://forum.kitz.co.uk/index.php/topic,18088.0.html). Could be co-incidence but the cab had just recently rec'd the xx206 update. Start and stop times appear to correlate with times when the cab would be uploading DLM data (10-11 am & pm). I'd guess it was cab related rather than line specific.
-
Thanks, kitz.
As you have explained, the line is in good shape except for the ReTX errors, I didn't really think these errors were actually an issue (thought it was just CRC's). I will keep my line on MDWS, I'm pretty sure the modem is fine. :)
-
Well, I just tried that and it didn't make any difference, thought it was absolute rubbish!
Dont think Ive personally ever seen a case where downloading has affected the SNRm. I have seen cases where downloading can increase the error rates, but that perhaps is more understandable.
-
Dont think Ive personally ever seen a case where downloading has affected the SNRm. I have seen cases where downloading can increase the error rates, but that is more understandable.
I don't understand how as DSL and internet are totally seperate. Whatever you do on the internet doesn't have any impact on the physical line coming into the property.
-
As you have explained, the line is in good shape except for the ReTX errors, I didn't really think these errors were actually an issue (thought it was just CRC's). I will keep my line on MDWS, I'm pretty sure the modem is fine. :)
Just be aware you've taken on the good bits but avoided the warnings.
Also be aware that G-INP Retransmit TX are in effect the equivalent of CRCs. They are the same type of errors (failed data) but handled at a different layer - ie the router doing the retransmits rather than say TCP on the PC.
-
Right, so I'm getting hundreds of CRC's a day?! How come they're not appearing on the CRC counter and DLM isn't taking any action?!
-
A CRC (http://www.kitz.co.uk/adsl/error_correction.htm#CRC) is a counter for corrupt data packet(s) that needed to be re-requested.
G-INP Retransmit TX is a counter for corrupt data packet(s) that needed to be re-requested, only in this case its done at the the physical layer.
-
Crikey, I didn't realise that, thanks. :)
-
With ADSL though, downloading or not made no difference to the amount of CRC or other errors, if the CRC rate is very high, then you won't be able to transfer any data successfully. But that's because it's constantly sending and receiving idle ATM cells when not transferring any higher level data. VDSL2 uses PTM not ATM, but I think it still sends and receives idle PTM codewords (64/65-octet coding) when not transferring any higher level data. I think G.INP will re-transmit idle codewords, I don't think it "knows" not to bother if they don't contain any actual data.
kitz, didn't you recently have several hours with vast numbers of CRCs? I assume you weren't using your connection at a constant rate the entire time.
Anyway, I thought the point was that William Grimsley's line currently has a lot of work for G.INP to do, compared to other lines which have very little for G.INP to need to re-transmit anything.
-
In fastpath, it is only CRC, ES and SES that give you a feel for how the line is working
In old-style FEC+interleaving, it changes to FEC, CRC, FECS (rarely visible), ES and SES.
With retransmission activated, it becomes FEC, retransmit-tx, CRC, FECS (rarely visible), LEFTRS, ES and SES.
DLM is likely to only react to ES - but that is (and always will be) something of a guess about how a hidden system works.
A reminder: Statistics gathering (such as MDWS) only works when you can compare an idea of "before" with that of "after". If it isn't running when an event occurs, it is already too late to ever see the picture of "before".
-
I know I sound like your typical customer, but the modem resynced by itself, I didn't make any of this happen, I just want to leave it be because it's obviously happy if it hasn't lost sync yet. :)
-
Taking a broad, overview of the circuit's behaviour for the last 24 hour period (the "traffic lights" image, attached below) we see that there is
very little nothing that could cause the DLM process to intervene. No DS ES, just 48 US ES and no resynchronisation events. Everything in the "green zone".
Looking at the various plots for the same time-frame, we can see that the circuit is reacting to RF ingress during the hours of dusk to dawn. The SNRM, FEC and Bit Swapping plots look somewhat "dramatic" but when they are each viewed in a full screen, respectively, there is nothing significant.
Overall it would be interesting to see what, if any, events occur with that circuit in the forthcoming days/weeks/months.
-
I know I sound like your typical customer, but the modem resynced by itself, I didn't make any of this happen, I just want to leave it be because it's obviously happy if it hasn't lost sync yet. :)
I don't know if you're still around William, but here's a story of what happens when the resync happens and results in a lower SNRM of around 1dB:
http://forum.kitz.co.uk/index.php/topic,18102.0.html
There is no black-and-white answer here. It is all a case of risk management ... and a low SNRM value just makes for more manual monitoring effort.
-
Line in a bit of a mess this morning as you can see on MDWS. Not sure what's causing it. :/
Aha, there's an Openreach engineer working on a pole near the bottom of our lane!
-
Aha, there's an Openreach engineer working on a pole near the bottom of our lane!
Why would that interfere with your line... to be honest looking a MDWS I can't see anything irregular... *ahem* or even even 'more' irregular than its current status which is low SNR, increased error correct rate and traditional affects of a long unstabl'ish' line.
What's the issue you had?
-
Check the Downstream CRC Errors, there's a huge amount showing there especially in a short space of time.
(https://i.gyazo.com/0cb0f50aeae0ead7adcee01ce67c77a5.png)
Just to let you know, the line is not long, check the line attenuation.
Recently, there has been more Downstream CRC's per day than there was a few weeks ago on the line. Something isn't right.
-
Well, the fact the weather has changed since the other week, also if your saying BT was up a poll that probably means a new connection coming on to the network so potential crosstalker....
As for your line length... its certainly not short, my Sky connection in Brum which is connected to an ECI cab, is considered long (750+m) yet that's happy to get 61/12....
Anyway, don't go calling BT, they might ask you to reset your modem :)
-
Could be another connection, but to me it looked like a fault being fixed. Why would I call BT? That's the last thing I want to do.
Anyway, my original issue hasn't been explained, I have no idea what caused the Downstream CRC's, but it certainly wasn't crosstalk.
The Openreach engineer has only just left the lane, he's been fiddling next to quite a few poles. :lol:
Oh, and I highly doubt it's got anything to do with the weather. I'd have expected a slow rise in CRC's, not spikes.
-
Check the Downstream CRC Errors, there's a huge amount showing there especially in a short space of time.
(https://i.gyazo.com/0cb0f50aeae0ead7adcee01ce67c77a5.png)
Just to let you know, the line is not long, check the line attenuation.
Recently, there has been more Downstream CRC's per day than there was a few weeks ago on the line. Something isn't right.
That line is considered long attenuation is the same as mine. It's over 1000m to the cabinet
Sent from my SM-G935F using Tapatalk
-
Alright.
-
I must apologise to mlmclaren, my mum asked the Openreach engineer what was going on and he said he was installing a new line into a property up the lane. What makes me curious though is why did the SNR Margin increase and then decrease shortly after? Was the previous line disconnected (SNR Margin increased meaning less noise and crosstalk) then the new line connected (SNR Margin decreased meaning more noise and crosstalk)?
-
I guess it's nothing more than the engineer moving wires in a big bunch of wire pairs around, to access an unused pair in an existing cable, and then tucking them all back in when they had finished.
-
I see, I think he needs to be more careful, he could create several LOS! :lol:
Oh, my god! 2 Upstream SES!
-
If you keep watching your stats with so little spare SNR errors from time to time including the SE kind are normal and acceptable as you're willing to leave the line in its slightly more unstable state.
I would say a few upstream errors are to be expected and shouldn't cause to much of an issue unless you're noticing problems with using the connection such as packet loss.
-
Fair enough. :)
But, I'm not "willing to leave the line in its slightly more unstable state"!
-
But I thought you are leaving it at the high bandwidth and lower SNRM state, i.e. the more unstable state, rather than manually triggering a re-sync to go back to the lower bandwidth and SNRM around 6.
-
That's the router's choice not mine, the line is stable in it's current state.
-
And you have chosen to leave it like that rather than switch it off for half an hour then back on again.
-
Of course I have! Why would I want to experience a decrease in rate just for a few errors on the line? Seriously, I do not get some people on here.
-
But, I'm not "willing to leave the line in its slightly more unstable state"!
Therefore reboot it and let it sync at a more decent speed.
Of course I have! Why would I want to experience a decrease in rate just for a few errors on the line? Seriously, I do not get some people on here.
William, you are the one who posted the update about errors on here and we have given advice. For example those upstream SES you saw are purely down to the SNR margin being so low and the router/modem struggling to "hear" the FTTC cabs signals. Its perfectly normal behaviour, but it is not expected behaviour as you are running your line in a way its not necessarily designed to be.
-
Sorry, but I'm leaving it alone, I am not going to start rebooting the router when I get a power surge.
Anyway, the Downstream ES have increased slightly since the new customer was connected.
-
Sorry, but I'm leaving it alone, I am not going to start rebooting the router when I get a power surge.
Anyway, the Downstream ES have increased slightly since the new customer was connected.
The errors will increase due to increased noise.
-
Understood. I hope I haven't annoyed anyone again, I took some time away after I had a bit of a angry moment on here the other week. But, I just want to leave things alone now and see how they pan out. :)
-
Its strange how some lines can cope with lower SNRM than others unlike my own for example was syncing at the max DS of 39998 Kbps 40/10 and the SNRM was 6.8dB during the day but once the evening RFI hit just after 20:30 the SNRM started to drop and then became spiky with CRC error burst and SES
The line gave up when the SNRM hit 4.0dB and a DLM resync was activated for this 1000 meter line so must be at the very limit even with a target margin of 6dB.
-
It is interesting, and makes me think it's something to do with the cabinet more than anything, I can't understand why DLM would resync some lines at a SNR Margin of 4 dB and others not, especially if all the lines in question are experiencing low errors.
-
Are you certain it's really the DLM mechanisms triggering the re-sync? Or is it merely one or other end of the connection deciding it is unable to maintain the connection due to the changed conditions, and so forces the connection to retrain? I don't think any particular retrain reason number given really proves it was the will of the DLM.
-
I definitely think the DLM for my cabinet is very sensitive even a change of SSFP from MK3 to MK2 to is enough to get 3 retrains by the DLM and when the SNRM has hit 4.0dB not one retrain comes in but 2 in under 24 hours so different to other on MDWS
As I said near the start of this thread you gain a lot of knowledge from your own lines behavior over the years but one thing is for certain no two lines behave the same way even if the stats are identical.
-
There seems to be an increase of Upstream CRC errors on the line now. You'd normally see this when a phone call was coming in but in the last 2 instances, the phone didn't ring. :/
The cause has to be that the Openreach engineer has snagged our line pair... The huge amount of Downstream CRC's yesterday morning didn't occur today, and those coincided with the Openreach engineer being in the area so it seems a given to me.
-
CRC's on the upstream nothing to worry about and there still is G.INP on the upstream on Huawei cabinets if it all turns to red (2880 errored seconds in 24 hours) ;D
-
Yeah, I suppose they were more of an issue on ADSL. Also, as Upstream is the E side, it still comes all the way from the exchange!
-
Yeah, I suppose they were more of an issue on ADSL. Also, as Upstream is the E side, it still comes all the way from the exchange!
the entire vdsl signal is d-side, then from the cabinet both downstream/upstream travels along fibre. only voice is now e-side
-
E-SIDE (Exchange Side) - Exchange to PCP
D-SIDE (Distribution Side) PCP to Customers
-
Oh, I see! Does "voice" mean telephone then?
-
Does "voice" mean telephone then?
Yes, it does.
-
Not sure William if you have come across this scenario before
The larger exchange is 4.6 Km is feeding the broadband or Fibre to FTTC cabinet and the smaller exchange 0.6 Km is feeding the voice/telephone to PCP cabinet that is how it's working for me.
Others will have the Fibre & Voice/telephone coming from just one exchange
-
Yeah, I've heard about that. If I recall correctly, this was discussed in a different thread a short while ago. I think the fibre comes from the Sidmouth exchange to the fibre cabinet and the voice comes from the Colaton Raleigh exchange to the PCP.
-
Upstream looks "shot" today.
-
. . . this was discussed in a different thread a short while ago.
I have a vague recollection of that discussion. ;)
I think the fibre comes from the Sidmouth exchange to the fibre cabinet and the voice comes from the Colaton Raleigh exchange to the PCP.
Yes, that certainly seems feasible. Until told otherwise (by someone with access to the relevant network records), I would accept the above. Perhaps when you next see Glen (or is it Glenn? -- you have used both spellings in your earlier posts) he could tell you?
-
Upstream looks "shot" today.
Your experiment continues.
Has there been any recent change in the weather or other environmental conditions, perhaps?
-
I have a vague recollection of that discussion. ;)
Yes, that certainly seems feasible. Until told otherwise (by someone with access to the relevant network records), I would accept the above. Perhaps when you next see Glen (or is it Glenn? -- you have used both spellings in your earlier posts) he could tell you?
It's Glenn, oops. So, for all the posts that I can't edit which say Glen, it's Glenn. I doubt I'll be seeing him unless I get another fault which does seem possible with the Upstream looking like it is.
Your experiment continues.
Has there been any recent change in the weather or other environmental conditions, perhaps?
Haha, yes it does. With regards to the weather, no not really, it's been a fine day with some sunny spells. We are forecast heavy rain and slightly windy conditions tomorrow which always used to cause issues in the past when we were on ADSL. Plus, thinking about it, after the recent brief heatwave, no doubt the line has been slightly worn by this, so the wind and rain could cause some water ingress issues, but we shall have to see.
-
Work starts today for 2 days to replace a power pole on the lane, not sure which power pole this is, but it could interfere with our broadband connection. Also, whilst this work is being completed, heavy rain is due so could be an interesting 48 hours.
Interesting how the Upstream is more stable today now we have rain, the sun must've been having an impact.
-
I have to say that, if there were a risk of power interruptions (such as the replacement of a power pole that serves my property), I'd take the precaution of turning most things off, especially including the modem.
That'd interfere with the experiment, though...
-
Well, the power engineers have been and gone and as you can see, we've not had a power cut, so the experiment continues. :)
-
I definitely think the DLM for my cabinet is very sensitive even a change of SSFP from MK3 to MK2 to is enough to get 3 retrains by the DLM and when the SNRM has hit 4.0dB not one retrain comes in but 2 in under 24 hours so different to other on MDWS
As I said near the start of this thread you gain a lot of knowledge from your own lines behavior over the years but one thing is for certain no two lines behave the same way even if the stats are identical.
I'd find it hard to believe that DLM paid such real-time effort to monitor all lines closely enough to jump in at 4.0dB.
However, the DSLAM can be configured with an SNRM threshold at which a resync will be triggered - this is one of the standard configurable items in the line profile.. I've not heard of this parameter being varied by DLM, but it certainly could be.
If this parameter were set at 4dB for your line, then the DSLAM would drop the sync whenever SNRM dropped to 4dB or less, which matches your experience, but isn't quite the same as DLM monitoring directly.
The threshold can't be set to 4dB for every line - we've seen reports of sync surviving down to 0dB - and IIRC, 0dB is the default.
I could believe that DLM calibrates a line by observing how much the min & max SNRM values change each day, and deciding whether a changed threshold was necessary. It would actually be the first step I'd design if I were asked to implement a DLM that could vary the /target SNRM/ from 6dB to 3, 4 or 5dB. Which, of course, we've heard rumours of...
-
Well, the power engineers have been and gone and as you can see, we've not a power cut, so the experiment continues. :)
Fingers crossed for lady luck on day 2.
-
Yeah, they've been and gone and completed the work, as far as I know. :)
-
However, the DSLAM can be configured with an SNRM threshold at which a resync will be triggered - this is one of the standard configurable items in the line profile.. I've not heard of this parameter being varied by DLM, but it certainly could be.
That would sound right as when you think about it the DLM gathers up data for 24 hours and then acts on what it see's on the next 24/48 period, So a sudden drop of SNRM to 4dB and immediately my line resyncs that does not sound like the DLM to me.
Thanks WWWombat for helping me understand this odd issue that has been with since day one.
And that may explain why William has a lower SNRM after power cut the DSLAM must still think he is on the 6dB target margin one of those quirks of crosstalk during quick modem resyncs :-\
-
Brilliant, HRJ fault starting on the line!
-
There's been another spike of Downstream CRC's on the line, something's starting to happen.
Could be something electrical turning on but I'm not sure. The amount is slightly concerning.
-
Numerous posts removed and thread locked.