@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.