Kitz Forum
Broadband Related => ADSL Issues => Topic started by: g3uiss on June 17, 2018, 05:34:15 PM
-
I’ve been having issues with my 2nd line which is ADSL2. For years it performed well but after a series of phone faults it seems impossible for OR to get the broadband stable.
To me the errors look well below that requiring a DLM intervention but again this morning after a DLM reset it put my SNR up to 9db. I’m willing to bet tomorrow it will go to 12db.
Any comments on my stats which I might not have noticed is at
www.west-Lodge.com/adsl/index.htm
I’ve only just turned on uploading so there are no snapshots, but there will be one after 1800.
I really can’t see why the DLM keeps slowing me down 😰 Tony
[Moderator edited: asdl --> adsl]
-
Should be: http://www.west-lodge.com/adsl/index.htm
;)
Thanks 😄
-
I've taken a look at your statistics and cannot see anything obvious to account for the problem.
The QLN and Hlog plots show a relatively good metallic pathway, with just a touch of RFI at ~1007 kHz.
-
What is your router? I guess: Netgear DGND3700.
-
What is your router? I guess: Netgear DGND3700.
Huawei HG612
-
Tried a different modem/modem PSU?
Modem attached directly to wall or extension bar? Tried different ones?
What other devices are within a 2 metre radius of the modem?
Are you using powerline ethernet anywhere?
-
HG612, connected to Draytec 2925.
No Powerlines. Straight into latest BT faceplate, no internal wiring. Other devices, another HG612 for my VDSL, UPS, and apart from router and PC nothing.
Sort of what I thought, must be a excahnge / DSLAM issue ? Saw the RFI at 1Khz (tone 230), but its seems minor and the same blip on my VDSL circuit. Last option to tray a different modem, but reluctant as it only happend post voice issues on line (noise followed by no dial tone)
Thanks for thoughts
Tony
-
Might be worth trying those, short, twisted RJ11 cables for each modem as well as moving them as far away from each other as possible.
-
Saw the RFI at 1Khz (tone 230), . . .
Your calculation is a little bit off. ;)
230 x 4.3125 kHz = 991.9 kHz
Have you tried swapping over the two modems and seeing if the problem moves with the device?
-
Hi I meant to add the zero's ! No not swapped, because I have exactly the same spike on my VDSL circuit so I guess its something local.
I've had no issues with my VDSL said he touching the wooden desk. So I would expect the same spike. Any thoughts what goes on at that frequency, I know its below amateur Top band, we have no radio installations in this area.
The ADSL DLM re synced again this AM, it actually brought down my SNR from 9 to 8, but the spike remains in exactly the same place. Its also there despite the time of day, so its constant 24/7
:(
-
Location Watts NGR
R Devon Pearce's Hill, Exeter 1000 SX931881
Radio 5 Live Tywyn, Gwynedd 1000 SH581004
Radio nan Gaidheal Redmoss, Aberdeen 1000 NJ942024
Magic AM Crimpsall, Doncaster 250 SE566032
Classic Gold WABC Sedgley, Dudley 90 SO905939
-
I can't particularly see anything on the physical side of things.
The small noise spike circa tone 330 on QLN graph doesn't actually appear to be having too much of an effect, other than reduce your bit loading by 2 bits at the corresponding tones, thus we are only talking about a few kbps.
What I find more puzzling from the bitloading graph are several tones without any bitload. If you look closely on your hlog they appear to correspond with gaps in hlog too.
-
I’m no where near the quoted radio transmissions.
Yes I noted the gaps in the bit loading. There a couple on my vdsl line but fewer, while the QLN spike is in the same place.
I’m to have another OR engineer on Thursday I really can’t see anything from the stats causing the erratic performance and the DLM taking action every morning with the SNR.
Tony
-
Although I'm only basing on one QLN snapshot, IMHO the QLN spike is negligible.
I can't think what could be causing the 0 bitloads. There is nothing on QLN to show any noise at the corresponding tones. The pattern isn't typical of bridge tap or capacitive issue which is what hlogs usually show, but it does appear to be fairly evenly spaced at some points (appx every 50 tones).
Scratching my head as to what may cause 0 bit load but QLN gives no indication of noise at those tones. The fact those gaps are there on hlog shows whatever it is was there at the same time QLN would have been recorded during sync time.
b*cat have you ever seen anything like that pattern before, because I can't say I can recall doing do in the 15yrs I've been reading stats. Admittedly hlog hasn't been around that long, but you would expect to see corresponding low readings in [true] SNR per tone which used to be spewed out by the stats back then.... which goes back to QLN is OK :puzzled:
-
b*cat have you ever seen anything like that pattern before, . . .
Earlier this evening, when you mentioned the zero bit loading, I went back and took another look at that plot . . . and came away puzzled. I'm not too sure that it is regular spacing -- I think it is another example of "seeing a pattern that isn't really there".
What might be interesting is to search the raw data for each occurrence of zero bit loading and then calculate the frequency of each unused sub-carrier.
In answer to your question, above, my response is "no, never". (I wonder if Konrado5 has ever seen anything similar?)
-
It's hard to tell because of the scaling, you may be right about the pattern but to the naked eye they seemed around every 50 tones.
Looking at the raw data is the only way to confirm, but when I zoomed in a bit on the graph they appear to be ~
110
127
188
192
244
292
347
One of them will be the pilot tone
-
It seems to me that I've seen something similar on some graphs on this forum. I think there are some tones disabled on DSLAM.
-
I've seen blocks of tones disabled many times - usually at the end of the adsl2+ range. I've never seen interspaced tones disabled on the DSLAM like that though - certainly not in the UK.
g3uiss is quite local to me (& iirc same ISP) and I'm not aware of Openreach/BTw doing any ham/radio blocking in this area. We're not even near any large transmitters, so it would have to be something more localised to him.
-
PS
If g3uiss has a few mins to spare & nothing better to do, it may be interesting to compare those missing tones raw data with bit allocation on the VDSL line to see if it does affect both.
-
Could a navigational beacon (or other aid) account for the QLN blip?
As for the zero bit loading, one would certainly be due to the pilot tone . . . but I can't remember which frequency that would be.
-
Pilot tone have 2-bit loading on ADSL2+. Here is example on my circuit.
-
Could a navigational beacon (or other aid) account for the QLN blip?
~230 is clean here so wouldn't have thought so. My guess would be something in direct neighbourhood.
Whatever it is, it's only costing 2 bits in the bin so ~8kbps. As long as its static and not being a nuisance by causing lots of bitswap (check bitswap graph) at around that tone then its not worth losing sleep over.
As for the zero bit loading, one would certainly be due to the pilot tone . . . but I can't remember which frequency that would be.
Not much point remembering. Once upon a time it used to be tone 64. Now it varies, which is why I commented a rather vague "one of them". :/
-
Pilot tone have 2-bit loading on ADSL2+. Here is example on my circuit.
Tone varies depending on numerous things. It's not even SP dependent... for example yours are ~tone 420, which would be perfectly useless for those lines who can't get more than ~17Mbps. Also isn't that in the range that your ISP has DSLAM blocked for 99% of their other users.
I love your graph. Perfect example of how crosstalk also affects ADSL2+.
Can clearly see the effects from those who only get ~8Mbps, then that lovely bump at the end where you are the only user on the DSLAM with the unblocked tones.
-
Pilot tone is selected by CPE. I have slightly different pilot tone on different synchronization.
-
PS
If g3uiss has a few mins to spare & nothing better to do, it may be interesting to compare those missing tones raw data with bit allocation on the VDSL line to see if it does affect both.
The only tone with 0 bit loading is 328 on the VDSL circuit, so its not common to both. The single noise blip is exactly the same on both circuits. I suspect its just an anomaly.
All that said, ISP said they would reset the profile in an effort to sort it, hoping to avoid a visit (difficult for personal reasons to available for either full AM or PM time slots) .
Result:- DS SNR now at 6.1 US SNR now at 12.6 Interleave on US & DS at 8 delay Inp on US only at 2.
So now I'm worse off than ever. I'm awaiting their next update. Iv'e just turned on uploading to put current stats at www.west-lodge.com/adsl/index.htm
@Kitz is right, no radio stuff in this area (Nearest is HMS site which I think is very LF comms)
Not really worried about that single spike as commented it has little effect.
Thanks for all the input
Tony
-
Your encapsulation errors are through the roof. There's no point resetting the profile, lol. You'll be interleaved before long, I guess.
Turn the VDSL modem off for 24 hours.
Power cycle the ADSL modem. Let's see if your prolific error rate persists?
-
Hi @boost. Please explain encapsulation errors. The two services have run togeater for around 5 years ?
Only started after phone problems with water in the DP
Tony
-
Could a navigational beacon (or other aid) account for the QLN blip?
As for the zero bit loading, one would certainly be due to the pilot tone . . . but I can't remember which frequency that would be.
The nearest beacon is an NDB which operates on 318 kHz.
It’s low power supposed to have a range of 15 miles, but that’s optimistic and around that distance from me in a straight line.
I think whatever is local and on 24/7. But as said the effect is minimal.
-
Pilot tone is selected by CPE. I have slightly different pilot tone on different synchronization.
There's different methods. Static, determined within a range by the SP, set random within a range... or adaptive which can depend on line analysis and can also change when either the CPE or DSLAM detects that there is too much noise on that tone.
Number of pilot tones depends on amount of data transmitted by the pilot tone and if bitswap is in use.
Was just trying to keep it simple by saying its no longer worthwhile trying to remember them and why I used the term 'varies' and 'one will be' because we are unsure which method the DSLAM will be using. At one point TT's MSAN's appeared to be using 'random within range' Openreach/BTw use several different makes of DSLAMs/MSANs so I don't know which method is being used in this particular case. :/
-
So now I'm worse off than ever. I'm awaiting their next update. Iv'e just turned on uploading to put current stats at www.west-lodge.com/adsl/index.htm
Just had a look. Those missing tones are still there in the same place.
Considering Interleaving is now switched on, its done absolutely nothing to help.
In fact if anything, your CRC's and Err Secs appear to have increased and you've also had some SES errors. :( Lower SNRM is noted.
:'(
-
Just had a look. Those missing tones are still there in the same place.
Considering Interleaving is now switched on, its done absolutely nothing to help.
In fact if anything, your CRC's and Err Secs appear to have increased and you've also had some SES errors. :( Lower SNRM is noted.
:'(
Would you think that’s an exchange issue as nothing changed locally.
-
I cant think of anything exchange side which would cause that. Faulty line cards can cause strange problems that can look REIN like, but on 21CN BTw MSANs these are usually spotted easier than older line cards and even vdsl line cards due to the amount of lines they control.
The lower SNRM could/will in part be responsible for an increase in errors, but by the same token I'm surprised that FEC isn't making much difference and at least reducing some of the errors. I'm talking totally off the top of my head but that suggests its not noise from RFI/EMI bursts as we usually see but ingress from another source. With the missing tones I'm beginning to wonder about a possible oxidised joint somewhere, but I'm not seeing any typical signs of a HR fault either from your graphs. ???
Is the line clear if you do a Quiet Line Test?
b*cat is far better at electronics than me, so passing over to him his thoughts on whether he thinks an oxidised joint could possibly cause these types of symptoms despite it not being anything we've seen presented before. Otherwise I'm scratching my head.
-
Is the line clear if you do a Quiet Line Test?
Just another suggestion to see if you can pick up any symptoms of a High Open. Temporarily set DSLstats to record every 5 seconds.
Ring the landline from another phone, let it ring for a couple of rings (sufficient for DSLstats to have made a recording), then pick up the receiver to open the line for a sufficient length of time for DSLstats to have made another recording.
All the while carefully watching the Upstream SNRm graph for signs of any dips or spikes.
-
Just another suggestion to see if you can pick up any symptoms of a High Open. Temporarily set DSLstats to record every 5 seconds.
Ring the landline from another phone, let it ring for a couple of rings (sufficient for DSLstats to have made a recording), then pick up the receiver to open the line for a sufficient length of time for DSLstats to have made another recording.
All the while carefully watching the Upstream SNRm graph for signs of any dips or spikes.
Line is clear, but I recently had a line card changed which is when it all started. I will try the phone test you suggest later.
-
A bit more history might be useful.
Line fault on previously excellent line Feb-April this year. Eventually cleared but, for first time Interleave needed DS to keep it stable
2 weeks ago sudden slow speeds SNR put up to 12 by DLM.
Isp identified line card problem. This replaced.
Profile set at SNR 6 US/DS no interleave.
DLM action every night increasing SNR and Interleave, eventually speed poor and below MGALS
Various interventions by ISP. Yesterday they put SNR back to 6 US/DS no interleave. This morning DLM raised SNR again to 9
The ES rate appears to be below the "Red: from my understanding as I assume its 2880 like VDSL.
I have resisted a visit because personal circumstances don't give a clear AM or PM slot (I think @kitz) know about this
Iv'e just uploaded stats agian
Tony .....at wits end :(
-
Just another suggestion to see if you can pick up any symptoms of a High Open. Temporarily set DSLstats to record every 5 seconds.
Ring the landline from another phone, let it ring for a couple of rings (sufficient for DSLstats to have made a recording), then pick up the receiver to open the line for a sufficient length of time for DSLstats to have made another recording.
All the while carefully watching the Upstream SNRm graph for signs of any dips or spikes.
Nothing perhaps a very slight US blip of less than .1db only could see it if I made the page a very short time period.
-
Nothing perhaps a very slight US blip of less than .1db only could see it if I made the page a very short time period.
Very tiny blip and negligible. I'd be concerned if it took a downwards dip, but it looks fine.
Isp identified line card problem. This replaced.
Do you know for certain if the line card was replaced? Usually you get a small amount of downtime when they swap the line card out or at least a minute or two if they do a lift and shift.
Typical line card problems display symptoms that look quite like REIN. From what I have seen so far your SNRM is fairly straight lined.
The ES rate appears to be below the "Red: from my understanding as I assume its 2880 like VDSL.
WBC MTBE actually more forgiving than NGA. I don't understand either why DLM is penalising you as you are below the latest figures that I have unless something has changed again. WBC MBTE for standard was decreased from 300 to 250 in 2014.
Looks like DLM has increased target SNRM but removed Interleaving.
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 45 1
ES: 697 1
SES: 31 0
UAS: 415 384
LOS: 3 0
LOF: 26 0
LOM: 0 0
Oh - you do have quite a few Loss of Framing (https://kitz.co.uk/adsl/linestats_errors.htm#LOF) which are classed as line failures.
It may be worthwhile keeping an eye on that figure, I'm a wee bit more concerned over the LOFs than your Err/Sec count. The combo of SES & LOF can indicate longer duration of noise bursts. FEC doesn't always work well for longer duration noise bursts. Beginning to wonder if DLM is detecting & acting on that rather than the Err/Sec count.
I have resisted a visit because personal circumstances don't give a clear AM or PM slot (I think @kitz) know about this
.....at wits end
I fully appreciate why it is difficult :( Wish I could help more but I'm running out of ideas based on your stats. :(
-
Hmmmmm just been reviewing your posts and noticed this
Only started after phone problems with water in the DP
Water ingress!!!!
See Locating water ingress in telephone cables using frequency domain reflectometry (https://ieeexplore.ieee.org/document/1556938/)
When water enters a cable it lowers the magnitude and angle of the characteristic line impedance, causing reflections at the points where the water starts and ends. The dry and wet characteristic impedances of a 300-meter section of telephone line were experimentally measured and the reflection coefficient was estimated to have a phase angle of 20deg. Measurements of a properly terminated telephone line with 300 meters of the line immersed in water showed a first reflection with a phase angle of 162deg (180deg-18deg). A second reflection, from the end of the wet section, was measured with a phase angle of 25deg. These reflection angles differ from the 0deg or 180deg typical of bridge taps, open circuits or short circuits and this allows a technician to specifically identify water ingress
Is this why we are seeing those more or less evenly spaced 0 tones in hlog. hlog usually identifies bridge taps by identifying the point of reflection.
I'm out of my depth here as it would require proper tools to diagnose. Any thoughts from b*cat, ejs or Blacksheep please.
-
I guess that those zero bit loaded tones with corresponding gaps in the HLog are "blackout" tones with no signal, to allow noise monitoring. I think some of those tones show small dips on the QLN, suggesting there's less crosstalk on those tones perhaps because other lines also aren't using those tones. I think those gaps will be unrelated to whatever the problem is.
-
b*cat is far better at electronics than me, so passing over to him his thoughts on whether he thinks an oxidised joint could possibly cause these types of symptoms despite it not being anything we've seen presented before.
:hmm: Hmm . . . The symptoms are not characteristic of a joint developing HR or semi-conductive tendencies.
-
Oh - you do have quite a few Loss of Framing (https://kitz.co.uk/adsl/linestats_errors.htm#LOF) which are classed as line failures, but afaik these aren't counted as full retrains as far as MBTR is concerned.
It may be worthwhile keeping an eye on that figure, I'm a wee bit more concerned over the LOFs than your Err/Sec count. The combo of SES & LOF can indicate longer duration of noise bursts. FEC doesn't always work well for longer duration noise bursts. Beginning to wonder if DLM is detecting & acting on that rather than the Err/Sec count.
That's interesting, I was beginning to think the DLM is acting on something else. I will see what the DLM does tomorrow, I'm pressing for a visit week tomorrow, when I can make either slot. I just hope I can get a good engineer. The water in the DP is also interesting. The line was stable for many years until that problem, then it was never as good. As for the line card, I only have the ISP's word that the fault was cleared.
Thanks all for input, very grateful. Will post news tomorrow :)
-
Oh - you do have quite a few Loss of Framing which are classed as line failures
Every retrain caused by interferences = 1 LOS and 9 LOF.
-
Are these not related to all the resyncs caused by the ISP testing the line ?
-
Water ingress!!!!
See Locating water ingress in telephone cables using frequency domain reflectometry (https://ieeexplore.ieee.org/document/1556938/)
Is this why we are seeing those more or less evenly spaced 0 tones in hlog. hlog usually identifies bridge taps by identifying the point of reflection.
I'm out of my depth here as it would require proper tools to diagnose. Any thoughts from b*cat, ejs or Blacksheep please.
I am aware that a "wet cable" can be seen by TDR but have never had any experience of such a situation. I have always assumed that it is water inside the outer sheath, water penetration as a result of protective sheath damage, that gives rise to the effect. Unfortunately payment is required to download a copy of the PDF file.
Only started after phone problems with water in the DP
What we currently do not know is whether the DP is aerial or underground. With an aerial DP, I would be very surprised for any significant quantity of water to accumulate . . . even more so for such water to fortuitously submerge the end of a cable sheath, thus setting up a "wet cable". However if it is an underground DP, whose closure was defective at some time in the past, then there is a distinct possibility of significant water ingress.
I wonder if Black Sheep has had any experience of such a fault or knows of an occurrence?
-
Is this why we are seeing those more or less evenly spaced 0 tones in hlog. hlog usually identifies bridge taps by identifying the point of reflection.
I'm almost sure that these 0-bit tones are disabled tones. On QLN there isn't any significant noise. Moreover, there is no signal. If signal is very weak hlog looks jagged. For example, I've had jagged Hlog graph when I've had very low power output in HAM band mask.
-
What we currently do not know is whether the DP is aerial or underground. With an aerial DP, I would be very surprised for any significant quantity of water to accumulate . . . even more so for such water to fortuitously submerge the end of a cable sheath, thus setting up a "wet cable". However if it is an underground DP, whose closure was defective at some time in the past, then there is a distinct possibility of significant water ingress.
I wonder if Black Sheep has had any experience of such a fault or knows of an occurrence?
Underground DP and al cable all the way to the cab.
Another DLM at 0530 no significant changes except SNR reduced from 9.1 to 8.5. The only thing I hadn’t seen before just before the re sync the DS SNRM dropped to below zero. I recon this was on the DSL stats sample before the Re Sync.
I’ve just up loaded the stats to my web address. Very few errors I can see in this period
Tony
-
Looking at this post reminded me my dad had similar problem with Rodent damage to the underground cable feeding his circuit, BTOR had to replace the lot.....
Yes every time it rained errors went through the roof..
-
Interesting thought. Is the DLM more sensitive following a fault rectification?
The so called training period ?
I’m not sure where to press the ISP as the current speed is acceptable and I wouldn’t know about the re syncs if I didn’t monitor the line :)
-
I am aware that a "wet cable" can be seen by TDR but have never had any experience of such a situation. I have always assumed that it is water inside the outer sheath, water penetration as a result of protective sheath damage, that gives rise to the effect. Unfortunately payment is required to download a copy of the PDF file.
What we currently do not know is whether the DP is aerial or underground. With an aerial DP, I would be very surprised for any significant quantity of water to accumulate . . . even more so for such water to fortuitously submerge the end of a cable sheath, thus setting up a "wet cable". However if it is an underground DP, whose closure was defective at some time in the past, then there is a distinct possibility of significant water ingress.
I wonder if Black Sheep has had any experience of such a fault or knows of an occurrence?
Kitz PM'd me about this last night, and I have replied this morning stating how I'm as perplexed as yourselves with the missing tones ??
I did ask the question (as I had to speed-read the thread and wasn't 100% certain), if the OP was on an LLU service provider .... if so, then TAMS will play a part in the circuits make-up and may be a potential culprit ??
But, I have never witnessed graphs like that on either REIN or actual line faults ???
-
No I’m not on a LLU. May I ask what TAMS is. Not seen a reference to that before
Tony
-
I thought I'd seen Talk-Talk mentioned ?? Like I say, I don't have the time read threads fully these days.
TAMS = Test Access Matrix System
A functionality that allows Openreach to test non-BT circuits.
-
Thanks for that explanation. I’m pretty sure this plot has looked like that for some time, but couldn’t say how long. I never took much notice of these stats until problems started in February. Is hardware ie modem a possible problem ?
Also it’s not been power cycled for a long time but many re syncs since it was last. I haven’t got a modem to try that has a Broadcom chipset to compare.
Error rate seems to have fallen dramatically over last 24 hours.
Current average ES is 17/hour.
Tony
-
I need to do a longer reply. Started last night but hands are bad today.
Thanks BS for the comments.
I haven’t got a modem to try that has a Broadcom chipset to compare.
I'll PM you.
-
1st night DLM left me alone Horray !
-
Underground DP and al cable all the way to the cab.
Thank you for clarifying things.
With an underground DP and aluminium cabling there is the potential for mayhem following water ingress.
-
Thanks for that comment. Would those potential faults not show on the normal line tests done by ISP/OR, or cause a noisy line at my end 17070(2) .
It really follows, the Water problem cured a phone fault which started as intermittent, then one leg went. After that was fixed, the ADSL has been very erratic.
How do I get ISP/OR to look into that, any suggestions ?
Tony
-
Would those potential faults not show on the normal line tests done by ISP/OR, or cause a noisy line at my end 17070(2) .
Yes, I would expect some sort of anomalous result to be obtained.
It really follows, the Water problem cured a phone fault which started as intermittent, then one leg went. After that was fixed, the ADSL has been very erratic.
You really need someone like Black Sheep to be tasked with checking the circuit.
How do I get ISP/OR to look into that, any suggestions ?
The only suggestion I can make is persistence . . . Don't let your CP/ISP close the fault report.
-
Thanks @burakkucat. I think from BS earlier posts he’s some what short of time. I’m doing my best to keep the fault open.
It’s odd because the DLM is acting to reduce speed by raeducing the SNRM but the errors are well below what I believing should trigger that. The only issue is the ISP recons they reset line on the 15th so I’m in the 10 training period.
At the moment I’m syncing below their MGALS.
I think sometimes they are not happy with comments from users with some degree of Tecnical knowledge.
Tony
-
I strongly suspect its the number of LOFs which is upsetting the DLM, not the Err Secs.. which may also explain why its increasing the TNM rather than INP.
This is the reply I started the other night but didn't finish. I'm mega busy for the next few days and then I go AWOL for a while so I may as well post it now.
----------
It's looking like the LOFs can cause DLM action. But we have to be a bit careful if deciding whether an LOF could count towards DLM as you'd need to take note of the last retrain reason
According to your stats "Retrain Reason: 1" which we generally take to indicate that the resync was caused by DLM - see here here RDI detector code linky (https://forum.kitz.co.uk/index.php/topic,14598.msg274944.html#msg274944).
This sparks a few other questions, the main ones being
Is DLM using RDI codes for calculation of MBTR or ignoring any RDIs?
Do Line tests cause an RDI?
We may also have to be careful when distinguishing between retrain reason = 1 being an RDI and the RDI indicator mentioned in the ITU specification
RDI's only occur when an LOF is initiated at the DSLAM without a SEF defect.
LOF between the modem and DSLAM direction are highly likely to be counted towards MBTR.
Linestats show SFErrors but don't record what could be SEFs so we may not always know which downstream LOFs are being counted by DLM
From ITU G.992.1
D.2.1 LOF-rs: Loss of ADSL frame synch/resync event. This event occurs when some algorithm,
which may be vendor-specific, determines that a resync attempt is required. Note that this LOF-rs
event is probably (but not required to be) related to the SEF (severely errored frame) defect defined
for operations and maintenance (see 9.3).
So now lets look up the relevant sections relating to SEFs which trigger a LOF
9.3.1.3 ADSL line related near-end defects [path from the modem to DSLAM]
Severely errored frame (SEF) defect: An SEF defect occurs when the content of two
consecutively received ADSL synchronization symbols does not correlate with the expected
content over a subset of the tones. An SEF defect terminates when the content of two
consecutively received ADSL synchronization symbols correlate with the expected contents
over the same subset. The correlation method, the selected subset of tones, and the threshold
for declaring these defect conditions are implementation discretionary.
9.3.1.4 ADSL line related far-end defects [path from DSLAM to modem]
Far-end Remote defect indication (RDI): An RDI defect is an SEF defect detected at the
far-end and is reported once per superframe by the RDI indicator. The RDI indicator
(see 7.4.1.1) shall be coded "1" to indicate that no SEF defect is present in the previous
superframe and shall be coded "0" to indicate that an SEF defect is present in the previous
superframe. An RDI defect occurs when a received RDI indicator is set to "0". An RDI
defect terminates when a received RDI indicator is set to "1".
-
It is completely normal to see LOS and LOF counts like that every time the ADSL drops and reconnects (retrains). It seems the ADSL is dropping a lot.
Note that "resync" in the ITU documents does not mean what we usually call a resync.
I think sometimes it does not help to get bogged down in minute details of stats while losing sight of whatever the actual symptoms of the problem are.
-
It seems the ADSL is dropping a lot.
umm that was the point of my post. Since an LOS causes re-initialization, then I think its safe to assume that its line drops and not Err Secs that is the issue. Thus MBTR and not MTBE count triggering DLM. I pointed out in an earlier post I was concerned about the number of LOS.
I think sometimes it does not help to get bogged down in minute details of stats while losing sight of whatever the actual symptoms of the problem are.
Earlier g3uiss had mentioned about the SP performing line tests, so a few of those LOS will be DLM resyncs and line tests. We already know that DLM resync triggers an RDI. Admittedly slightly off topic, but that got me wondering if DLM took any notice of RDI markers (discounted them) when doing the MBTR calculation, which is why I mentioned it.
-
but that got me wondering if DLM took any notice of RDI markers (discounted them) when doing the MBTR calculation,
On reflection, likely not because it doesn't discount LPRs either.
-
But it is possible to have LOS events without them causing a retrain. However, in this case, they just look like lots of line drops, about 50 of them in the last lot of stats from 21 June.
-
Well it’s not had the DLM again.
I’m a bit confused with dates but on one day the ISP were doing line tests every 2/3. Hours. I thought it was just dropping but I compared the times with them and they were identical.
That must have been Wednesday as it had DLM action Thursday and Friday but not since. It’s also interesting that the comment about NM being increased rather than interleaving. So I’m leaving it alone, and see what happens, but I’ve put current stats up as at this morning. That might help as there has been no actual resync for 2 days.
Thanks for all the input,
-
PM'd ya, g3uiss. :)
-
I think the connection speed has been banded, rather than the target SNRM being increased.
-
Thanks EJS and also Black Sheep. I now have another modem (Zyxel) all configured ready to swap out. The intention is to see if the missing tones reappear. I suppose if they do that’s a positive result. If not it’s got to be back to the SP to sort with OR.
Interested what gives an indication of banding, rather than SNRM being increased. What makes the DLM chose that as a first option ?
My intention is to swap out tomorrow so I can see if the DLM is not going to take any action in the early hours.
I will post results.
Tony
-
Main indication of banding is that it's connected a few kb under one of the banded rates, 14,336k. Plus the attainable rate being significantly higher than the actual rate.
-
Thanks EJS. Most helpful and appreciated.
Tony
-
Main indication of banding is that it's connected a few kb under one of the banded rates, 14,336k. Plus the attainable rate being significantly higher than the actual rate.
ISP just confirmed that your right I'm banded.
6th engineer coming Friday, but will still swap out Modem tomorrow as I planned.
-
OK
Swapped out Modem at around 1130. Uploaded stats to my web site. You will see the missing tones are exactly the same. (Actually a partial one extra on the B1312-B10A router around 155). The SNRM slightly higher DS on the Zxyel, but sync speed identical.
As there is no change I've swapped back to my HG612. The stats showing now at www.west-lodge.com/adsl/index.htm are using the Zxyel and the snapshot at 1800 yesterday showing the HG612
So BTOR visit booked for Friday, not sure what they will find, but I'm now confident nothing untoward with my router.
Any comments most welcome.
Tony
-
But now on your Hlog there are no missing tones.
-
But the bit loading still has all the missing tones. I thought that was of the More concern ?
Please put me right if I’ve been looking at the wrong plots ?
The extra tone with 2 bits is likly the pilot tone ? Seen on the Zxyel modem not on the HG612
-
I don't think testing a different modem for a couple of hours is sufficient for dealing with a stability problem. It's not enough time to assess stability.
The 2 bit pilot tone has been on all the bitloading plots. I think the missing tones are unrelated to any line stability problem.
-
The connection is stable, its the banding which is the issue, which you kindly pointed out. I was trying to ascertain if a different modem will fill in the missing tones,
The only drops since the DLM banded me have been ISP running line tests.
-
Would the banding have been a problem if I had not mentioned it?
-
Yes because the speed I'm getting on this circuit is below what I always had following a line card fault, and what the ISP tells me the sync speed should be.
The ISP kept resetting the target SNR and the DLM intervened, despite the ES/SES being well below the assumed figure for DLM action.
You helpfully pointed out it was banding not target SNR.
I'm really sorry but I don't understand your post ?
Tony
-
But the bit loading still has all the missing tones. I thought that was of the More concern ?
Please put me right if I’ve been looking at the wrong plots ?
You've been looking at the wrong plots. It is a curiosity that earlier you had missing tones also on Hlog. Now Hlog is correct.
The extra tone with 2 bits is likly the pilot tone ?
Yes. It is.
-
Thanks. So the gaps in the BPT graph are not of consequence as they are the same with both modems.
Sorry but I’m getting confused😰
-
Sorry. I made a typo. You've been looking at good plots. It is a curiosity that earlier you had missing tones also on Hlog. Now Hlog is correct.
-
I did not intend for the fact that it's banded to be taken as some reason that there must be something for an Openreach person to go and fix. There's nothing to guarantee that a line will never get worse than whatever it was in the past.
-
@EJS Thanks. So I think what your saying I should just cancel the visit, and live with the reduced rate. I am aware that things change, but I wasn’t expecting a phone fault to permantly reduce my bandwidth.
I was asking for help interpreting the stats actually to avoid the need for an engineer to visit. I was hoping to identify a problem perhaps with hardware or other local issue. I did not want to say this on the forum but my wife has to have daily radio therapy for cancer treatment for 6 weeks every day needing a 40 mile round trip. I didn’t want to have to send her in a taxi,so I could be here for a vist.
I wasn’t wanting to say that, I just wanted to try and resolve an issue with the minimum of inconvenience. I’m now no further on. I’m greatful for all the input.
I will just leave it to the SP to decide on the course of action
-
Sorry. I made a typo. You've been looking at good plots. It is a curiosity that earlier you had missing tones also on Hlog. Now Hlog is correct.
Thank you that’s what I saw. Unfortunately it doesn’t prove a faulty modem one way or the other I don’t think.
Thanks for taking the time to correct the typo. I make tons !
-
Would the banding have been a problem if I had not mentioned it?
I certainly would have spotted it & if I'd been around more over the past couple of days would have mentioned it. The OP asked for help with his line being unstable for a while and dropping below the MGAL.
The PN of late would hardly send out an engineer if they felt it wasn't warranted. In fact they had been offering to send one out for a while but due to the OP's personal circumstances it was difficult to arrange a date and time which is why he asked if we could spot anything obvious that he could perhaps rectify himself.
-
I have to say I'm a wee bit disappointed in the fact that how this has turned out. I was going to post myself the other night about harsh comments, but in the end I bit my tongue and decided it's about time I start taking a back seat as communication for me is difficult and some days I find it hard to get across the point I am trying to make. Part of it could be the pain meds I'm on and the other part FM. I shall be going AWOL within the next few days anyhow as I'm due an operation which will leave me a bit incapacitated for a wee while and its why I'm so busy this week as I try to do what I can before I go in hospital so I've not had much time to spend on the forum. I have tried speech to text but found it doesn't always work well on forums for the posts I tend to make.
That leads on to what happened last night, I was aware of g3uiss's situation which is why I was trying to help and see if I could see anything, or at least any pointers that could assist if he did have to call out an engineer.
The line is performing below the MGAL, it used to be fine until he had problems with water in the DP. Although I didn't know until very recently g3uiss is fairly local to me on a neighbouring exchange and I know there is no RF in this area. Bear in mind also that his VDSL line does not exhibit those same blank tones either. I still maintain I've not seen anything like that before in 15+ years of reading stats, so I feel it is right to point it out.
Whilst I agree it may be a red herring to the overall problem - something is causing those blank tones and its interesting that hlog with the Zyxel modem is fine as is QLN... so what later causes no bit load? Am I not supposed to comment on something abnormal?
The line is quite obviously banded, you also have to consider what caused DLM to take interest in the line so quickly after a line reset. There's several indicators that it was MBTR rather than MBTE.
- Err Secs within MBTE limit
- Why banded but not interleaved. WBC DLM should opt for INP (Interleaving) if it was through Error rates.
- The presence of LOS and quite a lot of LOFs.
Whilst I appreciate that LOFs may not always cause a full resync it marks a period of short period time when the line is unavailable. There's a subtle difference between resync and retrain. Just about every technical document I checked classed LOFs as critical requiring either resync or retain. Whilst I note what ejs said about "not a resync as we know it". I think that bearing in mind knowing that DLM was highly likely to be taking action through MBTR figures rather than MBTE.
OK so I sidetracked a wee bit with the mention of RDI's but TBH I still think it was a valid point to make. What if DLM is ignoring the RDI markers (which indicate that the LOF was caused by something other than and SEF causing the LOF). It ignores Dying Gasp messages and still counts LPRs as a retrain, so I feel I was quite justified to wonder if there was the possibility it could be doing similar with LOF's that strictly speacking should be ignored because they have an RDI marker. I still feel justified in bringing up the topic because it may well explain why several other lines in the past have attracted DLM intervention when the resync count wasn't quite reaching the full total. It is definitely something to ponder over so therefore I make no excuse for raising it.
I repeat no matter what technical journal you look at, they all class the following as not just error states, but critical and the causes for loss of sync
- LOF (There should be an RDI marker if not caused by SEF - ie DLM initiated type resync at DSLAM)
- LOL
- LOS
- LPR (This is usually EU disconect of modem - and we know for counts this and ignores the dying gasp signal)
Anyhow back to g3uiss's problem. I feel that he should go ahead with the OR visit. Something is constantly causing DLM to take an interest and further cripple his speeds. It doesnt do that for nothing and its why I said I was not too happy with the LOF count.
What is causing the LOF's is another matter. I find it curious the Zyxel marked those tones during the sync process and whilst its not what is causing DLM to freak out, it still leaves the possibility that there is something causing retrains. Thus I feel it would be beneficial to mention to the engineer that DLM probably banded the line due to MBTR (retrains) rather than MBTE (Errors).
Finally whilst the Zyxel wasn't on very long, it does look like the error rate was slightly less during that period. The SNRM is also higher which means he should get a better sync speed with it if wasnt for the fact the line wasn't banded. I feel it may be beneficial at some point to run the Zyxel for a longer period to get a better picture. However not now as an engineer is coming on Friday so let him see it in its current state with the HG612
I'm in no hurry to get the VMG1312 back. I currently have a VMG8324 on my line and when I get chance I have a VMG8924 to put on and VDSL for me is off the radar for a while. My own line has just dropped below MGAL, but atm I have other things on which mean that now is not best time for logging faults with PN if I'm not going to be here or in a position to be swapping out modems myself.
What may be beneficial that if after the Openreach visit, the VMG1312-B10D does perform better on your line purchase of a B10A variant may well eke out more from your connection.
OK I'm done - hitting send typo's and all.
-
Whilst I appreciate that LOFs may not always cause a full resync it marks a period of short period time when the line is unavailable. There's a subtle difference between resync and retrain. Just about every technical document I checked classed LOFs as critical requiring either resync or retain. Whilst I note what ejs said about "not a resync as we know it". I think that bearing in mind knowing that DLM was highly likely to be taking action through MBTR figures rather than MBTE.
But always if there is one LOS there are 7 or 9 LOFs.
-
Greatful for all that info. I will post back following the visit, (and when the line is unbranded and stable try the Zyxel, and source one you recommend).
As expected since banding the line has been stable but well below MGALS.
-
But always if there is one LOS there are 7 or 9 LOFs.
I saw you mention that the other day and wondered where that had come from. Is there anything definitive about that or is it an observation. Years ago I saw someone mention 1 = 4... and quite often 1 =7 does crop up, yet there are examples out there that show otherwise.
LOS: 16 0
LOF: 25 0
LOS: 4 0
LOF: 8 0
LOS: 4 0
LOF: 7 0
LOS: 7 0
LOF: 12 0
LOM: 26 0
I'm well aware that LOFs may not always cause a full resync if the line recovers during the integration process, but something is causing DLM to take note of g3uiss's line and the pointers are its MTBR rather than err secs because of capping yet no interleave.
There wasn't anything I could find which says there is a ratio.. just "Prolonged LOS => LOF, but not always LOF => LOS"
and
7.1.1.1.1 Loss of signal (LOS) failure
An LOS failure is declared after 2.5 ± 0.5 s of contiguous LOS defect, or, if LOS defect is present
when the criteria for LOF failure declaration have been met (see LOF definition below). An LOS
failure is cleared after 10 ± 0.5 s of no LOS defect.
7.1.1.1.2 Loss of frame (LOF) failure
An LOF failure is declared after 2.5 ± 0.5 s of contiguous SEF defect, except when an LOS defect or
failure is present (see LOS definition above). An LOF failure is cleared when LOS failure is
declared, or after 10 ± 0.5 s of no SEF defect.
One thing we may see if LOS if a LOF RDI has been declared (no SEF defect). Example of an RDI commonly used by Openreach/BTw is DLM causing the line to retrain, which is when we may see 1=7 quite often?
The ratio thing isn't something I had looked into before, and I acknowledge you are very good at spotting patterns. Could the 1=7 be as a result of the DSLAM bringing the line down without SEF defects being present? I honestly don't know, but I am now signing off.
-
Is there anything definitive about that or is it an observation
This is my observation on Netgear DGND3700v2 when I have resync done ISP or resync caused by SHINE.
-
This is my observation on Netgear DGND3700v2 when I have resync done ISP or resync caused by SHINE.
Ahh thank you. ISP forced resync would fit with the 1=7 for RDIs. Not something I'd taken note of with for SHINE though.
-
Ahh thank you. ISP forced resync would fit with the 1=7 for RDIs. Not something I'd taken note of with for SHINE though.
When I have over 10 SES (more than 20 CRC errors per second) DSLAM force resync and I have 7 or 9 LOF and LOS.
-
Whilst I agree it may be a red herring to the overall problem - something is causing those blank tones and its interesting that hlog with the Zyxel modem is fine as is QLN... so what later causes no bit load? Am I not supposed to comment on something abnormal?
If QLN and Hlog is normal it is almost certain that it is some curious DSLAM setting.
-
I see similar problem.
https://forum.kitz.co.uk/index.php?topic=12540.0
-
Excellent find. :thumbs: Thank you I'd completely forgotten that long ago thread and as it just numbered some tones rather than a graph it didn't stick in my head.
other forum list
110
127
156
188
191
243
291
The other thing is that not all BTw lines get it or I'm absolutely certain I would have seen it on a graph long before now. In fact 2 years ago I put DSLstats on an adsl2+ line in this area for someone who was having line problems (turned out to be a HR fault cleared by new drop-wire) and that did not have the missing gaps. I did not take note of which type of MSAN he was on though.
From the other thread the reason was never found, although I note mention of IFTN. g3uiss is on IFTN:0x71c8 which I believe is Huawei MSAN.
-
Well done konrado ...... great bit of detective work, and I do believe an answer to the question.
I'm wondering if it may be wise for g3uiss to cancel the engineering visit IF obviously nothing can be done about this ?? He may attract potential charges for the visit ?? Just saying. :)
-
Great find but struggling to see what tone blackout has to do with the actual problem?
Errors. Lots of them!
Agree with BS, though. This has got charges written all over it :P
-
Thanks for the additional comments. The SP doesn’t know about the tones, and has arranged the visit on the basis the sync rate is well below MGAL. Oddly they haven’t given me the cost warning because they say the line is NOT performing as expected.
So on that basis I’m risking it. I’ve made a major commitment to be available so it’s worth a shot.
@boost I’m still unsure what errors you refer to. ES/SES are not breaking the MTBE although because of all the line tests earlier there were lots at resync training which @Kitz discussed.
I’ve just uploaded the stats again so they are more current and there have been no re syncs since modem swapped back.
@kitz recommended to definitely proceed with the visit.
The money isn’t the big issue here regretfully I had to post my personal circumstances and in that picture £100 isn’t significant if it happens.
Still interested in what errors @boost refers to as again @kitz suggested it wasn’t errors but retains that may have caused the banding.
-
Well done konrado ...... great bit of detective work, and I do believe an answer to the question.
I'm wondering if it may be wise for g3uiss to cancel the engineering visit IF obviously nothing can be done about this ?? He may attract potential charges for the visit ?? Just saying. :)
You have a PM
-
You have a PM
You have one back, sir. :)
-
So engineer arrived been here at least 3 times before when I had the line fault water in the DP in April. Did his test, he said all were OK and passed. I didn't get much detail, but 1 ohm difference in legs and a noise test was quoted at 59db.
One really useful bit of information he showed me on his phone, a graph of my connection going back months. He observed (as I have) the line has synced constantly at least since April 30th at 16mps without a drop and only since the line card swap had it become erratic and banded. He suggested there was little he could do at the property, but after a phone call to someone ? He went to the exchange to change the card and filter ? again. The phone was off for 10-15 minutes so I suspect this happened then. He also reset the line and now syncing at 15980. The graphs are all over the place following ISP tests again just before he came.
I've uploaded current stats - tomorrow I will see what the DLM does, if it bands me again, I suspect I will give up. ;D
Hope this makes sense to those that have been so helpful
Tony
-
It should be possible for your ISP to disable the DLM, or set custom thresholds to achieve the same result.
-
Your report on today's events makes sense. That the technician went to the exchange and made adjustments there reads as promising. I've taken a look at your uploaded data and it looks reasonable, to me.
There is just one thing I'll mention . . . and it concerns the configuration of DSLstats. You need to go to the Bit Loading, Hlog & QLN screens and left-click on the "Change tone range" button. In the Pop-Up that then appears, left-click on "Custom" and then adjust the slider so that the plot is just sufficiently wide to show the 512 sub-carriers of a G.992.5 circuit. At present, they are all set far too wide and show sub-carrier numbers that are not relevant to ADSL2+. ;)
-
Thanks for those comments. Iv'e changed the graphs, to try and just include the 512 tones, but It was either too wide, or as it is now. Hopefully this setting is better, also uploaded again.
Tomorrow will be judgement day, if DLM intervenes :)
Thanks for the suggestion also @ELS
-
I was convinced it was interference from your FTTC modem but I suppose it could have been further upstream?
Where, in theory, could the bare/patched terminals be closest before the house?
Anyway, glad you've got it sorted. I feel out of touch with ADSL these days. The joys of a single, flawless, FTTC line!
Well done for persevering :)
-
I was convinced it was interference from your FTTC modem but I suppose it could have been further upstream?
Where, in theory, could the bare/patched terminals be closest before the house?
Anyway, glad you've got it sorted. I feel out of touch with ADSL these days. The joys of a single, flawless, FTTC line!
Well done for persevering :)
Not sure it’s sorted until tomorrow to see if the DLM attacks me. However I’ve since last response received message fro ISP “engineer found exchange fault and has rectified”
Only time will tell 😄
-
Iv'e changed the graphs, to try and just include the 512 tones, but It was either too wide, or as it is now. Hopefully this setting is better, also uploaded again.
Yes, that's better. :)
However there is something odd with the Bit Loading per Sub-Carrier plot. It is missing the first 63 sub-carriers, those numbered from 0 to 62. I don't know why . . . and I don't know what to suggest.
-
Yes, that's better. :)
However there is something odd with the Bit Loading per Sub-Carrier plot. It is missing the first 63 sub-carriers, those numbered from 0 to 62. I don't know why . . . and I don't know what to suggest.
In addition to the missing tones that have no bit loading. I think its a mystery that wont be solved. I did try another modem today (HG6123B) the plots were the same.
-
DLM acted at 05:30, put me on 9.1 SNR and consequently speed reduced to 14015
Back to the drawing board ;D
However @kitz suggested DLM was acting on retrains. I guess with the line tests, by ISP, and disconnections but the engineer both here and at the exchange I could have had more than 10.
-
Well
I received some great advice after my last post, to be pragmatic about this and perhaps settling for the slightly now constant speed was the best course. I couldn’t argue with myself as I preach that exact principle in my own role. So it was for a few days stable at the reduced speed.
Then I lost dial tone 😰. When that was fixed at the exchange, my upload sync fell to 444mps with an SNR of 28. Also a further reduction in DS. I’m told that can’t be fixed until Wednesday next as the “order” is “stuck”.
So pragmatism might not always be the best course of action 😠
Nothing I can do, or the kind contributors to this thread can, but I thought an update useful.
-
Interesting developments. Hopefully you will be able to make a more positive post after Wednesday. :-\
-
And Wednesday came and there was no change. I’m sure there is a biblical reference here :)
Not sure when I should throw my toys out of my nice shady pram 😋
-
And Wednesday came and there was no change.
<Sigh!> >:(
-
In addition to the missing tones that have no bit loading. I think its a mystery that wont be solved. I did try another modem today (HG6123B) the plots were the same.
Well work is still on going, seems to have been escalated to BT wholesale as the DLM is causing some of the problems. However the bit loading on the low tones has now appeared !
Current stats www.west-Lodge.com/adsl/index.htm
-
. . . the bit loading on the low tones has now appeared !
So they have. How peculiar. :o
-
Well. I’m told all the issues have been resolved. At this time the speed and thruput is excellent. The stats look much better than they have although still some missing tones, but perhaps not as many.
I don’t know everything that’s been done, but I do know BT wholesale have been involved.
So time will tell.
Uploaded current stats to the normal web address
-
Uploaded current stats to the normal web address
Things certainly look better after about 1525 hours.
-
Things certainly look better after about 1525 hours.
Yes that was the reported fix time.
:)
-
This? "Ecclesiastes 1:9 King James Version (KJV)
9 The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun." :D
-
:) :) :)