Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: snadge on June 05, 2013, 11:14:17 PM
-
whats your opinion?
is it safe to turn off the modem and router?
or is it best to leave it on 24-7?
also, Im assuming someone from kitz wrote this in plusnet forums.... I dunno if Iam reading it right but the bit in bold sounds like a method to 'reset' the connection to ensure the best/proper speed profile for your line.. is this correct?
Unfortunately Plusnet can't get Openreach to do resets similar to ADSL, so it's a waiting game.
As you may have gathered, DLM on FTTC. can be aggressive, so as a general rule - do not turn off, reboot or disconnect the modem.
Should you ever have a real need to do that, the best method is to log into the Router, disconnect your PPP Internet session and then power down the Router. After about a minute power down the Modem and leave it off for at least an hour. Do this in daylight hours well away from dawn or dusk.
When you power up again wait for sync and all lights on the Modem to stabilise before powering up the Router. When the Router has booted, login and and click Connect to establish a PPP session.
There is no guarantee that doing that will improve the situation, it may stay the same or be slightly worse.
The best way to check the the sync speed of your connection is to run the BTw Performance test (ignore the red preamble except make sure no other programs are using the Internet) and at the end of the first run, click the Further Diagnostics button, enter just your Phone number and Run the Further Diagnostics Test. The results will show the DS IP profile for the Line (ignore the US profile). On FTTC the Profile x1.033 = sync speed. If you ever want to post the results here, just do a Copy and Paste of the results and post (no need to grab an image).
Do not rely on the ping result from the first part of the BTw Speedtest, it can be very variable and dependant on Tester congestion. Use ping ntp.plus.net from a cmd prompt. Pingtest.net can be quite reliable as well. But remember all testers can get congested a peak times and you should not rely on a single result. The same applies to speedtesters. You can get momentary peaks/dips at anytime so if you get an "unusual" result, run several tests. To get a true picture of the capabilities of your connection, run tests at off-peak times and try several testers to find which ones give consistent results for you.
One final point, the Current Line Speed at the member centre is initially set at the default value of 78Mbps for FTTC 80/20. This will update in due course to match the BT IP Profile, but if you want to ensure you get an accurate Profile from the BT Tester and ultimately the Current Line Speed, you need to login to the Router, drop the PPP session, wait about 30seconds and then click connect. This will initiate an update to the relevant servers. Do that will also mean you generally hop to another Gateway at Plusnet, which is something you may want to try if there are instances of persistent problems with slow downs or increased ping, just to check if it's Gateway related.
-
It's safe to disconnect/reconnect your router, but not the modem. DLM shouldn't intervene if it's just a one off for the modem, but a few times in a day might set it in motion. As a matter of course, though irrelevant for my line as DLM isn't functioning, I've set my ASUS RT-N66U router (with Tomato Shibby firmware) to automatically disconnect and reconnect the PPP session at 7:30am every day. If DLM were running on my line this would help ensure that my 'IP Profile' is kept in line with what my sync speed currently is. I prefer to keep the modem and router on 24/7 with a small desk fan underneath them blowing air upwards to keep both the HG612 and the ASUS RT-N66U nice and cool.
-
Leave the modem on constantly.
Turn the router on at the start of the day and turn it off at the end of the day -- if that is what you are accustomed to do.
-
I think that B*Cat's advice is very sensible. :)
If you have to power down the modem for any reason, it may help to appreciate the basis upon which DLM attempts to detect whether this was a user-caused resync or 'unforced retrain', or a 'forced retrain' caused by line conditions, as it tries to eliminate the former when determining the stability of your line.
Basically, it monitors the uptime in 15minute slots. If a slot has some uptime, and then is followed by one with none, then clearly something has happened. Either the user has powered it off, or the modem is having difficulty retraining ie regaining sync. However, if DLM sees at least two successive time slots with no up time (i.e. at least 30mins) then it should regard it as user-initiated and ignore it.
One final point. Asbokid has pointed out elsewhere that some modems have a last gasp communication function with the DSLAM if it is powered off, and so powering it off is preferable to unplugging the DSL line from the modem, as that may cause errors that are recorded by the DSLAM and held against you.
HTH
-
The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.
As said earlier, DSL modems may not like being turned on/off especially in a short time span, mainly because you are likely to be getting your IP address changed with 'might' conflict with software you already have set-up, plus I believe your modem has to go through what is called a 'self learning' stage, before it is up and running to it's peak performance, but confirmation of that may be required from one of the many wizz kids here on the forum.
Whereas with Fibre optic (at least with mine) my IP address only gets changed maybe about once a year and as far as I know there is no self learning curve for it to go through.
With saying that, with my fibre optic from Virgin Media I used to turn my modem off at the end of each evening which I did for a few years without any adverse effects.
But I think you will find the general consensus is just to switch it on and forget about it, (unless you are having problems and need to re-set the modem.
-
The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.
:hmm: Hmm, as this is the forum for FTTC and FTTH Issues I think we can fairly sure of the xDSL type to which Snadge refers . . . :D
-
The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.
:hmm: Hmm, as this is the forum for FTTC and FTTH Issues I think we can fairly sure of the xDSL type to which Snadge refers . . . :D
Considering my post above covers 2 different types of modem I'm sorry you feel you had to pull me up on the one issue that may not have been 100% relevant.
-
As said earlier, DSL modems may not like being turned on/off especially in a short time span, mainly because you are likely to be getting your IP address changed with 'might' conflict with software you already have set-up, plus I believe your modem has to go through what is called a 'self learning' stage, before it is up and running to it's peak performance, but confirmation of that may be required from one of the many wizz kids here on the forum.
So, if you have a static IP address and have passed the 'self-learning' stage, then you can switch it off and on as much as you like with impunity no matter who your ISP is? :no:
The main question here should be if it's a 'DSL/ADSL modem or Fibre optic.
Isn't the main question whether an EU's broadband line is subject to DLM or not, and if so, how that DLM works?
But I think you will find the general consensus is just to switch it on and forget about it, (unless you are having problems and need to re-set the modem.
Surely the original question was
is it safe to turn off the modem and router?
-
Considering my post above covers 2 different types of modem I'm sorry you feel you had to pull me up on the one issue that may not have been 100% relevant.
Don't forget, BT Fibre Optic uses VDSL signals - and is still therefore an xDSL modem. Your original post makes out that the Fibre Optic modem is NOT an xDSL modem, when it is. We're in the FTTC/FTTH forum, so we're not talking about Virgin Cable Fibre Optic, rather the BT Infinity Fibre Optic version via the phone lines. :)
-
OK, point taken, and please forgive an old codger for trying to be helpful.
Edit, typo
-
I think keeping the modem off is ok as long as its for a long period rather than doing it numerous times a day such as going on holiday, but cant be sure 100%, however I think its risky to leave the modem on with the dsl cable unplugged. As it will tally up UAS.
Some also mentioned on tbb that if yoju cut the power from the modem rather than pulling the dsl cable it will send a dying gasp which DLM interprets as not to treat as line instability, but this is theory only.
-
Some modems have a Dying Gasp communication function with the DSLAM if it is powered off, and so powering it off is preferable to unplugging the DSL line from the modem, as that may cause errors that are recorded by the DSLAM and held against you.
Just got round to testing this with the HG612 and the ECI vg3503j (Revision /r) VDSL2 modems from Openreach.
Here's the kernel logging (to UART) from the HG612 up to the point that its power plug is pulled:
Line 0: xDSL G.994 training
Line 0: VDSL G.993 started
Line 0: VDSL2 link up, Path 0, us=20000, ds=79987
2000-1-1 0:1:17 Notice 104500 DSL activate succeed
# =====>Now,begin dying...
D%G
And there ^^^^ is the Dying Gasp message (D%G) being sent by the HG612 to the DSLAM as its 12v power lead is pulled out.
Over at the DSLAM.. We can see this Loss-of-Power state recorded in the statistical performance log for that subscriber port.
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 41
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 22 (and rising)
..
------------------------------------------------------------------------------
So the Huawei HG612 and the Huawei MA56xx DSLAM both communicate and record the Dying Gasp and loss of service due to Loss of Power. (22 seconds lost at this point).
The seconds from Loss of Power can be subtracted from UnAvailable Seconds (UAS), a counter which also includes the time taken to sync up.
Now we can try the next stage of the Dying Gasp Test (defined in TR-115 Iss.2 Amnd.1 May 2013) [1]. That is to disconnect the live loop between the DSLAM and the HG612. Simply by pulling the DSL cable from the modem.
Resetting the DSLAM's statistical counters first.
MA5616(config-if-vdsl-0/3)#chipset reset 0
Note: Please don't operating on port while chipset resetting, are you sure to continue? (y/n)[n]:y
We can see, below, that pulling the DSL cable causes no Dying Gasp message to be sent.
Consequently, the Loss of Power counter at the DSLAM remains unchanged. Only the UnAvailable Seconds counter is incremented. Perhaps, surprisingly, there is no change to the Loss of Link counter.
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 31 (and rising)
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
Now another test (not in the prescribed TR-115 Dying Gasp Test). We will cause a loss of sync by introducing a high level of line noise to see how the DSLAM records those seconds of lost service.
Here's what the HG612 kernel reports to UART when that line noise is injected. It immediately re-syncs (albeit at massively reduced speeds because of the noise).
Line 0: VDSL2 link down
2000-1-1 0:25:32 Notice 104500 DSL deactivate
Line 0: xDSL G.994 training
Line 0: VDSL G.993 started
Line 0: VDSL2 link up, Path 0, us=6496, ds=16975
2000-1-1 0:25:53 Notice 104500 DSL activate succeed
Over at the DSLAM, all we can see for that re-sync from line noise in terms of seconds with problems is one ES and one SES, and an extra "full initialisation":
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 1
Count of severely errored seconds : 1
Count of loss of signal seconds : 0
Count of unavailable seconds : 348
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-initial ever-before
------------------------------------------------------------------------------
Count of full initializations : 2
Count of short initializations : -
Count of failed full initializations : 0
Count of failed short initializations : -
------------------------------------------------------------------------------
That injected line noise caused large number of errors, but these are reported in detail as 'channel statistics' rather than as 'line statistics'. In the downstream (CO end) the noise which caused that re-sync is recorded as follows:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 channel 1 co current-15minutes
------------------------------------------------------------------------------
Start time of this interval: 2013-06-07 03:30:00+08:00
Channel 1
The number of valid intervals in the interval table : 2
The number of invalid intervals in the interval table : 94
Total elapsed seconds in this interval : 402
Count of coding violations : 8
Count of corrected blocks : 34170
Count of encoded blocks : 37024
Count of uncorrectable blocks : 257
Count of atm cells : 0
Count of ptm packets : 82
Count of the number of retransmitted RS codewords : 0
Count of the number of retransmitted codeword that
effectively corrected a previously detected error : 0
Count of codewords that left the retransmit queue
without having been corrected : 0
------------------------------------------------------------------------------
Finally, just to confirm that the ECI vg3503j (Revision /r) also sends a Dying Gasp message. Although nothing is reported by the ECI's kernel:
Reset the DSLAM statistical counters first:
MA5616(config-if-vdsl-0/3)#chipset reset 0
Note: Please don't operating on port while chipset resetting, are you sure to continue? (y/n)[n]:y
From the ECI's kernel messages (to UART), up to the point that power is pulled:
[ 11.664000] Lantiq CPE API Driver version: DSL CPE API V4.11.4
[ 11.672000] Predefined debug level: 2
[ 11.704000] PTM 1.0.27 PTM (E1) firmware version 0.30
[ 11.708000] ifxmips_ptm: PTM init succeed
[ 19.880000] device ptm0.101 entered promiscuous mode
[ 19.884000] device ptm0 entered promiscuous mode
[ 19.888000] br-lan: port 3(ptm0.101) entered forwarding state
[ 20.812000] IPv6: ADDRCONF(NETDEV_CHANGE): ptm0.101: link becomes ready
[ 21.828000] br-lan: port 1(eth0) entered forwarding state
[ 21.896000] br-lan: port 3(ptm0.101) entered forwarding state
..
[ 94.576000] enter showtime
No loss of power seconds recorded by the DSLAM at this point.
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 39
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
Now the power plug is pulled on the ECI (no indication of a Dying Gasp message from its kernel):
And in the DSLAM logs we find:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 63
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 29 (and rising)
So that confirms that both the Huawei HG612 and the ECI vg3503j (Revision /r) do send a Dying Gasp message when the power is pulled from them.
cheers, a
[1] http://www.broadband-forum.org/technical/download/TR-115_Issue-2_Amendment-1.pdf
-
OK, point take, and please forgive an old codger for trying to be helpful.
:friends:
-
Asbokid has pointed out elsewhere that some modems have a dying gasp communication function with the DSLAM if it is powered off, and so powering it off is preferable to unplugging the DSL line from the modem, as that may cause errors that are recorded by the DSLAM and held against you.
Okay, just got round to testing this with the HG612 and the ECI vg3503j (Revision /r) VDSL2 modems from Openreach.
<snip>
So that confirms that both the Huawei HG612 and the ECI vg3503j (Revision /r) do send a Dying Gasp message when the power is pulled from them.
A masterful series of experimental results. Thank you for sharing. :)
I have another experiment that you might like to perform with one the Broadcom based Huawei HG6xx devices. Re-establish the CPE - CO link, with counters cleared, etc, make a telnet connection to the HG6xx device and then issue an xdslcmd connection --down command. It would be interesting to know how the MA5616 (DSLAM) reacts to that event. :-\
-
I have another experiment that you might like to perform with one the Broadcom based Huawei HG6xx devices. Re-establish the CPE - CO link, with counters cleared, etc, make a telnet connection to the HG6xx device and then issue an xdslcmd connection --down command. It would be interesting to know how the MA5616 (DSLAM) reacts to that event. :-\
The DSLAM just records the (forced) downtime from that command under the counter heading of more UnAvailable Seconds:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 122 (and rising)
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
For the sake of completeness (or almost, as the Ikanos Fusiv Vx180/185 chipset still needs testing), the Metanoia MT3301/2301 chipset was tested. The Metanoia VDSL2 chipset is found in the Draytek Vigor 2750/2850 and the Planet VC230.
The Metanoia does *not* send a Dying Gasp message.
Before pulling the power plug:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 36
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
And a few seconds after pulling the CPE power. Note the lack of any Loss of Power seconds:
MA5616(config-if-vdsl-0/3)#display statistics performance 0 line-showtime cpe ever-before
------------------------------------------------------------------------------
Count of forward error correction seconds : 0
Count of errored seconds : 0
Count of severely errored seconds : 0
Count of loss of signal seconds : 0
Count of unavailable seconds : 39
Count of leftr defects seconds : 0
Count of the number of error-free bits passed(64kBit) : 0
Minimum error-free throughput : 0
Count of loss of frame seconds : 0
Count of loss of link seconds : 0
Count of loss of power seconds : 0
cheers, a
-
yeah nice tests thanks, the only unknown now is if dlm takes the loss of power counter into account, but given openreach documentation, my guess is it does.
-
thanks for replies :)
I meant VDSL modem and turning them off at nights when going to bed....sorry should have made that clear - i would have thought DLM is set to ignore loss of sync if its late in evening and connects again 6am onwards...indicative of owner going to bed?
ASBOKID - how the heck do you get all the info from the DSLAM? - impressed!! :graduate:
-
ASBOKID - how the heck do you get all the info from the DSLAM? - impressed!! :graduate:
May I suggest that owning the DSLAM allows one to connect to its various service ports and to enter its configuration modes. ;)
-
ASBOKID - how the heck do you get all the info from the DSLAM? - impressed!! :graduate:
May I suggest that owning the DSLAM allows one to connect to its various service ports and to enter its configuration modes. ;)
so Asbo actually has a DSLAM in-house hehe?? thats dedication for you
-
Yeah, Our Wayne and his mate Fingers of Feltham lifted it for us! Only joking! :D Huawei vendors were selling them for £70 on Taobao, to clear stock when Huawei started shipping a replacement central control unit. Though SFAIK this one is the same as BT has been using (with a CCUB controller).
Quite useful for hacking. Just using it now to develop some code for OpenWrt on the ECI /r VDSL2 modem. It would be impossible to do this work with the number of errors and re-syncs I've caused (deliberately injecting noise onto the line). On a live Openreach circuit, DLM would have down-profiled it to just a few bits per seconds!
cheers, a
edit: finally getting some error counters out of the ECI now. Not sure what they mean, so just checking them against the counters held by the DSLAM.
CPE Chipset: Lantiq-VRx:5.4.8.6.1.6
CO Chipset: BDCM:v10.07.26
Line State: UP [0x801: showtime_tc_sync]
Attain Data Rate: 28848 Kbps / 50000 bps
Actual Data Rate: 28832 Kbps / 944000 bps
Interleave Delay: 0.0 ms / 0.0 ms
Impulse Noise Prot: 0.0 sym / 0.1 sym
Line Attenuation: 44.8 dB / 0.0 dB
Signal Attenuation: 40.2 dB / 0.0 dB
Noise Margin: 5.1 dB / 1.7 dB
Transmit Power: 13.2 dBm / 4.0 dBm
Line Uptime: 8m 57s
Chan FEC Errors: 56 / 8709
Chan Code Violations: 1 / 128
Path CRC Errors: 0 / 1460
Path Code Violations: 0 / 100941
-
so Asbo actually has a DSLAM in-house hehe?? thats dedication for you
Yes, indeed. ;)
I seem to recall him telling me that the MA5616 was a nice fit in the shower cubicle and that the waste pipe was a useful duct through which to route a fibre-optic feed! :D
Here is a new Huawei SmartAX MA5616 (http://www.ebay.co.uk/itm/261131145650), available as a 'Buy It Now' item on eBay.
-
haha - I was thinking that about the errors/DLM aswell asbo ;D ;D ;D
-
haha - I was thinking that about the errors/DLM aswell asbo ;D ;D ;D
Yes, it's useful looking at both ends of a connection, particularly for checking error rates!
From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly. It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.
E.g. in the screenshots below, the errors are recorded at both DSLAM and CPE as 300mV amplitude Gaussian noise is injected into the line. The noise causes a splurge of channel/path errors including, according to the DSLAM, 208 RsUncorr errors in the upstream. These are labelled as "uncorrectable blocks". Yet the HG612 doesn't record any of them. Hmm... And god knows where its figure of 842 HEC errors comes from. ???
cheers, a
-
From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly. It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.
Can you test this again, with DS interleaving on at say, a depth of 400 or 500 and US Interleaving on at some depth?
I saw downstream RSUnCorr counts when my VDSL2 connection had DS Interleaving at a depth of around 400 or so, but no upstream counts (possibly because upstream Interleaving was OFF):-
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 5108 Kbps, Downstream rate = 27200 Kbps
Path: 0, Upstream rate = 5079 Kbps, Downstream rate = 23567 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.0 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 13.0 6.3
VDSL2 framing
Path 0
B: 63 159
M: 1 1
T: 60 36
R: 16 14
S: 0.0864 0.9986
L: 7409 1394
D: 373 1
I: 80 87
N: 80 174
Counters
Path 0
OHF: 146964063 343224
OHFErr: 29345 144
RS: 683727268 3391028
RSCorr: 18880457 416
RSUnCorr: 1221537 0
Now that my connection is strangely on fastpath, RSUnCorr counts are zero for both DS & US:-
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 4205 Kbps, Downstream rate = 21232 Kbps
Path: 0, Upstream rate = 4563 Kbps, Downstream rate = 20209 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.7 5.4
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 6.3
VDSL2 framing
Path 0
B: 239 143
M: 1 1
T: 57 34
R: 0 12
S: 0.3777 1.0000
L: 5084 1248
D: 1 1
I: 240 78
N: 240 156
Counters
Path 0
OHF: 107465258 599047
OHFErr: 21311 69
RS: 0 3154280
RSCorr: 0 62
RSUnCorr: 0 0
Was Interleaving ON at any depth on all the ADSL connection(s) you have examined?
I believe this is an example from your own connection (DS Interleaving depth of 64 & US OFF):-
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 8000
Max: Upstream rate = 1200 Kbps, Downstream rate = 21856 Kbps
Path: 0, Upstream rate = 1020 Kbps, Downstream rate = 19944 Kbps
Link Power State: L0
Mode: ADSL2+
TPS-TC: ATM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 2.4 11.9
Attn(dB): 18.5 9.7
Pwr(dBm): 19.3 12.3
ADSL2 framing
Path 0
MSGc: 59 10
B: 123 145
M: 2 1
T: 5 1
R: 6 0
S: 0.3972 4.5447
L: 5115 257
D: 64 1
Counters
Path 0
SF: 6898534 586924
SFErr: 2953 16
RS: 1121011482 0
RSCorr: 9065728 0
RSUnCorr: 60746 0
-
From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly. It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.
Can you test this again, with DS interleaving on at say, a depth of 400 or 500 and US Interleaving on at some depth?
I was just saying to Colin that this would be a useful test. I will have a look at setting up the experiment. Interleaving isn't unfortunately configurable to the extent of setting the exact depth. Not even by DLM.
The Huawei DSLAM has a channel-profile parameter that allows the *maximum* interleaved *delay* to be set (and the inter-related *minimum* number of symbols to be protected by INP) but whether or not that maximum is fully utilised, or just a fraction of it, is up to the DSLAM.
So we can create a maximum of, say, 8ms delay in each direction, but the algorithm in the DSLAM will only increase the interleaver depth as much as needed, presumable to try and satisfy some BER, as well as keeping within that delay limit.
I saw downstream RSUnCorr counts when my VDSL2 connection had DS Interleaving at a depth of around 400 or so, but no upstream counts (possibly because upstream Interleaving was OFF):-
The DSLAM does appear to be recording *upstream* uncorrectable errors that the HG612 doesn't record. From a quick google it looks like it's a common issue with this and other Broadcom 6368 devices.
Interleaving and Forward Error Correction are not synonymous though. It's possible (maybe normal practice) to still use FEC without interleaving. The reverse isn't true though. So setting it to fastpath could still see FEC (RSCorr / RSUnCorr) errors reported.
cheers, a
-
Interleaving and Forward Error Correction are not synonymous though. It's possible (maybe normal practice) to still use FEC without interleaving. The reverse isn't true though. So setting it to fastpath could still see FEC (RSCorr / RSUnCorr) errors reported.
Ah, that could explain why I still see a small number of US RSCorr errors, even though DS & US Interleaving is OFF, with INP & delay at zero.
Counters
Path 0
OHF: 107465258 599047
OHFErr: 21311 69
RS: 0 3154280
RSCorr: 0 62
RSUnCorr: 0 0
Path 0
HEC: 50030 0
OCD: 0 0
LCD: 0 0
Total Cells: 1055279342 0
Data Cells: 80880670 0
Drop Cells: 0
Bit Errors: 0 0
ES: 26064 482
SES: 392 0
UAS: 974 974
AS: 580611
Path 0
INP: 0.00 0.00
PER: 5.38 17.00
delay: 0.00 0.00
OR: 47.56 27.29
-
Forward Error Correction is presumably disabled when the Framing Parameter 'R' (the number of redundancy bytes in the RS codeword) is set to zero.
Here, for example, R is zero (bytes) in the downstream, and 16 in the upstream.
Consequently no data is being passed to the RS decoder by the CPE modem. This is confirmed by the zero in the downstream column of the RS row.
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 45
R: 0 16
S: 0.0955 0.3782
L: 20104 5373
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 123346 47730
OHFErr: 0 0
RS: 0 2147351
RSCorr: 0 0
RSUnCorr: 0 0
..
Path 0
INP: 0.00 0.00
PER: 1.64 4.25
delay: 0.00 0.00
OR: 116.54 60.17
..
cheers, a
Edit: from an earlier post:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F12681785%2F1024%2Fframer-parameters%2Fframerparams-broadcom.png&hash=acb085e18abfe581b38da365b480fad952e06206)
-
interesting finds then Asbo...
other than the user not being able to read the errors....are there any other repercussions of the 6368 chipset not recording these stats?
-
Hi Snadge, the DSLAM has the error counts, so no biggie in terms of VDSL2 performance. Not sure why it's omitted.
cheers, a