Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Volunteers wanted

(1) Perhaps some other kind kitizen would be good enough to do the ADSL2 vs ADSL2+ comparison test for me? See prev post. (Obviously must have ADSL2+ line, and must be really quite long, say < 4500 d/s sync, but as long as you can get some result.) Must be done in modem-only mode, or both, if you wish to check the behaviour out. UI weirdness possible,

Needs to be done carefully, so the result will be repeatable, so a time-consuming pain of a job. See http://forum.kitz.co.uk/index.php/topic,15905.msg307641.html#msg307641

(2) Similarly volunteers wanted to check the enable-bitswap thing, in modem-only mode.

[G.DMT]

@G.DMT - (rather belated posting) I notice you posted a very impressive d/s sync rate of 4224 considering your high d/s attn (63.5 dB - which we take to be fake seeing as you are running on G.DMT), although your line is not incredibly long. (Mine is 4.55 mi, 7322 m, 21CN ADSL2+, d/s attn. of 65 - 67 dB, d/s sync ~2900 kbps.)

The line seems to be unstable at that high sync rate though, (perhaps needing a load of interleave?) - because of the very bad news >2000 d/s HEC errors. Is it locked into fastpath somehow? Is that the source of the corruption? 

I realise there's no point me asking you in that earlier post to test out ADSL2+ vs ADSL2 comparison for me if you don't have ADSL2+. Doh.  Sorry.

@Weaver

sync can go higher than that!
e.g. Here is what I see this morning.

Found Form post target: /Forms/login_1
######################################################################## 100.0%
Login POST succeeded.
url_effective http://192.168.0.6/wan.html
num_redirects 1
http_code 200
------------------------------------------------------------------------
   ADSL Statistics
   Mode:                              G.DMT
   Type:                              ANNEX_A
   Status:                            Showtime

                            Downstream Upstream
   Rate (Kbps):             4416 kbps 448 kbps

   SNR Margin (dB):         5.0       17.0
   Attenuation (dB):        63.5      31.5
   Output Power (dBm):      19.5      12.5

   Super Frames:            330447    330446
   RS Correctable Errors:   50996     141
   RS Uncorrectable Errors: 1557      170

   HEC Errors:              5775      174
   Total Cells:             881781    395690
   Data Cells:              513151    29900
   Bit Errors:              0         0

[root@k8 scripts]# cd plink-stats/
[root@k8 plink-stats]# ./get-stats.sh
 system up time:    63:07:59 (15acd01 ticks)
ADSL uptime     1:35:36
--- error-down ---
FEC error interleaved: 51721
CRC error interleaved: 1557
HEC error interleaved: 5775
--- error-up ---
FEC error interleaved: 141
CRC error interleaved: 170
HEC error interleaved: 174
--- error-second ---
Error second in 15min           : 5
Error second in 24hr            : 73
Error second after power-up     : 73
--- margin ---
noise margin downstream: 5.0 db
--- rate-down ---
 4416 kbps
--- rate-up ---
 448 kbps


I had been trying to figure out more exactly what was going on with the sync speed fluctuations.   
I am well accustomed to the more extensive (and to me more understandible) BCM style of data.

Unfortunately I am not finding the zynos cli data to be quite so immediately useful so far.

I do have some data from a previous telnet logs.

Are you using M$ windows?
If so you can log your telnet cli sessions if you use the -telnet -log options to putty.exe   

It would indeed be progress to be able to properly understand what is happening with interleave depth, trellis, data redundany ratio etc.
 
As far as I can tell from some obsolete documentation for zynos Mediatek based DSLAMs that Google found on the net,
this might be related to atuc and atur.
How exactly to find out I am not completely sure. 

ATUC/ATUR SES
The Number of Severely Errored Seconds transmitted (downstream) or
received (upstream) on this ADSL port. Severely errored seconds contained
30% or more errored blocks or at least one defect. This is a subset of the
Down/Up Stream ES

This might be useful.
 
tc> wan dmt msg1
max no of bits per tone 15
transmit PSD -40
atuc fm 3 atur fm 3
EES 1
trellis code 1
vendor rev. 0
T1.413 rev. 0
verdor id 0x0
min required SNR 6
crc2=c05b,crc2_cal=c05b
dn_snr_margin 2304,r_msgs1_trellis_opt 1
tc>

