Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Weaver on April 29, 2018, 02:33:15 PM
-
This morning I gathered some stats on the differences between ADSL2+ mode and ADSL2 mode on one of my lines with a DLink DSL-320B-Z1 modem.
Thanks to a suggestion from Burakkucat I was alerted to the possibility that locking the modem to choose ADSL2 rather than ADSL2+ might be a better setting for my ultra long lines (~65dB d/s attn; 4.55mi long).
These are the results using one modem on one line only, my line #1.
ds sync / us sync
2595 / -- auto mode; no bitswap!
2784 / -- adsl2; bitswap
2804 / -- auto
2827 / -- adsl2
ds sync / us sync / ds snrm
2795 / 557 2.8 adsl2+
2819 / 553 2.8 auto
2830 / 553 2.3 adsl2
2791 / 553 3.1 adsl2+
2848 / 553 2.1 adsl2
2848 / 553 -- adsl2; [ no bitswap!]
2823 / 553 3.0 adsl2
2809 / 553 3.1 adsl2
2784 / 550 3.0 adsl2
2770 / 553 3.3 adsl2+
2827 / 550 3.0 adsl2
Note that ‘auto’ means auto-select mode where the modem chose who-knows what mode itself.
Geometric means of the above are, approx, -
auto = 2811.5
adsl2+ = 2785.3
adsl2 = 2819.9
-
And the winner is . . . (http://www.centos.toracat.org/ajb/tmp/bounce04.gif)
-
Have you been at the magic mushrooms again? ;D
-
No, just the cat-mint. ;)
-
It's so very slight, but tentatively Burakkucat possibly wins from those stats. Adsl2 is possibly very slightly better than adsl2+.
If auto actually really means adsl2 in practice, and it never goes to ADSL1 by choice (which would be very surprising, but I can't prove it) then I could lump in the auto results too which would improve the picture in favour of ADSL2.
I need some advice on statistics to know what the significance of this very small data set is. There have not been enough tests done, certainly not enough runs with adsl2+.
Mrs Weaver was wanting to go off and do other things and was waiting around for me to give her the go-ahead to plug the test modem back into the router as normal, instead of it being straight into the main LAN switch (where I could interrogate it) temporarily.
So the current advice is to definitely follow Burrakucat’s wisdom, because it is not disadvantageous, there's no evidence that it is. How long your line has to be though is unknown. You always have to check on the tone spectrum for safety’s sake.
If I had had any wit, I would have captured some stats from the modem to show anyone who might be interested in seeing a ridiculously long but I suspect clean line.
The stats from the modem’s http output are not very detailed. Not as good as many. I haven't tried telnet into it yet, there was a superb earlier thread on this modem which I need to re-read.
-
I have a Netgear DG834Gv5 stored away in "The Grotto". I first used it with my TalkTalk connection, when that service was provided by 20CN equipment, in G.992.1 mode . . . the device was configured in "auto" mode. When TT upgraded their equipment to 21CN, the DG834G, left in "auto" mode, then connected in G.992.5 mode . . . poorly. (Without getting it out, powering it up and checking, I believe it can only be configured as either "G.Dmt" or "auto". Not G.992.3 mode.)
I then used a 2Wire 2700HGV for some time. That device would first attempt to connect in G.992.5 mode, analyse the training response and re-try in G.992.3 mode. The latter mode it found to be viable and so did not take the final step downwards to G.992.1 mode. The 2Wire device also displayed the bit loading per sub-carrier and it was quite clear that nothing in the sub-carrier range of 256 to 511 was being used.
Hence when I finally started to use devices that were fully configurable (initially Huawei HG6xx devices, latterly ZyXEL VMG1312-B10x devices), I have always manually selected G.992.3 mode.
-
And Burakkucat’s line is rather faster than mine at 2.7-2.9 Mbps d/s sync , so if his bins / tones don't go high enough, then mine certainly won't.
One line, cwcc@a.4 is slightly faster downstream btw, at least most of the time.
But for some reason the line tested here, cwcc@a.1 is always the fastest upstream by a sizeable amount, the upstream differences being a long-standing mystery. (I can't even cook up any candidate theories for why.)
One other problem with the weak statistics of these tentative results is the variation in the SNRM. The reported figures might well just be strongly correlated with the sync speed. In that case, the question is, what about the variations in SNRM within one mode? (where say lower SNRM is linked with higher sync rate.)
The results presented are in time order. One bizarre outlier, at 200k d/s sync below the normal range was stripped from the dataset in calculating the derived statistics as an anomaly. It was perhaps to do with its being the very first result obtained (soon) after power loss, or perhaps after upsetting BT somehow.
If anyone speaks stats I would appreciate some help. Utterly ashamed to say never got my head around the subject properly, but amazingly Theoretical Physics students at my place never got a course on the subject (well perhaps that is for the experimental lot).
-
On this type of exchange equipment, I expect auto will connect using ADSL2+. This is the type of exchange equipment where the difference between ADSL2 and ADSL2+ is very small. I think the difference is greater on the older (TSTC) exchange equipment.
-
On this type of exchange equipment, I expect auto will connect using ADSL2+. This is the type of exchange equipment where the difference between ADSL2 and ADSL2+ is very small. I think the difference is greater on the older (TSTC) exchange equipment.
Nods in agreement.
And it would always be worthwhile, initially, to monitor the circuit to determine the active sub-carrier range.
-
I re-read some stuff from the old thread that was generously contributed by user G.DMT (what a star!). I haven't been able to see how to look up bits-per-bin assignments.
-
Interesting that the 4.5 mile upstream rate on ADSL2 is actually slightly faster than what I get on my 1.3 mile FTTC link!
I get 15M down and 530k up from an ECI cabinet. I’m hoping that the new firmware for G.INP (when it finally gets released) fixes this somehow as I’m convinced it’s a bug of some kind.
-
I have a Netgear DG834Gv5 stored away in "The Grotto". I first used it with my TalkTalk connection, when that service was provided by 20CN equipment, in G.992.1 mode . . . the device was configured in "auto" mode. When TT upgraded their equipment to 21CN, the DG834G, left in "auto" mode, then connected in G.992.5 mode . . . poorly. (Without getting it out, powering it up and checking, I believe it can only be configured as either "G.Dmt" or "auto". Not G.992.3 mode.)
If I can recall correctly, the Netgear DG834Gv5 was the worst out of all the DG834Gs (it had Conexant chipset). v4 was by far the best (Broadcom BCM6348S), and tweakable in debug mode with custom firmware available (DGTeam). The v1, v2 and v3 (Texas Instruments) were apparently OK (I know the v3 was quite solid) while not tweakable, did have custom firmware (I know v3 did).
-
I used a Netgear DG834v4 on good lines and found it to be great but never tested one on my own ultra-long line, and that would have been the real serious test. I have never used any of the with-wireless ones.
I used the v1-v3 on my own long line and especially the v3 was utterly superb. It synced high, was ultra aggressive with low snrm and hung on really well with very few resynchs. The v2 and v3 were a little better than the v1 I think.
-
If I can recall correctly, the Netgear DG834Gv5 was the worst out of all the DG834Gs (it had Conexant chipset).
You do, indeed, remember correctly. :)
Conexant :yuck:
-
I used the v1-v3 on my own long line and especially the v3 was utterly superb. It synced high, was ultra aggressive with low snrm and hung on really well with very few resynchs.
I think the v3 sync'd a bit lower for myself, but it was probably just as stable as the v4. Texas Instruments chipsets weren't actually that bad from the limited sample I had. In fact, in some cases I would say pretty much on par with Broadcom.
Conexant :yuck:
My thoughts exactly. Probably comparable to MediaTek. ;D Can't say I've used either the v5 or a MediaTek-based modem, but Infineon chipsets that were used in some of the TalkTalk modem-router combos (D-Link, AFAIK) back in the ADSL days were certainly bad enough (at least on my line).
-
For some reason though I have had a very good experience with a huge pile of MediaTek / Trendchip modems in my DLinks. I'm using these as modems only, not as routers so maybe I am not seeing some of the software nasties, my line is long and slow but I think ultra-clean, and also no VDSL2 so those could be reasons why my experience might be different.
-
[off topic]
My thoughts exactly. Probably comparable to MediaTek. ;D Can't say I've used either the v5 or a MediaTek-based modem, but Infineon chipsets that were used in some of the TalkTalk modem-router combos (D-Link, AFAIK) back in the ADSL days were certainly bad enough (at least on my line).
Conexant (https://en.wikipedia.org/wiki/Conexant), Infineon (https://en.wikipedia.org/wiki/Infineon_Technologies) and Lantiq (https://en.wikipedia.org/wiki/Lantiq) are all on a "To Avoid" list that is maintained in "The Cattery". :-X
[/off topic]
-
I did some tests now on line cwcc@a.1 with a ZyXEL VMG 1312-B10A modem -
Settings were:
- PhyR down = on, up = on (suspect it is really on too, for downstream; poss not on for upstream)
- SRA = on (supposedly; 'allowed' at least)
- bitswap = on
Sync rates (kbps):
G.992.5 | | | G.992.3 |
down | up | | down | up |
3034 | ? | | 3134 | 519 |
3103 | 515 | | 3066 | 515 |
3085 | 519 | | 3081 | 515 |
3085 | 519 | | 3060 | 512 |
| | | 3085 | 515 |
| | | 3081 | 519 |
| | | 3081 | 519 |
So very little in it, but a paltry amount of data for decent statistics I am ashamed to say.
-
Interesting results, thanks Weaver.
-
Btw these are all with downstream target SNRM set by AA to 3dB and actual downstream SNRM is about that too. Upstream target SNRM is 6dB and actual value matches that.
A few other points. The data doesn't point this out but it is clear that with this modem the sync rates (even the downstream) doesn't just go up and down for the hell of it, because of DLM mucking about or something. If you just reboot the modem and don't change any parameters at all then it tends to come up with the same sync rate it had before, so it's very consistent and this has not always been the case.
In the past there has been a lot of statistical ‘noise’ in these kind of sync rate stats, for reasons unknown. It could have been somehow linked to the downstream sync rate drooping, starting well below the downstream target SNRM and then sometimes going down further then yo-yoing. That doesn't happen any more either. Even on a 3dB downstream target SNRM the number seem a lot more consistent and healthy. The instantaneous downstream sync rates quoted for the DLink DSL-320B-Z1 modems in the past were at anything from ~0.6dB - 2.5 dB and rarely as high as an actual 3dB.
Coming back to the present, there does not seem to be much variation between sync rate achieved after a resynch performed at night time vs in the day time.
The bits per bin spectrum of the ZyXEL has some of the holes missing compared with the measurements taken with DLinks on two lines (although the line used in the ZyXel measurement is neither of those lines used with the DLinks, so not quite a completely fair comparison). It has a much longer tail at the top end, with a lot of values being 1 bit higher and there are a lot of 1-bit bins at the very top whereas there are no 1-bit bins with the DLinks almost as if they were not doing them 1-bit to a lack of such capabilities, or else a policy, almost like it thinks it is G.992.1. But who knows it could just be something to do with noise levels on those bins and bitswap decisions especially if the DLinks do not have monitored tones? Anyway, some of this might be related to why the thing seems to differ less between daytime and nighttime. I seem to remember reading something or other that mentioned an (analog?) filter, at the front end, maybe a higher-quality more expensive AFE on the B10A compared to some of the other competitor devices. Maybe better noise filtering means more resilience to RF ingress and that could help at night?
-
PhyR down = on, up = on (suspect it is really on too, for downstream; poss not on for upstream)
PhyR (AKA G.INP) is not enabled on ADSL connections for any direction on any wholesale platform in the UK AFAIK.
SRA = on (supposedly; 'allowed' at least)
Seamless Rate Adaption is also not enabled for ADSL connections.
Essentially, the settings above won't do anything - but regardless of whether they're on or off it should not have any performance impact as they will not be utilised when the connection is negotiated.
-
The reason I thought PhyR was working is that there was a sizeable PhyR event count value for downstream.
-
Then all I can say is "pass". I am not aware of any major ISP offering ADSL with LLU presence having PhyR enabled. That doesn't mean that it doesn't exist, but I am not aware and cannot find any significant information to prove or disprove this. I am almost certain that connections on BTW do not have it.
Would be interesting to see your statistics, if you are able to provide the information from the CLI using: adsl info --stats
If I am not mistaken, you should have two bearers (0 and 1, though the latter will be 0 kbps for both directions). You should also have an INP figure.
-
PhyR (AKA G.INP) is not enabled on ADSL connections for any direction on any wholesale platform in the UK AFAIK.
It is.
It is also not aka G.INP
PhyR is Broadcoms own proprietary invention. It was then standardised by the ITU as G.998.4/G.INP
You can only have PhyR with Broadcom modem to Broadcom DSLAM.
I am almost certain that connections on BTW do not have it.
The opposite. Only fairly new BT 21CN equipment seems to use this.
Sky also have G.INP on ADSL, but that's actual G.INP, not PhyR.
Weaver, have you checked the stats and double checked PhyR is on and working on both ADSL2 and ADSL2+?
Would be interesting to see your statistics, if you are able to provide the information from the CLI using
You can see his PhyR here
https://forum.kitz.co.uk/index.php/topic,21513.msg372354.html#msg372354
-
I was not intending on spreading misinformation. So I am glad you pointed out errors in my post, j0hn.
We think this is now Broadcom talking to Broadcom at the NSBFD exchange.
I do not know if you have checked or mentioned the vendor before, buit perhaps you could confirm with:
adsl info --vendor
Perhaps a pointless experiment, since there is no reason why it won't return BDCM.
-
Only fairly new BT 21CN equipment seems to use this.
Sky also have G.INP on ADSL, but that's actual G.INP, not PhyR.
G.INP works with G.992.3, G992.5, G993.2 & G.993.5 and iirc only works on the downstream direction for adsl2/adsl2+
-
Fyi - do we think that indicates the presence of Broadcom PhyR active? It is a relatively new MSAN installed 2015-12 at NSBFD
VMG1312-B10A
Login: admin
Password:
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 430 Kbps, Downstream rate = 3360 Kbps
Bearer: 0, Upstream rate = 515 Kbps, Downstream rate = 3052 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.0 5.8
Attn(dB): 65.0 41.0
Pwr(dBm): 18.4 12.4
ADSL2 framing
Bearer 0
MSGc: 52 11
B: 35 62
M: 4 1
T: 3 1
R: 10 12
S: 1.4861 3.8462
L: 829 156
D: 2 8
Counters
Bearer 0
SF: 4572161 445221
SFErr: 6 59
RS: 198889038 51454
RSCorr: 1004 6954
RSUnCorr: 26 0
ReXmt: 920 0
ReXmtCorr: 851 0
ReXmtUnCorr: 27 0
Bearer 0
HEC: 31 107
OCD: 0 0
LCD: 0 0
Total Cells: 535374229 90480196
Data Cells: 4314082 1084725
Drop Cells: 0
Bit Errors: 978 13038
ES: 3 39
SES: 0 0
UAS: 48 48
AS: 74387
Bearer 0
INP: 26.00 2.00
INPRein: 0.00 0.00
delay: 8 8
PER: 16.16 16.34
OR: 28.70 8.32
AgR: 3067.16 522.12
Bitswap: 13620/13748 37/37
Total time = 20 hours 40 min 35 sec
FEC: 1004 6954
CRC: 6 59
ES: 3 39
SES: 0 0
UAS: 48 48
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 35 sec
FEC: 33 140
CRC: 0 2
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 20 35
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 = 20 hours 40 min 35 sec
FEC: 1004 6954
CRC: 6 59
ES: 3 39
SES: 0 0
UAS: 48 48
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 20 hours 39 min 45 sec
FEC: 1004 6954
CRC: 6 59
ES: 3 39
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
and
> adsl info --vendor
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 430 Kbps, Downstream rate = 3372 Kbps
Bearer: 0, Upstream rate = 515 Kbps, Downstream rate = 3052 Kbps
ChipSet Vendor Id: BDCM:0xa3a7
ChipSet VersionNumber: 0xa3a7
ChipSet SerialNumber:
-
I've been a long term advocate that adsl2 may work better on long lines rather than adsl2+ and I believe I may have been one of the first to start suggesting this dating to when BTw first started using adsl2+.
I recall having a telephone conversation many years ago with Azzaka from Zen about a problematic line which definitely worked better on adsl2 than adsl2+ and adsl and giving him my theory why this was. If Leo was still around he would be able to confirm that after our conversation Zen started recommending adsl2 to EU's on long lines.
Theres a post about this subject here (https://forum.kitz.co.uk/index.php/topic,10163.msg203998.html#msg203998), which also mentions the 2700HGV negotiating adsl2 mode
-
Is it possible that the experiment would benefit from PhyR being disabled? Don't know why I suggest that.
-
I think any apparent difference between ADSL2 and ADSL2+ is not due to any difference between the ADSL2 and ADSL2+ standards, it's entirely due to the type of equipment. The oldest type of ADSL2+ equipment (TSTC) isn't good at ADSL2+, on any length of line, but long lines have a sort of get out by being able to sensibly switch to ADSL2 or even ADSL1.
Long line behaviour:
TSTC: does ADSL2+ badly
IFTN: automatically switches to ADSL2
BDCM: ADSL2 / ADSL2+ makes no difference
You don't often get to clearly see the difference the equipment makes unless someone has two lines to the same place on difference equipment (https://community.plus.net/t5/Broadband/Two-ADSL2-lines-One-significantly-slower-than-the-other/td-p/1426249), or has some sort of protracted fault and manages to get their line switched from one type of equipment to another.
-
Theres a post about this subject here (https://forum.kitz.co.uk/index.php/topic,10163.msg203998.html#msg203998), which also mentions the 2700HGV negotiating adsl2 mode
I followed the link and . . . "That looks familiar." :D