Thanks for the details on installing the new firmware. I had installed mine wrong and not noticed it was wrong.
Replacement HG622 has just arrived: I'm in a quandry now whether to test the new firmware on the 612 first, or test out the 622. I think I'll go for the 622 though.

Any hints on how to make such tests with minimum disruption to DLM are welcome.

@Ixel: You say DLM doesn't effect me. What service do you have? I thought DLM affected all FTTC connections, and it was just the IP/BRAS profile setup that differed between suppliers.

Edited by StephenTodd (Fri 07-Jun-13 15:34:52)

I will my experience when swapping modems and what has been the best for me...

If you power up the HG612 ready and just swap the DSL cable over this always reduces my speed by 2/3Mbps. Though if you power them up then turn the current modem off at the wall then swap the DSL cable over I don't get a speedloss the sync is within 0.1/0.2 as the previous sync. (Note SNR was the same at the time of all swaps)

The reason DLM doesn't have an effect on me isn't completely clear, only theories. But it dates back to the time last year where I was fiddling around with limiting the maximum sync rate on the Fritz!Box 7390, eventually (weeks) it caused DLM to remove all interleaving in one go but it kept my speed banded at 60Mbps down and but thankfully kept the full 20Mbps up. I'm on an 80/20 FTTC service with BT Business. So, yes, DLM would normally be an issue, but I somehow stopped it working on my line altogether. I don't mind losing 20 megabits on the downstream at a bonus of having no DLM activity and no interleaving (lowest possible ping) .

@Ixel: Most peculiar!

@ryant: Thanks for the suggestion. I had heard it (probably on this forum), with a suggestion that the power down sent a 'last gasp' signal to the cabinet that allowed DLM to distinguish it from any faults. I'm not 100% sure it works; it may be that DLM stores up the fact of change; but only applies the lower speed overnight?

It's a shame the firmware doesn't have a clean 'disconnect' option. I think I'm going to give one modem an 192.168.1.2 address to make switching and experimenting easier.

Edited by StephenTodd (Fri 07-Jun-13 17:49:38)

Part 1 of my experiment done, switched to new firmware.
Slight improvement in sync speed; due to slightly reduced FEC overhead.

Text

1 23 45 67 89 1011 1213

.                   old firmware                  new firmware                 Down            Up              Down            Upmax:            81348          21752            81099          21662 path:           68816          20000            70147          20000SNR (dB):        6.3             7.0             6.0             7.1                                           R:              16              16              12              16 N:              80              254             64              254I:              80              127             64              127                                           INP:            3.00            0.00            3.00            0.00 D:              1091            1               1373            1delay:          8.00            0.00            8.00            0.00

In reply to a post by StephenTodd:

the power down sent a 'last gasp' signal to the cabinet that allowed DLM to distinguish it from any faults. I'm not 100% sure it works; it may be that DLM stores up the fact of change; but only applies the lower speed overnight?

DLM always applies its changes overnight. Perhaps, if things were *really* dire, it would intervene sooner, but every change I've ever seen has been between 2AM and 7AM.

The dying gasp signal is a bit to be set in the framing parameters sent out by the modem, and is definitely defined within the VDSL2 specification. You can't be sure that a modem's chipset actually supports it, and you can't be sure that the DLM algorithm pays attention to it.

However, I tend to trust that it works, so always choose to power down the modem in preference to anything else - and especially to just unplugging the DSL cable. I haven't yet triggered anything bad in doing so, no matter how careful or otherwise I am being.

Thanks for that confirmation, WWWombat.

I have just broken VDSL connection three times, being careful to power down each time first.
* to replace firmware in HG612
* to replace HG612 with HG622
* to replace HG622 with HG612

I'll see where that leaves my sync speed in the morning.

~~~
For some reason the HG622 has not been a success for me.
asbokid couldn't have been more helpful and understanding,
but there is something about my line or the way that I configured it that two different HG622's haven't liked.
Hence the quick swap in and out.

It could be the case WWWombat but I've always put it down to the SES/UAS errors that it creates when disconnecting the DSL cable. Then the errors are reported to the DLM when re-synced and it sees it as a high number so reduces speed but that's the only reasoning I can think of but whether it actually sends the errors when it wasn't currently synced.

In reply to a post by WWWombat:

DLM always applies its changes overnight. Perhaps, if things were *really* dire, it would intervene sooner, but every change I've ever seen has been between 2AM and 7AM.

Not always, I've seen some at various times of the day, these are the recent ones since we've had the resync log.

15/03/2013 19:10 - RESYNC detected (DS 44694 Kbps, US 11283 Kbps) since the previous ongoing data harvest (DS 41376 Kbps, US 10850 Kbps)
17/04/2013 05:56 - RESYNC detected (DS 42588 Kbps, US 10461 Kbps) since the previous ongoing data harvest (DS 44694 Kbps, US 11283 Kbps)
01/05/2013 06:00 - RESYNC detected (DS 43677 Kbps, US 10551 Kbps) since the previous ongoing data harvest (DS 42340 Kbps, US 10212 Kbps)
01/05/2013 06:57 - RESYNC detected (DS 43622 Kbps, US 10715 Kbps) since the previous ongoing data harvest (DS 43677 Kbps, US 10551 Kbps)
06/05/2013 06:27 - RESYNC detected (DS 47197 Kbps, US 10014 Kbps) since the previous ongoing data harvest (DS 43622 Kbps, US 10715 Kbps)
06/05/2013 23:08 - RESYNC detected (DS 47007 Kbps, US 10641 Kbps) since the previous ongoing data harvest (DS 47197 Kbps, US 10014 Kbps)

In reply to a post by ryant704:

but I've always put it down to

What is the "it" you have put down to?

DLM intervention after something in particular?

Of course, a power-down of the modem means there aren't any counters for it to report back to the DSLAM when it resyncs, on top of the fact it reported the loss of power on its way down.

I know SES and UAS become apparent when the errors get so bad that the line can't be sustained (An SES occurs when there are > 18 faults within 1 ES. A UAS starts when there is either no sync, or 10 consecutive SES seconds occur). So perhaps these play a part in the DSLAM counting "unexplained resyncs" in a 24 hour period.

However, I think DLM still mostly works on the average CRC count over 24 hours.