and this
tc> wan dmt msg_ra
max allowed margin 31
min required margin 0
new min required margin 6
c_msgsra_min_snr_margin=6
crc_ra2=755f,crc_ra2_cal=755f
r_msgra_r=0
r_msgra_k=146
r_msgra_ncloaded=161
r_msgra_lp_attenu=127
r_msgra_coding_gain=0
r_msgra_perf_margin=6
r_msgra_dmax=64
r_msgra_bmax=1168
dn_snr_margin 2304
tc>


tc> wan adsl linedata near
relative capacity occupation: 113%
noise margin downstream: 4.5 db
output power upstream: 12.5 dbm
attenuation downstream: 63.5 db
tc>

Also - an immediately useful BCM linestats figure was the Max Possible Data Rate.
So at a glance you could see how your instantaneous rate compared to the Max Possible Rate.

As far as I can tell, you _might_ me able to construct an equivalent by working backwards from the current sync rate and the 'relative capacity occupation', but I have already spent substantial time on this, .... and my new Broadcom based Billion 8800 arrived.

Would I be correct in assuming that you resolved you issues with your firebrick routing and that you are able to access the telnet and http ports on your modem?

Most of the Pieces are there.
It looks like I may have found K and R
in
r_msgra_r=0 and r_msgra_k=146

We should now have access to most of what is depicted here:
http://www.kitz.co.uk/adsl/linestats_errors.htm

 
Just to be clear here.

I have the impression that the modem chipset+adsl binary firmware does quite a good job of syncing and,
most importantly on a slow or unstable line, _re-syncying_.

The Primary Problem for me is that I am stuck on 20CN (i.e. ADSL1)
This means that I get needlessly hammered by IPProfile restriction for days, weeks and infact MONTHS !!!

At one point it took 34 DAYS for DLM to stop punishing me for a single slow resync. !!!   

For my situation, I need a modem that minimises this issue.

I had been persevering with the TrendChip TC3162 / Zynos / D-Link  combo because experience has shown that you need to give DLM a MINIMUM of 10+ DAYS to settle down before you can know if the effects you are seeing might be transitory.

I don't know if I have the patience to endure even slower than usual internet for the full 35 days required to be sure. 
Especially when I cannot actually glean all the information that I would like from the chipset / OS / modem.

I am very heavily tending to the idea of reverting back to the 'known quantity' that is the  Broadcom / Linux / Billion
 combination.
 

[Weaver]

 
[
Unfortunately I am not finding the zynos cli data to be quite so immediately useful so far.

I do have some data from a previous telnet logs.

>Are you using M$ windows?

I have a Windows box, I mostly use my iPad these days since I became ill and have found it uncomfortable to sit upright at a desk. I have a telnet client for iOS, I'm sure. The Firebrick router blocks access to the modems (thank goodness) from the LAN side, but I could of course plug a monitoring device straight into a modem.

> Would I be correct in assuming that you resolved you issues with your firebrick routing and that you are able to access the telnet and http ports on your modem?

No I never solved that, I chose not to pursue it, partly due to fatigue and pain and partly because of other distractions. I'm very glad the modems are as isolated as possible, so no rogue device on the LAN can get at the admin http etc services. I haven't changed the default admin IP but I might change the default admin password and username if possible after reading your belt and braces post. I normally never ever leave any device on admin defaults, but they are physically secured and I keep having to swap them out with successive lightning strikes, so ease of swap out is a convenience thing. I'm pre-programming some now in addition to what AA do but it's difficult to find out what works in the web UI and what is a red herring dummy control.

> This means that I get needlessly hammered by IPProfile restriction for days, weeks and infact MONTHS !!!
I sympathise, having been on ADSL1 until Xmas.
> At one point it took 34 DAYS for DLM to stop punishing me for a single slow resync. !!!   

>For my situation, I need a modem that minimises this issue.

>I had been persevering with the TrendChip TC3162 / Zynos / D-Link  combo because experience has shown that you need to give DLM a MINIMUM of 10+ DAYS to settle down before you can know if the effects you are seeing might be transitory.

Sorry, not following you. :-) Are you saying that DLM is punishing you for the modem's unstable behaviour or the experimental activity that you've had to do?

