Imagine when the DSL cable is unplugged, this will create UAS/SES errors and the modem will record them. Once the cable is plugged back in it will send these errors back (Not sure if it does, this is what I believe it does) to the DLM and see that it had a rather long period where it couldn't communicate with the modem and decides to reduce the speed to try and improve stability.

That is my experience and the reason I put it down to it but whether it will report the SES/UAS back to the DLM is another matter all together!

Sorry if you find it difficult to understand

You're saying the "it" is "DLM decides to reduce the speed to try and improve stability due to the UAS/SES errors" ?

Yes, but the UAS/SES are obtained when the DSL cable is unplugged. I'm not saying it does but is the only really real reason I can think of as the SNR was at 6.2.

I'm not saying it is that but it's what I personally believe and have worked out from my experiences.

Sorry if you find it difficult to understand

I understand everything you wrote (in the post I'm replying to).

What I didn't originally understand was the "it" that represents the consequences of the link being unplugged, and the counters sent back. But I guess you are talking about DLM making an intervention.

send these errors back [...] to the DLM and see that it had a rather long period where it couldn't communicate with the modem

I can't tell you for sure what DLM makes use of to choose when to intervene, but I can be pretty sure that it *isn't* the UAS value.

If you just leave the modem disconnected from the phone line, but powered up, the UAS counter will be constantly increasing. Why should that circumstance be a thing that DLM cares about? DLM can only intervene by defining the end result of the sync - it can't do anything to make a sync happen, and certainly can't make any change whatsoever if there is no physical path.

To me, it just doesn't make sense to have DLM intervene because of a physical disconnection.

this will create UAS/SES errors and the modem will record them

SES could be a factor in the decision-making, but SES shouldn't be incrementing in the circumstances you describe. When the UAS counter is active, SES should be inhibited anyway... not least because the modem can't be performing CRC checks on a line that isn't in sync.

And remember that UAS, SES and ES aren't "errors" as such. They are "seconds" during which certain events or states were seen.

but whether it will report the SES/UAS back to the DLM is another matter all together

The specification for what gets sent back is included in spec G.997.1, where all the parameters that get sent from modem back to the DSLAM tend to be named something-XFE (for example, UAS-LFE, ES-LFE, SES-LFE, CRC-PFE).

DLM then gets the values from the DSLAM.

Interestingly, the BT SIN that regulates the VDSL2 modems has a definition for the minimum parameters that must be correctly sent back to the DSLAM@ Take a look at the SIN document, requirement "R.VDSL2.17".

The SIN includes FECS-LFE, ES-LFE, SES-LFE, so you can probably assume that these could well be used by DLM. However, it doesn't include UAS-LFE or CRC-PFE - so these almost certainly aren't included in the DLM calculation!

That last one is a surprise to me, certainly!

In reply to a post by ryant704:

is the only really real reason I can think of as the SNR was at 6.2.

I'm not sure what you are saying there.

Are you suggesting that certain SNR values or ranges trigger DLM intervention?

It's not really a secret, if you do reset the modem when the SNR is lower than target (6) you are more likely to lose speed. The same applies when the SNR is higher it will increase the speed if it's above target. Of course that is very basic and I know there is more to take into account but on very basic terms this will more than happen 99% of the time (100% in my case and experience for my line).

Edited by deleted (Sat 08-Jun-13 02:00:42)

But a resync that happens because of a low SNRM is just that - a resync. Yes, it will adjust the speed as you say, but by relatively small amounts, and in proportion to the difference from the target SNRM.

That kind of resync does NOT alter the FEC or interleaving settings, and doesn't band the speeds.

A low SNRM triggering a resync like this is NOT triggering a DLM intervention. That is a different thing.

When DLM does intervene, it will turn on FEC and interleaving, by specifying new settings, or by adjusting those settings. It might also set speed bands (with minimum and maximum speeds).

All of those settings, once in place, will indeed affect the sync speed too, but they are usually considerably bigger changes in speed than that seen during a simple resync.

When DLM has chosen to intervene, and has set the new settings, it causes the changes to take effect by triggering a resync... but this is one that is enforced merely so that the new parameters are used during the new sync.

Edit:
You have unlocked the modem, so use the "xdslcmd info --show" command to view the settings.

The "INP" and "delay" values are the primary parameters set by a DLM intervention. Those wouldn't change over a normal resync.

From those 2 parameters, the modem chooses "R", "I", "D" and "N" parameters during the sync, which are the detailed FEC and interleaving parameters. Those don't normally change during a plain resync either, but they are a little more flexible.

If you aren't seeing a change in these 6 values, then you have a plain resync.

However... note that we discovered that changing the HG612 firmware can result in a sync with different R, I, D and N values for the same INP and delay values. The firmware is definitely making different choices.

Edited by deleted (Sat 08-Jun-13 02:25:25)

Just checking my understanding, and missing bits, and maybe a useful key for others who part understand ...

FEC - forward error correction ~ number of corrected errors == RSCorr
CRC - cyclic redundancy check ~ number of uncorrected errors == OHFErr
ES - errored seconds ~ number of seconds that included any uncorrected errors
SES - severe errored seconds ~ number of seconds that included >18 uncorrected errors
UAS - unavailable seconds ~ number of seconds during which the link was effectively unavailable
LOS - ???
LOF - ???
FECS - forward error correction seconds ~ number of seconds with corrected errors ~ does this appear in modem stats?

LFE - line far end
PFE - ???

RSUnCorr - ??? also the number of uncorrected errors, but measured in a different way from CRC or a different kind of error ???

~~~
Also, does what you said above imply that the FEC/RSCorr rate is not used as part of the DLM calculation?

Just to confirm that three broken modem connections yesterday fairly close together, all done by unplugging the modem first, did not cause DLM to do anything nasty to my sync either immediately or overnight.

Loss of Frame
Loss of Signal
Path Far End
"The SIN includes FECS-LFE" implies FEC/RSCorr rate is used.

Edited by deleted (Sat 08-Jun-13 11:36:02)