Kitz Forum
Broadband Related => ADSL Issues => Topic started by: burakkucat on January 03, 2019, 10:37:05 PM
-
I wonder if the more analytical of our members would be able to interpret the following statistics, harvested from a ZyXEL VMG1312-B10A that is acting as the CPE on a long metallic pathway, and is configured to operate only in ADSL2 (ITU-T G.992.3) mode. In particular, do the error counts hint at any possible problem? :-\
> xdslctl info --show
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 417 Kbps, Downstream rate = 3428 Kbps
Bearer: 0, Upstream rate = 445 Kbps, Downstream rate = 3082 Kbps
Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.1 5.8
Attn(dB): 64.0 40.3
Pwr(dBm): 18.2 12.4
ADSL2 framing
Bearer 0
MSGc: 52 14
B: 35 46
M: 4 1
T: 3 1
R: 12 12
S: 1.4717 3.3007
L: 848 143
D: 2 8
Counters
Bearer 0
SF: 64333918 789747
SFErr: 1539 42
RS: 2798525458 999616
RSCorr: 84573 8888395
RSUnCorr: 3343 0
ReXmt: 54454 0
ReXmtCorr: 51851 0
ReXmtUnCorr: 3462 0
Bearer 0
HEC: 3953 39
OCD: 9 0
LCD: 9 0
Total Cells: 3238169092 1089949025
Data Cells: 360612088 43423312
Drop Cells: 0
Bit Errors: 188262 3954
ES: 227 40
SES: 9 0
UAS: 180 180
AS: 1036442
Bearer 0
INP: 26.00 2.50
INPRein: 0.00 0.00
delay: 8 7
PER: 16.00 16.50
OR: 28.99 9.69
AgR: 3097.23 453.88
Bitswap: 259493/261876 38946/38946
-
Hi B*Cat
1st Question - how long is the uptime?
You look as if you are having error bursts with 4% of Errored Seconds being SES... so I'm betting the problem is short lived and repetitive - have you got a ES graph?
I'm having experiments with two lines one of which has an SNR of 3 and the other of 11. There's a surprisingly similar pattern on both lines despite the SNR difference. Your interference may be similar if the uptime is low (and have the same low chance of sussing it out if it is similar :().
-
Is that your line B*cat?
The presence of PhyR caught my eye.
-
Thank you, both, for your comments. :)
No, those harvested statistics do not relate to my circuit . . . but were "pushed under the door of The Cattery" early yesterday morning, with a note asking about the error counts. The only comment I could make was that without details of the relevant time-frame, etc, not a lot could be deduced.
-
The AS figure (Available seconds) indicates an up time of almost exactly 12 days. :)
-
So the error counts are basically not much. Is this one of Weaver's lines?
-
The AS is only the time from the last resync but the accompanying ES/SES numbers are the total uptime.
Either way for at least 12 days (11.995 days) those numbers look great.
Even better if the modem uptime was longer than that.
-
. . . Is this one of Weaver's lines?
b*cat smiles, enigmatically. :)
-
Could someone be kind enough to talk me through the PhyR stats in this? To help me understand them?
-
I'm wondering what is the relevance of it being limited to ADSL2 vs ADSL2+?
I know on my 3-5Mbit line I was always surprised that ADSL2+ performed better when everything online at the time suggested it should have zero benefit on long lines.
-
When I did that I had got the idea from a suggestion by Burakkucat. He thought that forcing a restriction to ADSL2 on a very long line may close the modem to shut its ears to the very high tones used by ADSL2+, thus narrowing the window and letting less noise in. I don’t know whether or not modems do this; it could be that they have the same input subsystem and there is a variable width input filter or the hardware could be identical. I assumed that it couldn’t hurt and so I tried the idea when I first went up to ADSL2 from G.992.1. Indeed the highest tones I can use are way too low for me to lose out on anything by using ADSL2 not ADSL2 A+.
-
Its been a long long time, but I seem to recall I lost some upstream speed if I limited to ADSL2.
But then with it being so long ago, the crosstalk situation is likely VERY different today. The chances of getting those higher frequencies is probably much slimmer than when I last had it.
-
Alex, did you mean to write “if I limited to ADSL2” ?
-
Alex, did you mean to write “if I limited to ADSL2” ?
Why yes, I did.
But thinking back, this was probably when I was on Be Broadband, so could also be why it made a difference back then.
-
One difference which I noticed last night, is that if you have PhyR / G.998.4 / G.INP, for ADSL2 there are differences in the standards compared with ADSL2+ (and VDSL2). See G.998.4 annex A.
For ADSL2, the maximum amount of RAM to be allocated for the ReTX Tx queue in the DSLAM, quoting - "transmit retransmission queue in the CO" - is limited to the half of the downstream interleaver delay in bytes, i.e.: Qtx* Q * H ≤ 8001 bytes". For ADSL2+ this figure can optionally be 12000 bytes instead - see annex B. The maximum value of Q*H is 1024 bytes, but I can’t see all the individual parameters for my modem.
So a constraint on performance is possibly relaxed with ADSL2+, by an implementation option. This will affect the range of patterns of lookback retransmission that can be supported, where a receiver can indicate a NACKed or ACKed DTU way back which is different from its successors. When such a circumstance could practically happen is quite unclear to me, and even the mere possibility is an option.
A more careful look might reveal other differences between ADSL2 and ADSL2+, but I have yet to do all the tedious work.
-
Have you tried any of your lines on ADSL2+?
I'd be interested to see if PhyR remained enabled and if there was any increase in sync.
-
Because PhyR isn't G.998.4, what's in the G.998.4 document isn't necessarily relevant.
As far as I can tell, there are no differences of any significance that make ADSL2+ itself worse than ADSL2 on long lines. The reason that some long lines perform noticeably better on ADSL2 than on ADSL2+ is that the oldest and worst type of exchange equipment (identifiable by vendor code TSTC) is rubbish at doing ADSL2+. It's actually just as bad at doing ADSL2+ on short lines as it is at doing ADSL2+ on long lines, the difference is that you can't fix only getting 16Mb when you should get 19Mb by setting your modem to ADSL2 because ADSL2 is limited to 12Mb. I think any reasoning about noise on higher frequencies somehow making ADSL2+ worse on long lines is entirely spurious.
I'm pretty sure Weaver's lines will be much the same on ADSL2+ as on ADSL2. Any differences in the amount of interleaving memory available will be irrelevant assuming it's constrained by the maximum delay permitted, not the amount of memory.
-
Ejs is wholly unimpressed by Burakkucat’s theory.
I wasn’t suggesting that the differences in the G.998.4 standards might make a practical difference in performance, even less so for me, but I was just interested to note that differences do exist.
I’m interested to learn that PhyR ≠ G.998.4. I had got the wrong idea about this; I had picked up some idea that the two might be practically equal, based on something that I thought Kitz had said, but I probably misread or misremembered.
Btw my exchange as really recent hw installed at the end of 2015, for the 21CN upgrade.
@j0hn If I remember correctly, I ran on ADSL2+ briefly and there was no difference within the statistical noise; had to be careful about resyncing itself causing changes in the sync rate even when no parameters have changed. I once did a group of tests and put all the results in a spreadsheet and I couldn’t make any reliable conclusion out of it, not without a large number of tests.
I’ve attached the results; zip file containing an xlsx file. The original spreadsheet is in iOS Numbers format and I hope the conversion to Excel format hasn’t mangled it up too much. If anyone has any problems I can convert to csv even.
-
It maybe none sense but would ANNEX L on ADSL2 benefit long lines more than ANNEX A?
-
@mofa2020 - Yes, in a way; I would think the benefit would be about the same on long lines, because on my lines the low end frequencies are very good. Clearly on a short line all the bits per bin values are going to be higher so the extra contribution from the additional annex L low bins will be greater. Annex L would be a bigger part of the whole on an ultra long line, because the higher tones are so weak that their bit loading total is small compared to the additional Annex L low bins. Anyway, Annex L would be absolutely wonderful for me.
-
In that group of tests, on two occasions I did a three-way test: adsl2 vs adsl2+ vs "auto". Auto came in the middle, but the tiny sample size, only two tests, is ridiculously small. I should have tried to work out what auto was actually choosing. That would have been interesting. I believe I can see it in the stats. I didn’t have any stats for the DLink modem I was using, so I should have also tested with the ZyXEL too, on which I do have access to stats.
What will a modem do on auto? Does it have a fixed preference or does it do intelligent analysis based on stats obtained?
-
How big do we think a DTU is on your system? I have absolutely no idea. I see the maximum is 1k, but that seems a bit large to me, no? Wouldn’t there be a slight benefit from having smaller DTUs - more likely to succeed, and also a disadvantage which is increased overhead and fewer slots available in the tx queue if running into the limit on total ram vs n slots times size per slot.
-
What will a modem do on auto? Does it have a fixed preference or does it do intelligent analysis based on stats obtained?
I always assumed Auto just means it tries them in order from best to worst until it gets sync. I'd be very surprised if it does anything intelligent.
-
Just out of interest I was going to compare ADSL2 vs ADSL2+ on my line, from memory performance all seemed to be the same with the only difference being the reported attenuation. Oddly, today if I enable ADSL2+ the line will not sync. Disable it and it returns to normal.
-
By the way, does anyone know how modems auto-discover which protocols are available at the other end and negotiate or go through in some order or preference ? - possibly with certain things knocked out of the list of permitted alternatives.
Is there a standard for multi-protocol negotiation? I can’t look in say G.992.3 say, can I ? Perhaps there’s something in the original G.992.1 which gives at least a clue.
-
I have always assumed that if "all" is specified in the protocol list, a modem will try the most "advanced" protocol first and if synchronisation is not achieved will then work down the list in a stepwise fashion.
I.e. VDSL2, ADSL2+, ADSL2, ADSL (or, if you prefer it, G.993.2, G.992.5, G.992.3, G.992.1).
-
How do you ask the other end if it can handle the protocols? Do you try one and let it fail if objected to? Or is there some exchange of protocol-dentifying information so you don’t have to try and then fail?
I don’t even know if it’s possible to speed up the process by tweaking the allowed list and paring it down.
-
Recommendation ITU-T G.994.1 provides a flexible mechanism for digital subscriber line (DSL)
transceivers to exchange capabilities and to select a common mode of operation.
-
Just out of interest I was going to compare ADSL2 vs ADSL2+ on my line, from memory performance all seemed to be the same with the only difference being the reported attenuation. Oddly, today if I enable ADSL2+ the line will not sync. Disable it and it returns to normal.
If I recall correctly, I think my upstream was considerably higher on ADSL2+ vs ADSL2. Line is somewhere between 2-3kM.