Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Tacitus on May 25, 2017, 10:47:44 AM
-
Is it possible to tell from the stats below whether I've been put on a banded profile? I'm currently on a capped 40mbps service which has been solid for ages but last week for some reason went haywire with the sync dropping to around 35Mbps and pings all over the place. It seems to have recovered as FECs are well down but is still well below what it was.
The current BBMonitor is here:
[url]https://www.thinkbroadband.com/broadband/monitoring/quality/share/b9a68d71b8f1a0a781e3b97ac9222f239e8fac84-25-05-2017/url]
Max attainable has hardly changed and is still around the 58 mark so I don't see why the sync speed should have dropped so much.
Modem is a Zyxel (Broadcom) some 1/4-1/2 mile from a Huawei 288 cabinet.
============================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
Traffic Type: PTM Mode
Link Uptime: 0 day: 20 hours: 56 minutes
============================================================================
VDSL Port Details Upstream Downstream
Line Rate: 10.057 Mbps 34.998 Mbps
Actual Net Data Rate: 9.999 Mbps 34.999 Mbps
Trellis Coding: ON ON
SNR Margin: 8.5 dB 13.5 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 7.6 dBm 13.7 dBm
Receive Power: -6.9 dBm -5.7 dBm
Actual INP: 0.0 symbols 52.0 symbols
Total Attenuation: 0.0 dB 19.1 dB
Attainable Net Data Rate: 12.727 Mbps 57.354 Mbps
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 6.9 29.0 42.8 N/A 14.0 34.4 55.1
Signal Attenuation(dB): 6.9 28.6 42.6 N/A 17.2 34.1 55.1
SNR Margin(dB): 8.6 8.5 8.5 N/A 13.5 13.5 13.6
Transmit Power(dBm):- 0.1 -14.0 6.6 N/A 11.4 7.8 5.5
============================================================================
VDSL Counters
Downstream Upstream
Since Link time = 56 min 59 sec
FEC: 9190 144
CRC: 0 44
ES: 0 38
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 2 sec
FEC: 33 1
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 32 1
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 10 hours 25 min 2 sec
FEC: 2680 66
CRC: 0 20
ES: 0 18
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 10606 413
CRC: 1163 98
ES: 21 88
SES: 20 0
UAS: 78 58
LOS: 1 0
LOF: 7 0
LOM: 0 0
Total time = 1 days 10 hours 25 min 2 sec
FEC: 13286 479
CRC: 1163 118
ES: 21 106
SES: 20 0
UAS: 78 58
LOS: 1 0
LOF: 7 0
LOM: 0 0
============================================================================
-
Yep, looks like you have been banded. If you are on a 40M service anyway you won't tell the difference.
-
Yep, looks like you have been banded. If you are on a 40M service anyway you won't tell the difference.
Thanks for the reply. I agree that in practical terms there is little to no difference but I'm curious. Sorry for all the questions but my technical knowledge of VDSL/Fibre and the machinations of OpenReach is limited. :)
Which of the figures tells you that I'm on banding?
What are the implications? Will this be removed in time or am I stuck with it? Are there several banded profiles going down to (say) 5Mbps as the line deteriorates further?
Why does the maximum attainable stay more or less the same, whilst the sync speed goes down? Surely if the problem is noise/errors etc the max attainable should go down as well.
Thanks for any help.
-
The actual data rate of an exact figure (well 34.999) of one of the band boundaries rather than a random figure is the clue. See https://community.plus.net/t5/Library/FTTC-DLM-What-it-is-How-it-works/ba-p/1322799 for the band profiles. If whatever caused the problem has now gone away, your line should eventually recover to its previous figure although DLM doesn't always relent and remove banding.
-
The actual data rate of an exact figure (well 34.999) of one of the band boundaries rather than a random figure is the clue. See https://community.plus.net/t5/Library/FTTC-DLM-What-it-is-How-it-works/ba-p/1322799 for the band profiles. If whatever caused the problem has now gone away, your line should eventually recover to its previous figure although DLM doesn't always relent and remove banding.
Useful link thanks. Does DLM apply interleaving as well as banding and how do I tell? IE both at the same time or is it one or the other.
-
DLM applies Interleaving and G.Inp as well as banding. Banding is a last resort and only usually happens after a severe burst of disturbance. Have a look at http://dslstats.me.uk/index.html to obtain extra stats and graphs from your router as the stats you have posted show G.Inp but not Interleaving depth.
-
The DLM applies retransmission (G.INP) or interleaving.
The minor levels of interleaving/FEC associated with retransmission on Huawei cabinets are not particularly significant. Retransmission requires maintaining a queue of data in memory, as does interleaving, equipment can't do significant levels of interleaving and retransmission at the same time.
-
Have a look at http://dslstats.me.uk/index.html to obtain extra stats and graphs from your router as the stats you have posted show G.Inp but not Interleaving depth.
I shall have to fire up the Windows machine to use that as I'm Mac based. For some reason I can't login via telnet otherwise I could use 'show VDSL' which I think is the correct command.
-
If you do manage to telnet in, at the ATP> prompt type sh for a shell. At the shell prompt the command is xdslcmd info --show I think the interleave depth is the Bearer0 D: figure, but I'm sure somebody will correct me if I'm wrong.
-
If you do manage to telnet in, at the ATP> prompt type sh for a shell. At the shell prompt the command is xdslcmd info --show I think the interleave depth is the Bearer0 D: figure, but I'm sure somebody will correct me if I'm wrong.
Thanks. I've managed to get so far in and it's obviously connected to the Zyxel, but it accepts the username and simply locks up when I try to put in the password. I've looked at the admin stuff via the browser and can't see any reason why it should reject access via telnet.
Shame as telnet has been quite useful with routers in the past.
I have got an old Windows box running XP (it's that old) so I might dig it out just for this unless DSLStats is Win7 and up. If that's the case I'm stuffed.
-
You didn't say what model of Zyxel it is, but any models with recent firmware only permit a single telnet access at any one time. Is it possible that you have some other device connecting by telnet, or maybe a zombie access which didn't clear properly? These things aside, there is normally no problem accessing the data by telnet. The advice given above isn't correct for Zyxel - it applies to the HG612. With the Zyxels you should only need to enter name and password to gain access to the CLI. The command to get the main stats is
adsl info --stats
or
xdslctl info --stats
-
You didn't say what model of Zyxel it is, but any models with recent firmware only permit a single telnet access at any one time. Is it possible that you have some other device connecting by telnet, or maybe a zombie access which didn't clear properly? These things aside, there is normally no problem accessing the data by telnet. The advice given above isn't correct for Zyxel - it applies to the HG612. With the Zyxels you should only need to enter name and password to gain access to the CLI. The command to get the main stats isadsl info --stats
or
xdslctl info --stats
Unlikely I have any other telnet instances since the router (Zyxel SBG 3300) is locked to one IP address for admin purposes. Nonetheless I went through the list of processes and can't find any. I think the problem might be computer related although I can't fathom why. This is what I get after logging into the shell as admin:
Trying 10.0.1.0...
Connected to 10.0.1.0.
Escape character is '^]'.
ZyXEL SBG3300
Login: ****
Password:
Then it refuses to accept any further input, but eventually produces the following:
telnetd:error:59.557:lck_checkBeforeEntry:171:lock required during cmsObj_get
telnetd:error:59.558:rut_isAdvancedAccountSecurity:1589:get of LOGIN_CFG failed, ret=9807
telnetd:error:59.559:lck_checkBeforeEntry:171:lock required during cmsObj_getNextInSubTreeFlags
No idea whether these are MacOS or Zyxel error codes - a quick Google didn't produce anything meaningful. Used telnet in the past with both Draytek and Zyxel routers with absolutely no problem.
-
telnetd:error:59.557:lck_checkBeforeEntry:171:lock required during cmsObj_get
telnetd:error:59.558:rut_isAdvancedAccountSecurity:1589:get of LOGIN_CFG failed, ret=9807
telnetd:error:59.559:lck_checkBeforeEntry:171:lock required during cmsObj_getNextInSubTreeFlags
'telnetd' is likely to be the server (daemon) process on the ZyXel, rather than the client on the Mac.
-
I'm not familiar with this model, but is there a particular reason why you're using the IP address 10.0.1.0? The default IP address is 192.168.1.1, and the login name and password are the usual admin and 1234. 10.0.1.0 may have different login credentials. If I'm talking through my hat then please tell me to go away.
-
I'm not familiar with this model, but is there a particular reason why you're using the IP address 10.0.1.0? The default IP address is 192.168.1.1, and the login name and password are the usual admin and 1234. 10.0.1.0 may have different login credentials. If I'm talking through my hat then please tell me to go away.
Once I'd done the initial login with admin/1234 etc I decided to alter it to 10.0.1.0 as that's the LAN my other stuff was on. I think using that range also stems from the days when I regularly used a VPN to login to home and the need for both ends to be on different ranges. OK there are other ways but that's the choice I made at the time.
Don't think that's the problem but I've not previously tried using telnet with this router. It worked OK with previous ones, but it's an interesting point.
Easier to continue than to alter everything else as some things are on fixed IP with the DHCP element on a higher range. EG DHCP starts at 10.0.1.50 some other things are on fixed but below that range. OK the DHCP elements are effectively fixed since I do MAC binding, but still.
TBH I think it might be a good idea to start again with a more logical setup based entirely on DHCP and MAC binding. When this router bails out, I'll probably do that :)
-
Some modems / routers you have to turn on Telnet !.
You could use a web browser to check the settings page..
-
At the telnet password prompt...just type the password then press enter. There may be no Astrix or no characters shown...just type the password then press enter..
Ian
-
Some modems / routers you have to turn on Telnet !.
You could use a web browser to check the settings page..
Yes you can turn on/off telnet on the 3300. I checked via the browser and it's switched on with the proviso that it's accessed from a single IP which is the machine I use for admin tasks. I checked just in case I'd mucked up the Ips somewhere...
At the telnet password prompt...just type the password then press enter. There may be no Astrix or no characters shown...just type the password then press enter.
Ian
Tried that as well. Basically there is no response.
As I said I've not had a problem with telnet and other routers so I really can't fathom what's happening here. However, I've got most of what I need from the browser interface so maybe leave it for the time being as everything seems to have settled down.
-
Looks as though DLM has relented and I'm back up to 39,999 (capped 40mbps).
My Broadband Ping (https://www.thinkbroadband.com/broadband/monitoring/quality/share/da2e5bb26bdb1ba2af4a08f2985229c3ff1642ca-01-06-2017)
A drop in connection at around 8:15am suggests something may have been done at the cabinet, although the high ES around that time may have forced the reconnect. If the latter was the case I would have expected DLM to either maintain or lower the connection speed.
Still all is currently OK, until the next bout of instability.... :(
============================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
Traffic Type: PTM Mode
Link Uptime: 0 day: 23 hours: 55 minutes
============================================================================
VDSL Port Details Upstream Downstream
Line Rate: 10.057 Mbps 39.998 Mbps
Actual Net Data Rate: 9.999 Mbps 39.999 Mbps
Trellis Coding: ON ON
SNR Margin: 8.4 dB 11.1 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 7.4 dBm 13.9 dBm
Receive Power: -6.3 dBm -5.3 dBm
Actual INP: 0.0 symbols 52.0 symbols
Total Attenuation: 0.0 dB 19.0 dB
Attainable Net Data Rate: 12.770 Mbps 56.542 Mbps
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 7.0 29.2 43.2 N/A 13.8 34.5 55.4
Signal Attenuation(dB): 7.0 28.7 42.5 N/A 17.0 34.2 55.4
SNR Margin(dB): 8.5 8.4 8.4 N/A 11.1 11.1 10.9
Transmit Power(dBm): 0.6 -14.1 6.5 N/A 11.6 8.1 5.5
============================================================================
VDSL Counters
Downstream Upstream
Since Link time = 55 min 25 sec
FEC: 12320 157
CRC: 0 33
ES: 0 31
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 13 min 51 sec
FEC: 79 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 45 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 13 min 51 sec
FEC: 79 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 12357 158
CRC: 534 33
ES: 10 31
SES: 10 0
UAS: 37 27
LOS: 1 0
LOF: 7 0
LOM: 0 0
Total time = 1 days 13 min 51 sec
FEC: 123675 8300
CRC: 1699 437
ES: 32 404
SES: 30 0
UAS: 115 85
LOS: 2 0
LOF: 14 0
LOM: 0 0
======================================
-
Looks as though DLM has relented and I'm back up to 39,999 (capped 40mbps).
My Broadband Ping (https://www.thinkbroadband.com/broadband/monitoring/quality/share/da2e5bb26bdb1ba2af4a08f2985229c3ff1642ca-01-06-2017)
A drop in connection at around 8:15am suggests something may have been done at the cabinet, although the high ES around that time may have forced the reconnect. If the latter was the case I would have expected DLM to either maintain or lower the connection speed.
:) :) That would be DLM re-syncing your line.
-
:) :) That would be DLM re-syncing your line.
The high ES and CRCs around that time made me wonder if that was the case but I try to be optimistic and hope someone has done some work to improve the line, which is around 60 years old. :)
At least the move to fibre should have by-passed the long length of aluminium through the village.
-
At least the move to fibre should have by-passed the long length of aluminium through the village.
I very much doubt it, I would expect the aluminium will be on the 'D' side of the cab, not the 'E' side.
-
At least the move to fibre should have by-passed the long length of aluminium through the village.
I very much doubt it, I would expect the aluminium will be on the 'D' side of the cab, not the 'E' side.
To be fair ..... it's 50/50 whether the Ali is on the E or D side cable, or indeed both ?? Flip of a coin, Licq. ;) :)
-
Interesting, didn't think Ali was ever used on the E side. Thanks for the clarification.
-
Yeah ...... quite abundant to be honest. Obviously I personally could never equate the amounts ...... but I would humbly suggest there is as much Ali on the E-side cable make-ups, as there is on the D-side builds. :)
-
At least the move to fibre should have by-passed the long length of aluminium through the village.
I very much doubt it, I would expect the aluminium will be on the 'D' side of the cab, not the 'E' side.
Could be totally wrong of course, but older residents tell me that apart from some 'patching' (their word) nothing much has been done between me and the cabinet. One of the BT guys who came to fix a neighbour's broadband said there was a long length of aluminium through the village, which correlates with what I've been told about work done during the early 70s when copper prices were high.
-
Precisely, thats what I meant. If the Ali is between you and the cabinet, you will still be using it. The fibre only replaces the cable between the cabinet and the exchange.
-
You guys are obviously more knowledgeable than me so could someone tell me the significance of:
Actual INP: 0.0 symbols 52.0 symbols
There must have been another resync around 9pm last night which suggests the probs may be due to crosstalk but the new reading is:
Actual INP: 0.0 symbols 47.0 symbols
which until recently was the long term figure. What is the significance of the drop in the number of symbols? Does it mean that G.INP is no longer working as hard to stabilise the line?
-
What is the significance of the drop in the number of symbols? Does it mean that G.INP is no longer working as hard to stabilise the line?
In technical terms, the number represents DLM's requirements on the choices made by the modem at sync time. Here it is asking for noise protection to cope with a burst of noise (SHINE rather than REIN) that lasts for 47 symbols.
DSL works at 4,000 symbols per second, so 47 offers protection against a noise burst lasting 12ms. 52 isn't much different: 13ms.
With retransmission, "protection against a noise burst" means: The modem has to set up retransmission so that it can store all of the transmitted blocks for at least 12ms, and then be able to retransmit them after the far end reports they all went missing. On top of that, given that re-transmission usually happens within 1ms of the loss being noticed (or so I understand), it also requires settings to allow blocks to be re-re-transmitted a fair number of times.
The shift from 52 to 47 probably does mean the modem is working slightly less hard. Less memory seems certain.
I guess it also means the maximum jitter that G.INP can introduce is 12ms too.
-
In technical terms, the number represents DLM's requirements on the choices made by the modem at sync time...... [ SNIP]
Thanks for the explanation.Very helpful :)
-
Sorry to resurrect this thread but at long last I've managed to get telnet working and got some info, albeit of little use. However, what is the significance of "Bearer: 0 and Bearer 1"?
> xdslctl info
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 12699 Kbps, Downstream rate = 58673 Kbps
Bearer: 0, Upstream rate = 9999 Kbps, Downstream rate = 40000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
>
There's actually less info here than I get from the web interface. :(
-
Try
xdslctl info --stats
which should give you the full set of stats.
Bearer 0 is the actual data carrier, bearer 1 is the retransmission data carrier (G.Inp).
-
Bearer 0 is the actual data carrier, bearer 1 is the retransmission data carrier (G.Inp).
This seems to be a common misconception. Without retransmission, the overhead management messages, used for things like sending stats to the equipment at the other end, and organising bitswaps, are mixed in with the data in bearer 0. With retransmission, the data is sent over bearer 0 (the first time and if it gets retransmitted), and those general management messages are separated into bearer 1. Bearer 1 appears when retransmission is on, but it does not carry retransmitted data blocks.
-
I stand corrected.
-
That worked :) Bit long but any comments would be appreciated.
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 12696 Kbps, Downstream rate = 57816 Kbps
Bearer: 0, Upstream rate = 9999 Kbps, Downstream rate = 40000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 11.8 8.5
Attn(dB): 19.0 0.0
Pwr(dBm): 13.7 7.5
VDSL2 framing
Bearer 0
MSGc: -6 58
B: 178 236
M: 1 1
T: 0 23
R: 12 16
S: 0.1424 0.7543
L: 10727 2694
D: 16 1
I: 191 127
N: 191 254
Q: 16 0
V: 2 0
RxQueue: 22 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 1788340
OHFErr: 104 445
RS: 2419588256 3823605
RSCorr: 1501611151 10138
RSUnCorr: 0 0
Bearer 1
OHF: 53181696 0
OHFErr: 0 0
RS: 319089806 0
RSCorr: 37 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 905902041 0
rtx_c: 53889 0
rtx_uc: 323774 0
G.INP Counters
LEFTRS: 394 0
minEFTR: 39991 0
errFreeBits: 2434381182 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1246015147 0
Data Cells: 624931657 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 90 843
SES: 60 0
UAS: 200 140
AS: 854369
Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 8.70
OR: 0.01 58.79
AgR: 40055.74 10057.90
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 41540/41572 11853/11856
Total time = 20 days 10 hours 18 min 46 sec
FEC: 1515682347 18514
CRC: 3479 903
ES: 90 843
SES: 60 0
UAS: 200 140
LOS: 4 0
LOF: 32 0
LOM: 0 0
Latest 15 minutes time = 3 min 46 sec
FEC: 5685603 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 22547276 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 10 hours 18 min 46 sec
FEC: 927666459 268
CRC: 100 67
ES: 25 61
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 9 days 21 hours 19 min 29 sec
FEC: 1501611151 10138
CRC: 104 445
ES: 27 418
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>