Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ixel]

No hes not. 

The default profile setting for DLM is 'standard'. 
Theres only been Zen and Plusnet who've come out and said they provision on Speed, although I suspect AAISP will also likely be using 'Speed'.

If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed.   I pity any poor person with TalkTalkTV provisioned on Stable, as that will be a complete nightmare to get any changes removed - 2 Errored seconds per day and youve blown your chances.   

Someone needs to find out what BTr provision at, but finding out that info could be hard, as I bet most of the reps wouldnt have a clue what you are talking about

It did feel as if I was DLM'd to interleaving faster when I was with BT Business (until the time I capped my connection 60Mbps downstream which brought it back to fastpath). With Zen it so far has been speed banding followed by interleaving, rather than interleaving being done first - interestingly.

[NewtronStar]

Poor old STARMAN line has become interleaved 

[kitz]

Looks like its been switched back on.  I notice someone else on the forum said theyd been DLM'd yesterday too.

[marjohn56]

This is 100% definite.
Typical that the info comes a bit too late   but here are some of the answers anyhow for the FTTC DLM.

The BToR DLM measures the following parameters:

Total 24hr SES (downstream)
Total 24hr ES (downstream)
Total 24hr SES (upstream)
Total 24hr ES (upstream)
Total 24hr uptime
Total 24hr unforced retrain count
Total 24hr Full Initialisations
Total 24hr failed initialisations
Line rate (downstream) in previous 24hr period
Minimum line rate (downstream) in previous 24hr period
Maximum line rate (downstream)  in previous 24hr period
Line rate (upstream) in previous 24hr period
Minimum line rate (upstream) in previous 24hr period
Maximum line rate (upstream)  in previous 24hr period

The days monitoring file covers the period 00:00 to 23:59:59

Definitely no FECs

Interesting... only my first or second post here, wish I had more time.

An interesting thing has happened to my VDSL. Some weeks ago, lets say the end of October I purchased a Draytek DSL Router to replace my OR/Sky router/Asus router combination. At that point, my sync was sitting at 61/20 and had been for as long as I'd been on the 80/20 profile. Because the Draytek decides that everytime you make a change to a setting it wants to reboot I was hammered by the DLM, there were also stability issues with the Draytek ( now sorted ) which added to the probem. Leaving it for a week saw no improvement so I put back the OR modem and after a few days there was still no change. Sky mamanged to get the DLM reset somehow, engineer call out to the cab I suspect, however, service was restored and I was back at 61/20. Being an optimist and with new firmware in the Draytek I reconnected it. This time it sat at 61/20 but over a few days fell to 51/20, then fell to 39/10!

Called Sky again, this time an OR engineer came to the house, I now having replaced the Draytek with the OR modem/Sky Router/Asus combo. Fair play to the guy, he was very thorough, popped his meter on there ( nice piece of kit! ) and said there were far too many errors and found a problem with the connections in the back box, not common but known about, replaced the back box and error count on his meter fell drastically. Connected the OR back up 68/20 and all working. Overnight the sync dropped back to its 61/20 as interleave was applied and I was back to my old rates; this was the Wednesday morning.

On the Frday evening, forever the optimist I reconnected the Draytek, determined I would get this thing to work. Synced at 61/20 and stayed there until the following Tuesday. On that morning I went out and bought an Asus DSL-AC68, No!!! I hear you say, well whatever, connected it up and it locked at 68/20, well I thought that's nice. At the time I was running at TBB Ping test and refering back to it I noticed that at 8:30 that morning there had been a momentary interuption and the latency had more than halved, so the sudden increase had occurred before the Asus was installed. The Asus as we now know was very unstable and must have re-synced several times it did not however trigger a DLM response. I ran the Asus intermittently over the next week testing new firmware versions but was never happy at the amount of errors I was seeing.

At this point let me say that the Asus has since left the premises and returned from whence it came ( PC World ). Since that day, I have had the Draytek running now for about 3 weeks, stable no re-syncs unless I cause it but I have on occassion forced a re-train or reboot with new firmware, something that prior to that one morning at 8:30 would have caused a DLM response.

