Whereas the SNR spectrum upates in real time on my Netgear modem, the QLN spectrum is unchanging. Looking for a way to update it, I noticed the qlnmntr command (presumably QLN monitor) on the telnet interface.
There was a brief discussion on this forum back in 2012, about the purpose of the command. At the time, the advice from Bald_Eagle1 was to "give it a go". So I did. The telnet interface shows the command syntax as:
adslctl qlnmntr [--time <sec>] [--freq <msec>]
A Zyxel modem with a very similar interface (search for "VMG1312 cli reference manual") has more detailed information:
adsl qlnmntr [--time] [--freq]
--time :
Sets the time in seconds for which QLN monitoring is to be done.
If set to 0, monitoring will be done for ever.
--freq :
Sets the frequency in milli-seconds of QLN reporting.
At the end of monitoring time , the result is available in the QLN MIB info
and can be seen using
adsl info --QLN :
Also, during the monitoring period the updated results is being updated
in MIB and can be seen every “--freq” milli-seconds.
On experimenting, I found the Netgear "adslctl qlnmntr" command to work as described in the Zyxel document, the "freq" parameter being the measurement period. For example "adslctl qlnmntr --time 30 --freq 6000" gives an fresh QLN spectrum every 6 seconds, for 30 seconds. But there are a few important wrinkles.
1. The first update can be badly wrong, by as much as 20 dB, so is best ignored.
2. During the updates, the internet connection is lost, and the returned SNR spectrum is unchanging.
3. Rather than doing a continuous QLN estimate and updating once per period, the software does a completely new assessment for each period. As random noise estimates are more accurate the longer they can be averaged, short periods give noisy results. For instance, a period of 200 ms gives random variations (between periods) in the region of ± 5 dB, whereas a 2 second period has variations of about ± 0.5 dB, as does a 10 second period. Since QLN is only reported to the nearest 0.5 dB, it's hard to be more definitive. A 2 second period appears to be the sweet spot for getting a quick update.
4. Following on from 3, it seems that a longish period gives a less noisy QLN curve than the one generated automatically when the modem reboots. Just ignore the first result, as mentioned in 1 above.
5. Usefully, a new qlnmntr command overrides any existing one.
6. This is the unpopular bit. The modem is disconnected from the internet during QLN updates, but remains disconnected after the updates have ended. The modem Web interface is responsive, but on the browser the internet Connect button has no effect. The only way I found to resume normal operation was to reboot the modem.
Overall, the qlnmntr command seems useful in a lab setting, but of limited use otherwise.
I will be grateful if anyone finds a way to reconnect quickly after a QLN calibration, preferably via the telnet interface.