Do you need more interleave or some such? Are you able to get the HEC errors, a disaster, under control?

I try to stay on the right side of the evil DLM gods. I run my three modems on a UPS (with double output filtering as the output is not a clean sine wave I suspect, but a horrid staircase) and never usually turn it off without waiting the Kitz half hour.

[G.DMT]

The Firebrick router blocks access to the modems (thank goodness) from the LAN side, but I could of course plug a monitoring device straight into a modem.

So, out of the 3 of us that have this modem, I am the only one who is actually trying to monitoring the performance of the line.

I'm pre-programming some now in addition to what AA do but it's difficult to find out what works in the web UI and what is a red herring dummy control.

Having spent some hours exploring the cli via telnet and more hours exploring the GUI via curl I can assure you that
every feature that I have examined in the web interface maps directly to a 'user space call' ( in the common vocabulary of Linux programmer/admin) available on the cli    
 
You can test the truthfulness of a GUI setting by exercising the associated command in a telnet session.

The Menu pane on the Left of the Web GUI layout is javascript driven and a bit of a dogs breakfast to work with -  yet another contributor of my lack of confidence in the 'security' provided. 
 
Anyone  can use the (curl) code that I posted to login and make calls directly to the service behind the features you see in the GUI.
I has been well over a decade since I was last paid to do web development, but it only took me 10 minutes to figure out how to hack around it, and 3 hours to implement it.
Not a good sign. 

This again worries me deeply, and contributes to me not wanting to have it accessible to the LAN- as it is at the moment. 

I need to be able to monitor the ADSL chipset performance, and to do that permanently I would only be comfortable plugging it into an isolated monitoring network (via either a dedicated or a programable switch) accessed solely via my RasPi proxy.

On balance, for me, it seem like a lot of effort powering yet another device (the switch) to work around the issue of only having 1 RJ45 connector, for a device whose apparent strengths will only be able to shine if my exchange ever gets upgraded to 21CN and ADSL2.

IIRC you mentioned that you prefer to keep all modems on the same IP, but maybe I picked that up wrong?
I was assuming you firebrick does not have 3 wan ports and that you are multiplexing via VLANS ?

If so a small configurable switch that understands VLANS (and trunking) like a NETGEAR GS108Tv2
would seem to be an ideal setup for you though!

Sorry, not following you. :-) Are you saying that DLM is punishing you

It is the low IPProfile that is punishing me, but yes.

Are you saying that DLM is punishing you for the modem's unstable behaviour

One of the many frustrations with 20CN DLM is that it is quite difficult to know what it is doing, or why it is doing it.
You have to be logging and watching pretty closely to work it out.
One of the possibilities that I allow for is that the speed drops and resyncs are being caused by a developing line fault, and not the modems fault at all.

If I could see the interleave depth changing when the modem resyncs, I could see if DLM was ramping up error correction ( probably line fault or bad modem) or easing off on the error correction redundancy- speeding up my connection.

Are you saying that DLM is punishing you for the modem's unstable behaviour or the experimental activity that you've had to do?

Ha! I have not even tried the 'adjust the SNR' feature yet.
First I have to wait for DLM to stabilise, and I have to have good monitoring to observe the results of any experimentation.
If the chipset/firmware/OS is already acheiving  the most that can be extracted, then my fiddling can only make it worse. 

Do you need more interleave or some such? Are you able to get the HEC errors, a disaster, under control?

I wish I had that data. Even if I did, ajusting it is entirely in the Lap of the DLM gods. 

Anyhoo it's the weekend and the sun is shining. I'm off out to enjoy it! 

[G.DMT]

In the quest to discover _why_ the modem has been performing so many resynchs
i.e.  Try and understand did poor line conditions/fault/etc cause a resynch and DLM is ramping up error redundancy to compensate or did was the modem forced to resynch by a DLM interventions e.g. line good and DLM backing off on error overhead?

I added some more data collection to the telnet scripts.