I can sync quite happily at 68/20 but I see about 2400 FEC a day and maybe 180 ES so I have increased my SNR to 8db to reduce this, there are always zero SES and zero HEC.

I have lsearched and tried to see what is a normal range for these errors, as there will be errors but cannot find any definative values, it also appears that on the Tuesday I was put back on an open profile and the DLM has not interfered since, strange, any thoughts?

[Ixel]

So far my initial thoughts are that the ASUS seems to handle interleaved connections better than the HG612 (only thing I can safely compare it with), though this is just comparing ES/SES/CRC values and not the FEC value. The FEC on the ASUS for the downstream does eventually go wild - though the connection remains fine still. On the HG612 I would still get some CRC errors/ES but with the exact same interleaved connection I would get little to no CRC errors/ES on the ASUS. The ASUS on the other hand seems to handle fastpath extremely unreliably, which I'm hoping will eventually be improved to a point where it's usable or better in comparison on fastpath.

[marjohn56]

I have since I posted this found a link that does give some detail on thresholds. If its true then I can afford to reduce my SNR back to 6db and still be in the safe zone.

I'm pretty sure that this has been seen before on this site, but here's a link anyway.

http://community.plus.net/library/broadband/broadband-faults-guide-our-testing/

Ixel, I would really have liked to have been successful with the Asus, and I may, if they sort it out, go and buy one again. However, I cannot afford to have it randomly resetting as both myself and SWMBO work from home and we use VC a lot.

I'll not mention said modem again as it's off topic for this thread.

[Ixel]

Fair enough, just sharing my thoughts as you asked .

[kitz]

Yep my heart sunk for you when I saw mention of the DSL-AC68, although I do believe they are slowly getting there and at least PC World took it back.

>> so I have increased my SNR to 8db to reduce this,

Interesting, does this lower the sync speed?  because all attempts with other routers the DSLAM over-rides it  and still sets it at 6dB.  With the BCM routers weve found that it is possible to increase the SNRm, but only by capping the maximum sync speed.

>> replace my OR/Sky router/Asus

Out of interest which OR modem did you get.  If its a HG612 it may be worthwhile having a go at unlocking it.

>> I have lsearched and tried to see what is a normal range for these errors, as there will be errors but cannot find any definative values

Ive seen a few sets, but Im not sure if any of them are correct.  The only ones we know for sure are the latest 21CN ones and its pretty apparent that the fttc parameters dont appear to have changed at the same time the 21CN ones did.
30/300 seems to be about the nearest figures to what we see.   But you also have to bear in mind we dont know which ISPs are provisioning on what stability level.   Theres only Zen and Plusnet who so far have come out and said 'Speed'.


>>  I would really have liked to have been successful with the Asus, and I may, if they sort it out, go and buy one again. However, I cannot afford to have it randomly resetting as both myself and SWMBO work from home and we use VC a lot

If you are looking for the best stability with the highest bit rates,  then IMHO its got to be either a Billion, the HG612 or a Zyxel.

[marjohn56]

Raising the snr by 2db drops me from 69 to around 63, lowering it by 2db will take my sync rate up to 73+, of course if I do that the I see a proportional increase in errors.

My HG612 is as originally supplied when I went fttc, and I have unlocked it.

from what I have read it seems there are three profiles, speed, stable and super stable; my impression is that my (Sky) profile was set to super stable and is now on speed, that's the only way I can explain what has happened to my line.

The Draytek is solid now on the beta firmware I am running, so I have no worries with that, I am more interested in seeing how far I can raise the error rates without incurring the wrath of the DLM.

[marjohn56]

I thought it might be useful to post my Draytek stats at 8db SNR. Link up time is now at something like 23hrs 30 minutes. I'll reset the snr to 6db after I post this message and post the stats again after about 24 hours at that SNR.



Hmmm... OK, could be 7db then, whatever.. resetting to 6db now.

[kitz]

Notes for me and others

Currently reading the court case link

Section 235 - 238  lists some interesting info

