If I set the upstream target SNRM using clueless.aa.net.uk, most of the time it remotely triggers a resync within a few seconds. I set the parameters as I want them and hit SNR RESET. Iirc, sometimes a resync doesn’t happen. My best guess is that it might be to do with the system’s idea of something like that ‘target margins have / have not changed’ or ‘the current values of the various fields are xxx and it’s still like that, so nothing to do’. But I’m not sure. I’m very fuzzy about this just now.
Does anyone know if there is anything written up in the various standards docs, BT SINs, The Broadband Forum (is that right?), anyway, the usual suspects etc etc ?
> for your upstream the DSLAM would control it
Understood. Thanks. Btw, is that directly or indirectly, do you know? By which I mean is it the case that the DSLAM tells the CPE modem what to do or perhaps ‘asks’ it please do x in that respect? Or is it more direct and doesn’t work like that?
That would explain a lot, would it not? The DSLAM normally controls what happens in the resync and ensures that the initial value of the upstream SNRM is at the target as expected. But then if going to the correct target at resync time relies on the DSLAM remotely controlling things, and if no persistent setting gets stored in the CPE modem as a ‘standing order’, ‘for all future resyncs’, then when I do a CLI-initiated resync, that is then outside the sphere of influence of the DSLAM perhaps. So it could be that the behaviour that has been seen is just exactly what I should have expected had I but known how things work?