Now also reports:
relative capacity occupation:

Scraped from:
tc> wan adsl linedata near

Added a new telnet function:
telnet_show_msgra which calls:

tc> wan dmt msg_ra

seeking to confirm the hunch that the values
r_msgra_k=129
r_msgra_r=0

Are equivalent to
K (Number of bytes in DMT frame)
R (Number of check bytes in RS Code word)

Much as described here:
http://www.kitz.co.uk/adsl/linestats_errors.htm

Now there are 36 lines of output.
The last 14 are exactly as collected,
as I did not want to throw anything away until I could be sure I understood what I was looking at.
 
[root@k8 plink-stats]# ./get-stats.sh   
 system up time:     0:38:52 (38f47 ticks)
ADSL uptime     0:38:22
--- error-down ---
FEC error interleaved: 22004
CRC error interleaved: 173
HEC error interleaved: 673
--- error-up ---
FEC error interleaved: 21
CRC error interleaved: 12
HEC error interleaved: 13
--- error-second ---
Error second in 15min           : 0
Error second in 24hr            : 8
Error second after power-up     : 8
--- margin ---
noise margin downstream: 6.5 db
--- rate-down ---
 3904 kbps
--- rate-up ---
 448 kbps
tc> relative capacity occupation: 115%
tc> max allowed margin 31
min required margin 0
new min required margin 6
c_msgsra_min_snr_margin=6
crc_ra2=755f,crc_ra2_cal=755f
r_msgra_r=0
r_msgra_k=129
r_msgra_ncloaded=145
r_msgra_lp_attenu=127
r_msgra_coding_gain=0
r_msgra_perf_margin=6
r_msgra_dmax=64
r_msgra_bmax=1032
dn_snr_margin 2304

Any hints, advices or even guesses how to proceed with extracting or understanding the Interleave Depth / trellis /  Reed Solomon / Error Correction information will be gratefully received. 

[ejs]

A lot of the things seen in the output here are more or less direct references to messages that are part of the ADSL1 protocol. You need to refer to the ITU G.992.1 PDF

rates_ra corresponds to the C-RATES-RA and R-RATES-RA messages, which give
RS_I number of parity bytes per symbol in the interleave buffer
S number of symbols per codeword
I interleave depth in codewords

wan dmt rates_ra =>
opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|132   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4

The rates_ra messages give 4 options which were considered, and the later rates2 messages indicate which option was chosen, although the RS_I, S and I parameters were the same for all 4 rates_ra options in the wan_dsl_diag.txt data you posted.

[G.DMT]

A lot of the things seen in the output here are more or less direct references to messages that are part of the ADSL1 protocol. You need to refer to the ITU G.992.1 PDF

Thankyou ejs.       

Kitz forums comes up trumps again. 

I have downloaded the English pdf from this link:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.1-199907-I!!PDF-E&type=items

256 pages may take me a little while to digest.   

rates_ra corresponds to the C-RATES-RA and R-RATES-RA messages, which give
RS_I number of parity bytes per symbol in the interleave buffer
S number of symbols per codeword
I interleave depth in codewords

wan dmt rates_ra =>
opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|132   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4

The rates_ra messages give 4 options which were considered, and the later rates2 messages indicate which option was chosen, although the RS_I, S and I parameters were the same for all 4 rates_ra options in the wan_dsl_diag.txt data you posted.

That is great info for me.  So I scripted grabbing the relevant raw data.

[root@k8 plink-stats]# ./get-inter.sh
 system up time:    13:35:21 (4aa5f9 ticks)