Priority between interleaving and cap level
In some circumstances the ILQ indicates that green logic should be run. The green logic has a number of steps. The first important decision step in the downstream logic (step B) is an operation which provides a YES or NO answer. If the answer is YES the logic branches one way whereas if the answer is NO the logic branches another way. The YES branch may reduce the interleaving level while the NO branch may increase the cap level. In fact the NO branch includes some further questions (Step C and within step G) which might send the flow back to the interleaving branch but that is a detail and makes no difference to this analysis.

Importantly on the YES branch, the interleaving level may either be reduced by one or left as it is but whether the interleaving changes level or not, there cannot be a change to the cap level. On the other hand on the NO branch (subject to steps C and G) the cap level may be increased (or left alone) but if the cap level is to be increased, the interleaving level cannot be altered. So the green logic can lead to three possible outcomes overall: no change, reduce interleaving or increase cap level. These are the only possibilities. The logic cannot change both the interleaving and the cap level at the same time. The decision whether to actually change interleaving or cap level depends on line conditions.

A key part of the claimant's infringement case here involved arguing that this logic showed that the system gave a higher priority to increasing cap level over reducing interleaving. The defendant did not agree. One aspect of the claimant's argument and Prof McLaughlin's evidence was based on the defendant's marketing materials but I reject that. The priorities, if they exist, must be derived from the logic of the method used and not from assessments about the subjective views of the operator. Considering the logic itself, I fail to see how it is possible to state meaningfully that this green logic gives a higher priority to increases in cap level over interleaving. The logic simply chooses which branch to take in certain circumstances. The choice depends on line conditions. In this logic there is no priority between interleaving and cap rates.

Accordingly for these two distinct reasons, I reject the claimant's case that the NGA logic as a whole, or the entire green logic as a part of it, infringes the claims.

Since this has been rules as non-infringing then its likely that at least this part of the ILQ will stay?

We already know that the DLM classifies Red and Crimson  Red being from MTBR and Crimson from MTBE.   We also know that DLM only reduces profiles if the ILQ is green.  Therefore info contained in the above para would perhaps seem to indicate that which step if the ILQ deems your line as could depend on whether you were DLM'd for either MTBE or MTBR.

Need to try and do some more digging in this area..

[kitz]

Woooooo  lookie what I just found whilst searching on info from the above para -  a patent US 8582460 B2 dated 2009 specifically devoted to the ILQ 

kitzy has lots more reading to do...  and try figure out how it slots in with what info is already available.... and then  if/how the patent would be applied to fttc.

Although the invention talks about changing SNRm, there are a couple of tables in there   [table 3 & Table 4 ] that specify capped profiles.

Theres a bit of interesting information in there too about monitoring the SNRm.   We already know that RAMBO can and does do this already when checking whether to apply a capped rate profile for poorly performing lines.   It looks like this same function could also/is being used to monitor the line's SNRm for 'x' days before deciding whether to remove interleaving/caps.

Too soon to say anything definite until Ive digested it all and worked out how it fits in with existing BT DLM info..  but I thought some of you guys may also find this interesting.   Im saving that patent to read later because Im still trying to work my way through the court case to see if any other gems of info come out of it which may aid further understanding.

[marjohn56]

Just to confirm the Draytek does alter sync rate when changing the SNR, last night I posted the stats for approx 24 hours at 8db,  it WAS 8db even though it said 7.

Below are the stats for 25 hours at 6db ( default ). Now, a question for all those who have more knowledge than I do, and that's most people, are the stats below likely to trigger a DLM response or am I safe to leave it?

[kitz]

Just to confirm the Draytek does alter sync rate when changing the SNR,

Thats very interesting. Thank you for confirming it.    Previously altering the target SNRm has been impossible.

Anyone on VDSL with a BCM based router want to try and see if it works on theirs too?   Is this something to do with the recent changes.

are the stats below likely to trigger a DLM response or am I safe to leave it?

Sorry its a bit impossible to say from one set of stats.  I cant tell how long a period the ESecs cover. 
232 E/S for a day is perfectly fine.   Your upstream looks more concerning though 

[NewtronStar]

If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed.

Kitz i do think it's going to take a miracle for interleaving to be removed, it's now 7days since capping the sync from 30000 kbps to 25000 kbps even with 100 downstream errored seconds over 24 hours and with my oscillating SNRm this is going to be hard to get interleaving removed