Print

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

[Chrysalis]

I did read the zen doc which shows there is more than just green and red status, there is some other colour codes as well, interestingly if a line exceeds the resync threshold DLM will always assume its a DS issue and will not take action on the US for resyncs.

I have been wondering now if its BTw policy to use the standard not speed profile on FTTC and isp's have just been assuming standard=speed but never had it verified?

[les-70]

 Back to the observations.  Here (I think) are all the connections on fast path exceeding 480/day at least once in the last 10 days, there are no higher fast path values per day. Below the number of errors per day is shown for each line.  I don't think Chrysalis should really be on the list as it looks like he had just one odd bad event.

 I believe that if I run my connection uncapped at full sync with the HG612 I will get about 500 and with the Billion about 750.  I would say that if you go over 1000 much you should expect the odd bad day to take you interleaved when you hit the standard level of 1440/day.

AnnM         944  F
Baldeagle   1100  F   
Crowroad    786   F
Nb99999    526  F
Nokiboi39  744  F
Chrysalis    554 only odd day F
Vdsl user    682 F

 I may do an analysis of those interleaved.  My impression, just looking as I went through all the lines, is that once interleaved you seem to need very very low error rates to recover and lower than the 144/day suggested in the Zen doc.  Interleaving may of course manage to achieve that.

[Chrysalis]

yesterday was a lot of rain, I seemed to have a larger amount of ES than normal, but who knows, as every afternoon I am getting bursts of CRC's which started about half a week or so after I had my new pair put in, which seems to coincide with the dentist across the road doing some major rebuilding work.

I think the 2880/day theory per day on speed is correct, so my theory is now that plusnet (who supply most members on this site) are not using the speed profile.

[tommy45]

I somewhat would agree with your theory, be it intentional or be down to BT wholesale who apparently they have to go via to action this sort of thing, currently my line is interleaved due to some random interference that caused a lot of errors and packet loss , over 14 days ago, i have swapped modems so i could get some idea as to why I'm not back on fast path again, over the past 2 days there have been 0 crc's and 0 error seconds generated on the DS DLM is a joke IMO

[Ixel]

I somewhat would agree with your theory, be it intentional or be down to BT wholesale who apparently they have to go via to action this sort of thing, currently my line is interleaved due to some random interference that caused a lot of errors and packet loss , over 14 days ago, i have swapped modems so i could get some idea as to why I'm not back on fast path again, over the past 2 days there have been 0 crc's and 0 error seconds generated on the DS DLM is a joke IMO

DLM is indeed a joke. I believe I'm now stuck on a banded profile again, although fastpath, 49/15. Been like this for quite a few days now, I was stuck on 60/20 for several months before it gave me 80/20 around the start of January this year. Maybe it'll recover again at the beginning of January? Definitely below the estimate either way.

[les-70]

 An analysis of the interleaved FTTC connections, 12 of them I think with 10 day stats, rather than the 22 with fast fast path is not encouraging! Noting the error rates of 1,2,3 hour as 24 48 and 72 per 24 hours  there are 5 interleaved lines with a  max value in the 10 days of more than 72/hour, 3 >48 but <72, 3 >24 but<48 and just one at 23.  The one at 23 garypower had a slight reduction in interleaving depth in the 10 days.  No one else had any change in interleaving. Morphium had 9 days with a max of 17/24hours but one day at 37.

  It looks like once your interleaved you may need to sustain less than 1ES/hour to recover to fast path!!!  .  Interleaving can give a big error rate reduction but 1/hour does not sound much to me.

  I suspect that the Zen doc. lower green band, which for standard would be 6/hour, might apply to a banded line but it looks quite unrealistic for those on interleaving.

[tommy45]

Where did zen get this info ? openreach or some other 3rd party or did they make it up?

[tbailey2]

Morphium had 9 days with a max of 17/24hours but one day at 37.

He's in Switzerland  8)

[Chrysalis]

An analysis of the interleaved FTTC connections, 12 of them I think with 10 day stats, rather than the 22 with fast fast path is not encouraging! Noting the error rates of 1,2,3 hour as 24 48 and 72 per 24 hours  there are 5 interleaved lines with a  max value in the 10 days of more than 72/hour, 3 >48 but <72, 3 >24 but<48 and just one at 23.  The one at 23 garypower had a slight reduction in interleaving depth in the 10 days.  No one else had any change in interleaving. Morphium had 9 days with a max of 17/24hours but one day at 37.

  It looks like once your interleaved you may need to sustain less than 1ES/hour to recover to fast path!!!  .  Interleaving can give a big error rate reduction but 1/hour does not sound much to me.

  I suspect that the Zen doc. lower green band, which for standard would be 6/hour, might apply to a banded line but it looks quite unrealistic for those on interleaving.

bear in mind every time I have been interleaved I have recovered.  My error rates whilst interleaved were something like 0-5 CRC/ES a day.  #It is understandable why the recovery target rates are so low, its to avoid lines flapping in between fast path and interleaving which is far from desirable.  They have to be reasonably sure that a line that recovers isnt going to keep flapping.

[les-70]

  One extra observation is that judging by the relation between attainables and actuals I think only ixel looks to be speed capped by the DLM.  I can't help wondering how the DLM might decide between interleaving and a speed cap. 

[Dray]

I bet it's based on resyncs.

[Chrysalis]

another thing that will band a connection is if it syncs too low then the banding gets reduced so the aim is for the sync to be close to middle of banding as possible.

[Ixel]

I bet it's based on resyncs.

That's also my theory. If the MTBR is exceeded then banding is most certainly used. If the MTBE is exceeded then most certainly INP and delay are used, but possibly banding as well depending on the severity. So far I'm not convinced the MK3 has managed to reduce the trickling CRC's I'm getting, but it's early days. I'm on the HG612 at the moment due to instability occuring yesterday on the ASUS (graphs on other thread), you may have already noticed my username on MyDSLWebStats.

[les-70]

  Ronski who has had interleaved ES/day rates between 22 and 84 went fast path today.  That suggest the value for a change is probably bigger than the 1/hour suggested above.  Maybe it really is 6/hour but with a history dependence that can mask seeing that as the actual value?

[Ixel]

I see. I suspect for a connection on the 'stable' OR DLM profile, that it is 6/hr (144/day) or less than that depending on the line history and perhaps the FEC (if the training doc is correct). I'm trying to keep my ES below 288, it's pretty bad that an ES is counted for just 1-2 CRC's as that's hardly unstable. I haven't been able to isolate the cause of this, just wish the ECI /r has reliable statistics. I'm not keen on capping the connection further than what DLM is currently capping it at (49/15) as it might well encourage DLM to set a lower banding, capping me further. My theory is that the banding won't lift unless my ES is below a certain amount.

I'm also studying the ASUS TC Console app at the moment, trying to get the statistics from that to work with my graphing app (as the TC Console reports error seconds).