ADSL uptime     3:32:55
--- msg_ra.sh ---
tc> max allowed margin 31
min required margin 0
new min required margin 6
c_msgsra_min_snr_margin=6
crc_ra2=755f,crc_ra2_cal=755f
r_msgra_r=0
r_msgra_k=144
r_msgra_ncloaded=158
r_msgra_lp_attenu=127
r_msgra_coding_gain=0
r_msgra_perf_margin=6
r_msgra_dmax=64
r_msgra_bmax=1152
dn_snr_margin 2304
--- rates1.sh ---
tc> opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|238   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
opt1 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|161   0   0   0   0   0   0| 10   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
opt2 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER| 84   0   0   0   0   0   0|  6   0   0
DS:RSf=  0,RSi= 10,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
opt3 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|  5   0   0   0   0   0   0|  2   0   0
DS:RSf=  0,RSi=  6,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
crc1=f5b4,crc1_cal=f5b4
--- rates_ra.sh ---
tc> opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|139   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt1 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|136   0   0   0   0   0   0| 13   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt2 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|133   0   0   0   0   0   0| 12   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt3 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|130   0   0   0   0   0   0| 11   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
r-rates-ra 0x1
crc_ra1=9e2a,crc_ra1_cal=9e2a
--- rates2.sh ---
tc> c-rates2 0x21,r-rates2 0x22
crc4=308b,crc4_cal=308b

But I still can't quite see how to make the connection from

--- rates2.sh ---
tc> c-rates2 0x21,r-rates2 0x22
crc4=308b,crc4_cal=308b


to selecting the correct option block. 

In case it might be useful I dumped a 'wan adsl diag' to file and will attach that here.

[root@k8 plink-stats]# source plink-stats.sh
[root@k8 plink-stats]# telnet_diagnostic > wan_adsl_diag.out.txt

[ejs]

The C-RATES2 message is described on page 108, section 10.8.11. I was going to say you have to convert the hex to binary, but looking at the bit patterns, you don't really have to do that. It's always going to be two hex digits, which will be 1,2,4 or 8 corresponding to option 1,2,3 and 4. The right hex digit must be for downstream and the left digit must be for upstream. It also says the C-RATES2 is the final one, and the ATU-C won't change the downstream option from the one in R-RATES2 it received.

So R-RATES2 0x22 indicates that the ATU-R (your modem) chose downstream option 2 and upstream option 2, and the C-RATES2 0x21 indicates the ATU-C (the DSLAM at the exchange) stayed with downstream option 2, which the PDF says it must, and decided on upstream option 1. I think that would indicate the 136 and 14 values from the rates_ra tables.

To confuse things further, I've written the above mostly based on the G.992.1 PDF, which calls them options 1,2,3 and 4, but I've just noticed they've been numbered 0-3 in the stats output.

[G.DMT]

@ejs Thanks a million! 

Thats really going the extra mile! 

I was able to whip up some regexes to strip out hex digits from c-rates2
and print out the (hopefully!) correct option table(s) to match.

[root@k8 plink-stats]# ./get-inter.sh
 system up time:    24:40:46 (8791b0 ticks)
ADSL uptime     1:48:09
--- msg_ra.sh ---
tc> max allowed margin 31
min required margin 0
new min required margin 6
c_msgsra_min_snr_margin=6
crc_ra2=755f,crc_ra2_cal=755f
r_msgra_r=0
r_msgra_k=132
r_msgra_ncloaded=147
r_msgra_lp_attenu=127
r_msgra_coding_gain=0
r_msgra_perf_margin=6
r_msgra_dmax=64
r_msgra_bmax=1056
dn_snr_margin 2304
--- rates1.sh ---
tc> opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|238   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
opt1 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|161   0   0   0   0   0   0| 10   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
opt2 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER| 84   0   0   0   0   0   0|  6   0   0
DS:RSf=  0,RSi= 10,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
opt3 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|  5   0   0   0   0   0   0|  2   0   0
DS:RSf=  0,RSi=  6,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  1,I= 16
crc1=f5b4,crc1_cal=f5b4
--- rates_ra.sh ---
opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|125   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt1 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|123   0   0   0   0   0   0| 13   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt2 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|121   0   0   0   0   0   0| 12   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt3 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|119   0   0   0   0   0   0| 11   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
r-rates-ra 0x1
crc_ra1=5e70,crc_ra1_cal=5e70
--- rates2.sh ---
c-rates2 0x41
r-rates2 0x44
first_digit_r_rates2: 4
last_digit_r_rates2: 4
first_digit_c_rates2: 4
last_digit_c_rates2: 1
OptName_D: opt2
OptName_U: opt0
opt2 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|121   0   0   0   0   0   0| 12   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4
opt0 +AS0-AS1-AS2-AS3-LS0-LS1-LS2+LS0-LS1-LS2
FAST |  0   0   0   0   0   0   0|  0   0   0
INTER|125   0   0   0   0   0   0| 14   0   0
DS:RSf=  0,RSi= 16,S=  1,I= 32
US:RSf=  0,RSi=  2,S=  8,I=  4


