Beware the router can still say fastpath on the stats UI page when it's actually not fastpath, hence why your ping might still be higher than expected.
Yep still reporting things wrong in various areas.
Regarding line attenuation, on the HG612 quite some time ago I have a screenshot of my pbParams data, clearly the ASUS is measuring the U0 attenuation (either line or signal, not sure which). However it might be calculating it a little lower than it should actually be.
U0 bank of stats are for the line way before they get to you, thats why the whole bank of them hardly vary at all, and why the power figures are minuses... or to make more sense of the Huawei poor formatting job (assuming this formats it correctly lol)....
Code:
VDSL Band Status U0 U1 U2 U3
Line Attenuation(dB): 1.3 20.3 31.7 N/A N/A 11.5 27.1 42.2
Signal Attenuation(dB): 1.3 20.2 31.6 N/A N/A 12.3 26.8 42.2
SNR Margin (dB): 16.8 16.1 15.6 N/A N/A 25.4 25.3 25.4
TX Power(dB): -5.1 -22.7 5.6 N/A N/A 9.1 7.3 6.5
Obviously altering the DSL settings such as the transmit power offset will effect this. Another interesting fact is that if I reduce my offset too much (e.g. to get an ideal attainable near to the 20Mbps upstream sync rate limit) it will cause downstream error statistics to be worse,
Alters the tones and possibly re-allocates them, depending on the routine asus are using.
such as increased errored seconds, severely errored seconds, FEC errors and/or CRC errors. So far the best setting that works for me appears to be +1 dB on the transmit power offset.
They should IMO just do away with that setting and fix it to allocate properly by iteself. All it does (as is obvious from some of the last few contributions
) is confuse people.
My current DSL settings:
http://i.imgur.com/2MoReXp.png
Code:
near-end path0 fec: 666233
near-end path0 crc: 28
near-end fec sec: 5797
near-end err sec: 10
near-end ses sec: 0
near-end los sec: 0
near-end ua sec: 0
far-end path0 fec: 589
far-end path0 crc: 94
far-end fec sec: 144
far-end err sec: 88
far-end ses sec: 0
far-end los sec: 0
far-end ua sec: 0
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.5 dB
AttenDown=10.3 dB
SNRMarginUp=12.6 dB
AttenUp=0.1 dB
DataRateDown=62681 kbps
DataRateUp=20000 kbps
ADSLUpTime=2 days, 6:18, 50 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.1 dbm
PowerUp=5.8 dbm
AttainUp=30249
AttainDown=104492
InterleaveDepth=1747
AdslStandard=VDSL2
AdslType=ANNEX_B
That's currently an average of around 12,000 FEC errors an hour, when I increased transmit power offset to +3 dB the FEC errors were almost continuously counting on the downstream. Reducing it to -5 dB also produced more FEC errors and CRC errors on the downstream. A setting of 0 dB (or default) resulted in a slightly higher rate of FEC errors compared to +1 dB at the moment. I'm leaving the settings as they are now and will wait for G.INP.
That now (attenuation figures, unless you have seriously tweaked something) when comparing to your old Huawei stats confirms what i thought its reading signal attenuation rather than actual line those figures are (allowing for device variation) as near to the U0 stats of the Huawei. It looks like its grabbing stats remotely at the cabinet or exchange rather than at your line end at sync time. Im not shocked that there is still various issues if its doing that, could also explain why it thinks everything is Fastpath LOL as it would be at the exchange its only at the cabinet DLM and interleaving gets applied. (at least i think thats the case still).
Final note, G.INP will mask the stability problems on older firmware, so while ESNP is not required I imagine G.INP will be a bit more active without ESNP (provided the line previously suffered stability problems with the ASUS before G.INP was enabled on the line).
Its going to be a right mish mash now of trying to interpret what a line is actually doing with G.INP and quirk figures on some devices.
Oh, I also believe bitswapping on VDSL2 is working. I initially synced with around a 7 dB SNRM on the downstream, and it's currently 8.5 dB. No noticeable activity at the cabinet/PCP recently either.
Only problem is that may be a remote and not LINE figure its reporting now though.
