Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: les-70 on May 10, 2014, 05:05:04 PM
-
Had a gigantic burst of errors last night. 13000 crc in minute. Today I notice that I am capped and interleaved. Seems fair enough but the DLM might have been kind enough to wait to see if it happened again. What puzzles me are the stats and bit loading. The snr downstream is only 6.4. With the attainable at 81864 I would have expected a value about 3db higher. e,g 9-10. Is this a strange or normal?
Below are the bit loadings and day or so before with a 64Mb/s self cap and those now with the DLM imposed cap of 68Mb/s The bit loadings with the DLM 68mb/s cap look rather like an 80mb/s sync bit loadings. Again is this normal or odd? The value of snr (6.4) suggests a 80Mb/s sync? it certainly is all odd to me ??? .
new stats are
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 21604 Kbps, Downstream rate = 81864 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68901 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.4 6.0
Attn(dB): 17.4 0.0
Pwr(dBm): 13.2 6.8
the bit loadins are:
-
As an interim answer to myself -- I think I need to do some reading on interleaving and INP. I am afraid that having never having been interleaved before I not taken too much notice of that subject.
-
Had a gigantic burst of errors last night. 13000 crc in minute. Today I notice that I am capped and interleaved. Seems fair enough but the DLM might have been kind enough to wait to see if it happened again.
:( Seems a bit harsh if it was a one off.
The timing of you putting the new router though wasnt good either. BToR in its infinite wisdom counts all resyncs as bad regardless or not if they were intended. I wish they would make use of the dying gasp.. its documented that they dont and no allowance is made for if the resync was due to the EU or due to LoS :(
With the attainable at 81864 I would have expected a value about 3db higher.
hmmmm how strange - I agree. Normally the additional SNR over the target margin is used to calculate the max.
Im as puzzled as you are. The only other possible place where that additional reserve could be hiding is overheads for interleaving.
----
Warning - while you were reading a new reply has been posted. You may wish to review your post.
- I see you have now also mentioned interleaving yourself, but I'll leave my post above as was.
-
I wish they would make use of the dying gasp.. its documented that they dont <snip>
Do you have a link or other details for that document, please? :)
-
eke... I will try find it for you. iirc its buried somewhere in one of BTs patent documents and not on their site.
It was discovered when we were talking about the differences between the BToR and BTw DLM. I think it may have been 7LM that found it originally.
-
ok I think this is the one. It took me ages to find it, as I kept finding the earlier BTw one first.
Im now running really quite late and I dont have time to double check and read through.. but I think this is the info you need.
https://www.google.com/patents/US20130201836?dq=ininventor:%22Christopher+Marcus+Croot%22&hl=en&sa=X&ei=BmcuUpjaDIOGhQeX24HABw&ved=0CDoQ6AEwATgK
for the most aggressive stability level the DLM function attempts to keep sync losses to below 12 per 24-hour period (including switching off modems/routers which count as a sync loss) and to keep the line error-free for 98.3% (59/60 seconds) of active uptime measured over a 24-hour period;
for the normal stability level the DLM function attempts to keep sync losses to below 6 per 24-hour period and to keep the line error-free for 99.8% (599/600 seconds) of active uptime measured over a 24-hour period;
and for the stable stability level the DLM function attempts to keep sync losses to below 3 per 24-hour period and to keep the line error-free more than 99.98% (5999/6000 seconds) of active uptime measured over a 24-hour period.
---
Added link
-
Thank you. :) That url (https://www.google.com/patents/US20130201836) allowed me to download a copy of the original document as a PDF file. On attempting to read it my eyes went out of focus and a cat-nap prevailed!
To be honest, I do not see any mention that a modem's "dying gasp" is ignored. Turning off the CPE obviously results in a loss of synchronisation with the DSLAM/MSAN and I cannot see any reason why that event should not be counted.
I seem to recall some experiments that asbokid performed --
- Severing the link between the CPE and DSLAM (as might be caused by "Sean O'Hoolihan" and his mechanical excavator) results in a loss of synchronisation event being recorded and the error second counter continuing to increment (along with all the other relevant error counters).
- Powering down the CPE (which sends a "dying gasp") results in a loss of synchronisation event only being recorded. The error second counter, etc, is not incremented.
Section 0105 reads, in full --
[0105] In an alternative embodiment, the stability levels could operate such that for the most aggressive stability level the DLM function attempts to keep sync losses to below 12 per 24-hour period (including switching off modems/routers which count as a sync loss) and to keep the line error-free for 98.3% (59/60 seconds) of active uptime measured over a 24-hour period; for the normal stability level the DLM function attempts to keep sync losses to below 6 per 24-hour period and to keep the line error-free for 99.8% (599/600 seconds) of active uptime measured over a 24-hour period; and for the stable stability level the DLM function attempts to keep sync losses to below 3 per 24-hour period and to keep the line error-free more than 99.98% (5999/6000 seconds) of active uptime measured over a 24-hour period.
In other words, it sets out what could happen in an alternative embodiment . . .
Finally I not convinced that patent describes the DLM process as used by Openreach for its GEA-FTTC VDSL2 links.
-
I was trying to avoid the DLM by capping my speed. The error burst came while the ZyXel VMG8324-B10A was connected with an uncapped sync close to 80Mb/s. I have gone back to the HG612 for the moment to avoid too many variables at once.
I am now back to capping my speed at 64mb/s so as to ensure immunity from the big attainable drops on my line when others power up their modems. Currently this is giving me a 7.8db SNR downstream, if it goes back to fast path it will about 11db SNR. I hope this is the best thing to do as I don't like any unexpected losses of sync and I wonder just what response the DLM would have in mind if left to its own devices in the face of the 6db drops in SNR that my line gets.
-
Well after 48 hours of use I must say that as the 15ms addition to pings does not seem noticeable for my use the interleaving seems to make better use of the the bits per tone than a speed reduction on fast path.
i.e if I were to cap to speeds to 69Mb/s on fast path I would expect a SNRM of about 8.5 and about 10ES per hour and roughly twice as many crc. With the interleaving the sync is 69Mb/s and SNRM is 6.2 but there has been a permanent zero ES. I am more sympathetic to its use even if I think it imposed prematurely.
-
I think any High CRC or FEC bursts of errors in the of space of 15-30 minutes will be seen and be recorded by the DLM an then the DLM will act on line by whats called a retrain in the wee small hours, that could be 23.30 hours after the event had occured (bursts of errors), the next stage is harder to predict but it does seem upto 14 days is the minium :(
-
It was discovered when we were talking about the differences between the BToR and BTw DLM. I think it may have been 7LM that found it originally.
Sorry, just noticed this. I certainly did post links to a couple of BT DLM patents in the dim & distant past.
I also vaguely recall a few discussions in which I participated, and that surmised BT's DLM probably ignored dying gasps, but I'm afraid I don't remember any hard evidence... Possible of course that I have just forgotten. ???
-
Cant respond to this properly atm since I have a king size bed on its side obstructing my way to certain rooms and its manic this week trying to finish everything before the carpet fitters arrive on Fri... so I really cant go searching for docs and linking to them. I was pushed for time on sat to find the one I did and perhaps it was the wrong one - they take a heck of a lot of reading through and there are several that are similar at first glance.
But I do know for sure that 7LM found one of the patents, then I later found another one that without doubt mentioned FTTC and how the DLM worked with the what they called the minidslams in the cabs and hooked up to the legacy data collectors for RAMBO and the DLM system. (there was a diagram showing the dslams in the cabs) There were some algorithms that mentioned MTBE and MTBR both of these were confirmed to be in use by Plusnet last year as part of how the existing DLM worked.
Whilst I am fully aware of the dying gasp which Ive have been preaching about it since about 2005/2006 when I first did the DLM stuff. If you search back in history to 2006, there will be many a post by me telling people how to power down to trigger a dying gasp. I also have no absolutely no doubt that the Huawei DSLAMs may be able to recognise the dying gasp messages. The question here though is that the BTw DLM system doesnt now seem to be using this method.
However I do seem to recall reading that the very first methods of detecting EU power downs - v - instability retrains proved unsatisfactory for various reasons and there was even discussion at one point about using power states (ie detecting when a router goes into low power mode).. however, BT in its infinite wisdom decided to come up with their own version of DLM using the 15 mins blocks to detect user inactivity and also factor errors into the DLM MTBE algorithms (something which the earlier system didnt do either).
Although the FTTC DLM may factor different methods of application for when a line is classified as instable to the WBC DLM. The BTw DLM does allow for this and you can set different profiles.. From observations and discussions in another thread on here, it was deemed that the BToR DLM preferred banding over SNRm configurations and iirc, then one of the documents did mention that these sort of configurations were allowed.
There is mention in one of the BT SINs (again cant recall which one) saying that an ISP can specify their own parameters if they so wished... now Im guessing at this, but I'd say BToR have probably taken this option and set their own profiles by using the 'SP specific custom option'. More musing but if they have taken this option then it could be the reason why ISPs themselves have a hard time trying to get any profile changes reset themselves and why its such a performance to get BT to make any changes with the FTTC profiles.
-
The DLM has been responsive. On day 4 upstream interleaving was removed and now on day 5, I am fully back on fast path. I guess there is some luck in all this unless unless the DLM has a memory that is saying that the connection was not bad apart from one bad day. Some angle-grinder activity by a neighbor is the suspect cause of the bad day.
-
Does anyone understand why there seems to be a difference between the max attainable values on fast path and interleaved (INP=3.5).
On fast path I had an attainable ~78Mb/s and sync ~77Mb/s, with SNR 6.3. With the switch to interleaving it became an attainable of 83Mb/s and a sync of 69mb/s with SNR 6.4. The bit loading in the states looked pretty much the same showing the interleaving using more bit loading for the same about of speed. On returning to fast path the stats are now back to prior values.
I think I understand all the values except the significance, if any, of the change in attainable from 78 to 83. Maybe it is just a quirk of how the values are estimated in the two states?
-
The reason your sync speed was lower was due to FEC overheads, even with same bitloading.
-
I understand the respective values of the syncs. It is the change in the attainable values that puzzles me. The interleaved value was 5Mb/s higher.
-
its something that always seems to occur, interleaved lines report higher attainable, I have some theories but they only theories.
Also I have only observed this behaviour on BT owned equipment not sky/easynet/BE.
1 - Interleaved lines get favourable power masking as they seen as needing a "bit of help" to work well.
2 - The modem miscalculates attainable rates.
3 - The interleaving technology actually gives superior snr. (this I observed when I used to use DMT on BT adsl max), I was watching my line one night when it was scheduled to go back to fast path, I watched it go offline for a couple of seconds, and then come back, the snr per tone was a few db lower across the entire range when it came back on fast path. this could be due to #1 tho. This observation I had in DMT makes #2 less likely.
-
I think I understand all the values except the significance, if any, of the change in attainable from 78 to 83. Maybe it is just a quirk of how the values are estimated in the two states?
I don't profess to understand why, but we always see such a difference whenever interleaving is applied.
It would appear to be physically impossible to ever achieve the higher speeds.
The only exception to this rule is when a connection resyncs at a particularly quiet period, when sync speed gets 'close' to attainable rate.
On those occasions, we often see sync speed maintained, but attainable rate becoming lower than sync speed when noise increases i.e. when SNRM reduces, currently below 6 dB in the case of VDSL2 connections.
Here's a recent example from my connection:-
Max: Upstream rate = 4027 Kbps, Downstream rate = 21148 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps
DLM clearly didn't like that after approximately 24 days as the connection resynced & ended up like this:-
Max: Upstream rate = 4216 Kbps, Downstream rate = 21268 Kbps
Bearer: 0, Upstream rate = 4245 Kbps, Downstream rate = 18858 Kbps
-
I think the best time to resync the Hg612 would be when Max Attainable is at it's lowest value, this will give you a higher SNRM to overcome any evening noise though your Bearer will Sync lower thats the trade off.
But the DLM keeps butting it nose in and then retraining at silly times like 2am 4am or 7am when the lines are quiet so by the evening SNRM will start to drop and hay ho the errors start accumulating ::)