I believe Openreach's VDSL service does use lSeamless Rate Adaption, so your sync rate can change without a retrain.

In reply to a post by lee111s:

I believe Openreach's VDSL service does use lSeamless Rate Adaption, so your sync rate can change without a retrain.

SRA is not enabled on OR's VDSL circuits.

http://forums.thinkbroadband.com/fibre/t/4239755-re-...

Edited by deleted (Mon 25-Apr-16 12:35:02)

As I mentioned previously today, I'll check the log in more depth at lunch time. I didn't say there wasn't a resync, I said I didn't see it in the logs.

That to me reads they do use it although don't simply call is SRA as they can use the algorythm to modify the interleaving depth too, without a retrain?

"The SRA is limited to tweaking the minimum and maximum data rates (banding), but the Openreach DLM algorithm can also modify the interleaving delays and impulse noise protection levels (and theoretically the TSNRM too)"

The use of the word "also" being key.


Additionally, that post was made in 2013, some 3 years ago. I note that Openreach did carry out some SRA trials along with vectoring so it's possible SRA in one form or another is in use.

I guess we'll wait and see what the OP comes back with.

Edited by deleted (Mon 25-Apr-16 13:00:12)

In reply to a post by lee111s:

That to me reads they do use it although don't simply call is SRA as they can use the algorythm to modify the interleaving depth too, without a retrain?

"The SRA is limited to tweaking the minimum and maximum data rates (banding), but the Openreach DLM algorithm can also modify the interleaving delays and impulse noise protection levels (and theoretically the TSNRM too)"

The use of the word "also" being key.

OR's DLM requires a retrain for changes to take effect. OR does not use SRA on FTTC circuits.

SRA dynamically adjusts sync rate on the fly which I've never seen occuring.

"No" to software IP Profile changes. (Other than, of course, any change to IP Profile caused by a change of sync).

FTTC IP Profile is 0.9678 x sync (no G.INP) or 0.9669 x sync (with G.INP), though some recent results from ECI kit seem to be clouding that simplicity.

I think I see what has caused this. G.inp has been disabled on the line. Obviously DLM must also have been reset if G.inp has been turned off. Would I be right in my assumption?

Sounds that way. I think we saw one a week or so ago where this happened but it wasn't BTW >> BTW.

Fingers crossed then when G.inp kicks in (and hopefully soon as there's lots of errors on line now) the speed will increase. I seem to remember when G.inp kicked in last year for the first time, I gained 7-8Mbps!

Have a look at your FEC graph ... It is interesting that from either 18:30/19:00/19:30 to 22:30 every night they drop down to near zero.

That suggests there is a noise source somewhere that is causing a problem and the source is turned off during the evening. I would certain not expect such a specific notch every day.