Once again - BIG BIG thanks to ejs for spelling it out for me so clearly.     

I will test this for a few days to check it out, and if it seems reliable I will clean up the output and post the code.
 

[Weaver]

@g.dmt - the firebrick has four Ethernet ports, I have configured three of them to be connected directly to the other three modems. If you wish to have more, the FB itself speaks VLAN tags, you just would have to tell it which VLAN tag value you are using for which modem.

[Chunkers]

I have been testing my four different devices on my line as previously suggested and thought I would share the results, <disclaimer> they are obviously totally non-scientific, probably not repeatable and largely only applicable to me



Sorry I haven't achieved the level of geekiness with the CLI stuff but I am not really that committed, hehe.  Some points of note :

• All the units were left on my line for 2 days and I averaged the number of dropped connections over the period
• I used the connection data from after the initial 24 hours as both the TP-Link and D-Link initially connected more aggressively but slowed down.
• The Broadcoms seem to connect very consistently and have a lower drop out rate
• I actually was impressed with the D-Link D320B Z1, especially considering the price, I have googled to try and find out what chipset it is unsuccessfully.  I saw a note earlier suggesting it is a MediaTek / Trend - this would surprise me as I previously tried a TrendChip  based Asus AC55U on my line and it was a total disaster, dropping the connection so frequently it was un-useable.

Cool beans!

Chunks

[Weaver]

Thank you very, very much Chunkers for that excellent study. Superb.

The earlier thread about DSL-320B-xx hardware variants mentions the specific chip used -
    http://forum.kitz.co.uk/index.php/topic,16583.msg306507.html#msg306507

[ It's very annoying when manufacturers reuse the same model names for completely new hardware. Car manufacturers do it I suppose. Does that legitimise this? ]

[G.DMT]

That is brilliant Chunkers!

Thanks so much for posting this useful comparison.

And here is a link that I had meant to post previously with some technical details of the chipset.

https://wikidevi.com/wiki/TrendChip

My first guess would be that the DLink DSL-320B-Z1 uses the TC3162LEM chipset combined with TC3086 Analog Front End.

A Launch date sometime back in June 2011 would make this silicon obsolete.

5 years is a very, very long time in the semiconductor industry.
Silicon years age even faster than dog years! 

So my best guess would be that it may well use the later  TC3182(P)    TC3086/7 combination.

It is not unheard of for low volume silicon  producers like this to just bake one wafer type, then hobble, not activate some functionality to enable them to sell it at a lower price while thus preventing devalueing the 'fully featured' version.

In fact IIRC the TP-Link TD-W8980 that you have uses the identical modem chipset to the
TP-Link TD-W8970 that I have, which has VDSL non-enabled.

https://wiki.openwrt.org/toh/tp-link/td-w8980

[Weaver]

> A Launch date sometime back in June 2011 would make this silicon obsolete.

> 5 years is a very, very long time in the semiconductor industry.
> Silicon years age even faster than dog years! 

I had wondered if the age of the chipset is the reason why it works so well on my ultra-long line. It dates from an era when ADSL was the priority, and G.Dmt was still very much around, compared with a later era when ADSL performance might have become an ugly sister to the real priority which was VDSL2. This reasoning says also that kit from that earlier era would have got extensively testing on G.Dmt and on high attenuation lines.

[Weaver]

[Bump. Apologies for re-advertising this.]

Would anyone be kind enough to check the enable-bitswap UI thing (in modem mode) for me? See:
      http://forum.kitz.co.uk/index.php/topic,17065.msg314628.html#msg314628

I'm really out of it at the moment, been quite ill the past few days, from Sunday morning onwards. That's why I'm asking, and even though I'm now doing better, I still don't have the energy nor concentration to do it myself.

If you need a DSL-320B-Z1 modem, I can send you one, if that helps.