Print

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

[roseway]

@les-70: You're quite right in every respect. I know FECs have been dismissed as playing any part in DLM, but it's hard to think of any other reason why my connection is still on the fairly high interleaving level.

[simoncraddock]

I've long suspected FEC is a DLM consideration.

During the time I was using the ASUS DSL-AC68 despite minimal CRC/ES/SES errors DLM would never adjust my profile upwards unless I stuck the Openreach Modem in-front of it or switched to a Broadcom device. This it would seem was because the ASUS was recording 100x more FEC errors than the Broadcom device.

I've since started using a Fritzbox 7490 which is a ECI chipset and my line is much quicker at reversing DLM actions, as was the case earlier this month when roadworks outside my home caused Interleaving to be applied for 72 hrs. Had the Asus still been in place I doubt I would even be on a Fastpath connection.

[Bald_Eagle1]

Apparently, the HG612 does (or did) consider US FEC as a reason for causing the connection to resync (Retrain Raeson 3).

This is from the HG612's SP10 driver code (I don't have a copy of the SP08 version):-

/*  line-drop reason code */
#define kRetrainReasonLosDetector                   0
#define kRetrainReasonRdiDetector                   1
#define kRetrainReasonNegativeMargin                2
#define kRetrainReasonTooManyUsFEC                  3
#define kRetrainReasonCReverb1Misdetection          4
#define kRetrainReasonTeqDsp                        5
#define kRetrainReasonAnsiTonePowerChange           6
#define kRetrainReasonIfftSizeChange                7
#define kRetrainReasonRackChange                    8
#define kRetrainReasonVendorIdSync                  9
#define kRetrainReasonTargetMarginSync             10
#define kRetrainReasonToneOrderingException        11
#define kRetrainReasonCommandHandler               12
#define kRetrainReasonDslStartPhysicalLayerCmd     13
#define kRetrainReasonUnknown                      14
#define kRetrainReasonG992Failure                  15
#define kRetrainReasonSes                          16
#define kRetrainReasonCoMinMargin                  17
#define kRetrainReasonANFPMaskSelect               18


I have quite recently seen evidence of fastpath connections resyncing where all DS error counts appeared to be quite low, yet US error counts were relatively high.

In some cases, quite high depths of US interleaving, INP & delay were applied & although DS remained on fastpath, with zero values for DS INP & delay, DS sync speeds were also reduced.

FWIW, tabiley2's connection recently resynced at lower speeds with Retrain Reason 6 (Retrain Reason Ansi Tone Power Change).

Do any of you know what that actually means?

[NewtronStar]

Have been waiting to see roseways DS stats change to non-interleaved for a few weeks now but nothing has changed, roseways DLM history looks clean to me and should have been put back on non-interleave by the fifth day after the DS issue.

Sure my line was always interleaved for years with consistent medium FEC errors and low errored seconds 200 per day did the DLM relent ? fecking no way 

[Chrysalis]

@les-70: You're quite right in every respect. I know FECs have been dismissed as playing any part in DLM, but it's hard to think of any other reason why my connection is still on the fairly high interleaving level.

which device are you currently using?

[roseway]

Billion 8800NL for the last 14 days.

[WWWombat]

Ooooh ... a whole thread on DLM that I must have missed while BT got around to sorting out my PCP record.
some interesting reading tomorrow...

[roseway]

It looks as though I was a little premature in what I said about FECs. At 02:43 today, DLM put me back on fastpath and I'm back up to near maximum downstream speed. G.INP isn't enabled. It took over three weeks but it got there in the end.

[les-70]

   It is good that the DLM has repsonded    ----eventually.  I notice Aardvark is now on his 11th day with zero ES over the whole period.  If he is also delayed then I suspect DLM algorithm changes have been made away from the previous 10-11th day time for a response.

[AArdvark]

It is good that the DLM has repsonded    ----eventually.  I notice Aardvark is now on his 11th day with zero ES over the whole period.  If he is also delayed then I suspect DLM algorithm changes have been made away from the previous 10-11th day time for a response.

Based on past experience i am expecting it will be around the 14 day point when DLM will re-sync my line back up to the original level.
I caused some of the delay by re-syncing the Zyxel after 6 days to switch on everything outstanding (G.INP [PhyR DS & PhyR US] & SRA) in case they ever get used by OR in the future.
[Been reading about some people getting G.INP switched on.]
(Fingers crossed re-syncs soon  )

[les-70]

  I notice that as AArdvark expected the DLM started to change on day 15 (just upstream so far), I don't know why he thought 2 weeks but for me It has always been 10 days. Maybe it depends on the DSLAM vendor.


 I still can only see one MDWS user with G.INP i.e. danbl.  danbl has attainables of about 122 and 36 Mb/s and it surprises me that G.iNP is on at all on that line.  If comments on Black Sheeps recent G.INP post are correct G.INP ought to be available, but maybe not in use, on about half lines in about about a months time.

[NewtronStar]

I still can only see one MDWS user with G.INP i.e. danbl.  danbl has attainables of about 122 and 36 Mb/s and it surprises me that G.iNP is on at all on that line.  If comments on Black Sheeps recent G.INP post are correct G.INP ought to be available, but maybe not in use, on about half lines in about about a months time.

Indeed the only one that has it does not need it that's a good example of a paradox.

[les-70]

  Unless Aardvark has some explanation the DLM seems to hate him.  Aardvarks line went fully interleaved on 14th Feb then with completely no errors at all went fast path on the upstream only on the 1st March only to go back to interleaved on the 4th. During that 3 day interval his upstream errors were very low.  Aardvark is now past 21 days and still fully interleaved, in the 21+ days he had 5 resyncs, MDWS never showing more than 1 per day and all reason 0 LOS.  Two other resyncs were the DLM changes on the upstream. Aardvark may of course know more of any other possible events.

    Previously back in September he had 14 days interleaved but otherwise has been on fast path until now.  If 21 days with completely zero errors is not enough to see a change you have to wonder and fear what has happened to the DLM or its algorithms!!

[AArdvark]

Thanks Les-70 for looking at my stats etc.

A good precis of what has been happening to my line.
I am chasing Plusnet to get some feedback.

DLM seems to be very touchy of late and very slow to recover.
I am on a Huawei DSLAM and the recovery time appears to be 14 days (unless you bounce the line  )

Some Planned BT Network Maintenance is due on my exchange tomorrow, so I expect it will bounce again.
Never know might get G.INP ........   

[Flying Porcine objects detected at 6 o.clock]   

[JustAnother]

I have just been disconnected and resynced, and suddenly MyDSLWebStats has emailed me to say G.INP is enabled on my line! I jumped from 1.42MB/Sec up to 1.69MB/Sec up so I am very pleased. So I guess no more DLM bullshit ever here.