Print

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

[snadge]

I found a page in DGteam fw on my 834N that allows 1 custom script to be executed under each section (startup, ADSL connect, Wireless, Firewall, Cron).. seeing as DGteam doesnt include the i24k switch I would like to run it here when connection is starting up - I know invoking i24k causes a re-sync, can this command be executed in one of these sections?? and if so.. which one? - I would like i24k enabled whenever the router is re-sync'd or rebooted

Enable router Startup (boot) custom script execution

Here it's possible to add a user defined script which will be executed at the end of the router's predefined startup sequence.
Note: The custom boot script will be executed once and only once in router's OS cycle lifetime and router's ADSL connection must be considered off at script execution: for these reasons, during the script preparation, don't include commands which depend on ADSL connection because they should be better included into the ADSL (re)connection custom script.

Enable router ADSL (re)connection custom script execution

Here it's possible to add a user defined script which will be executed at the end of the router's ADSL connection sequence or whenever a reconnection is needed.
Note: The custom reconnection script will be executed every time an ADSL reconnection event occurs and router's ADSL connection must be considered on at script execution: for these reasons, during the script preparation, it's always recommended to consider command restart events (kill then run) to prevent double executions.

thanks

[GigabitEthernet]

I think that if you put it in the boot script menu, it should work.

[snadge]

I think that if you put it in the boot script menu, it should work.

but if I re-sync the router...will it be executed?  bit of a funny one this lol

[GigabitEthernet]

I think that if you put it in the boot script menu, it should work.

but if I re-sync the router...will it be executed?  bit of a funny one this lol

Put it in both!!!!

[burakkucat]

A power-cycle or re-boot of the device will involve the local modem and the remote DSLAM/MSAN performing a link re-sync.

A link re-sync between the local modem and the remote DSLAM/MSAN will not invoke the local modem's re-boot code.

Hence I would suggest that use use the second of the two locations: Enable router ADSL (re)connection custom script execution.

[snadge]

thanks B'Kat 

I wonder,

executing i24k invokes a resync @ 100% SNRM, if I included it in that section of the router with my SNRM lower at 50% - I wonder if i24k will be enabled with the lower SNRM..  thing is theres no way of checking to see if i24k is on

[burakkucat]

I think it is now just a case of "suck it and see". 

[GigabitEthernet]

On newer routers, one can type "adsl profile --show" to show the options selected, e.g. i24k (called "24k" for some reason), sesdrop, etc.

[snadge]

Here it's possible to add a user defined script which will be executed at the end of the router's ADSL connection sequence or whenever a reconnection is needed.

as i24k invokes a reboot @ 100% SNRM then if I stick it in this section it will cause a double re-sync without my reduced SNRM or other options , I wonder if I can add all the commands in the box and put em in? (reduced SNRM, PhyRe on, Sesdrop on, i24k on)

if I put em in first box it will only be executed after a hard boot,
if i put em in second box it will be executed after a soft boot (so two syncs will occur)
if I put em in BOTH boxes 2 maybe 3 syncs will occur after a hard boot

EDIT i just tried it and run "execute script" with adslctl configure --i24k on and nothing happened...seems they are not for adslctl command but for scripts to do stuff withtin the router..?? not sure  asbokid would know

[asbokid]

Sorry, Snadge, I don't know, although Burakkucat's advice sounds good: drop that i24k command into the reconnect script, rather than the boot script, and then follow arobertson545's advice and check the status of the i24k switch (16 or 24kbyte interleaving buffer), to see whether it's been toggled correctly:

The switch seems to work okay on this 6368 device (HG612)..

Code: [Select]

# xdslcmd start --i24k on
xdslCtl_GetVersion success

# xdslcmd info
xdslcmd: ADSL driver and PHY status
Status: Idle
Status: G.994 Training
Status: G.992 Started
Status: G.922 Channel Analysis
Status: G.992 Message Exchange
Status: Idle
Status: G.994 Training
Status: G.992 Started
Status: G.922 Channel Analysis
Status: G.992 Message Exchange
..
Status: Showtime
Max: Upstream rate = 1192 Kbps, Downstream rate = 19128 Kbps
Path: 0, Upstream rate = 1020 Kbps, Downstream rate = 17223 Kbps

# xdslcmd profile --show

Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra Off
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: On
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
#

Good luck with it.. It looks like the 24kbyte buffer is an amendment to the xDSL specifications..  This from the Broadcom White Paper that we chatted about. The author(s) of the paper don't seem to think that increased interleave memory can provide an adequate solution for impulse noise: [1]

From the Broadcom White Paper:

Limitations of the Traditional RS + Interleaver Scheme

DSL technologies, including ADSL1/2/2+ and VDSL2, define a Forward Error Correction (FEC) scheme based on a combination of RS coding and convolutional interleaving to provide extra coding gain in first instance and, by extension, protection against impulsive noise (SHINE or REIN).  When ADSL2+ was defined a few years ago, the importance of the impulse noise issue was not identified,  and impulse noise protection was made worse as there was no initial provision in the new standards to scale Impulsive Noise Protection (INP) with the increasing line rates.  The most recent amendments to the standard aimed to improve this are interleaving memory and interleaving depth were increased from 16 KB to 24 KB and from 64 to 511 respectively, and the RS decoding speed pushed upward. Those improvements appear largely insufficient today, where DSL struggles to achieve 1 ms impulse noise protection, despite field data demonstrating that at least 5 ms are required.

“They steal your bandwidth” (and reduce your service reach)

The RS + Interleaver scheme suffers from a high overhead burden because for every errored byte, two additional overhead bytes must be transmitted to allow for a successful FEC correction. For example, assuming that an overhead of 10% correctable is tolerable, correcting a burst of 1 ms of impulsive noise (INP = 4 DMT symbols) requires an interleaver depth (or delay) of minimum 10 ms:

INP (ms) = ˝OH . delay (ms)

The ITU amendments mentioned above do not change anything in that fundamental limitation and only intend to be as close as possible to the formula without introducing additional framing limitations. 

Figure 1 clearly illustrates the capacity losses on an ADSL2+ system that complies with latest ITU amendments for increasing INP when delay is constrained to 8 ms. When INP is set to 4 and at 16 Mbps (4 kilobits per symbol), capacity loss is about 20%!

“They cheat with your margin” (Coding Gain Overbooked)

When we claimed above that the RS coding provided extra coding gain, we were fooling ourselves together with the whole DSL industry! Indeed, the RS coding gain assumes that the RS decoder is correcting the random stationary errors present when the line runs at a low-noise margin. In those margin conditions, the likelihood is very high that there is no room anymore to correct extra errors from noise impulse popping up on the line and the other way around.

Figure 2 shows that with a 2 dB noise margin, a (128,112) RS code with 24 KB interleaving memory will fail to correct an impulse it should correct in 33% of cases. In practice, at least 3 dB of margin is needed to correct more than 99.5% of the expected impulses.

RS FEC capabilities are, therefore, double-booked. In practice, an additional 2–3 dB margin is required to recover the expected BER and INP figures, at the cost of huge capacity loss.

“They can make it even worse” (Error Propagation)

The next problem is the well-known issue of error propagation caused by the deinterleaver. The processing that scatters the errors to make them correctable by the RS code also makes the situation much worse when the RS code is stressed beyond its correction capability. Whenever a burst exceeds the RS code correction capability, the impulse affects data over the full depth (or delay) of the deinterleaver, as illustrated in Figure 3.

This means that for a system set with INP = 2 (500 μs) and delay = 8 ms, an impulse slightly above 500μs can destroy 8 ms worth of data. Remember as well that we are talking about impulse of up to 5 ms in the field, and that +500 μs is very common. In such a case, the error is likely to cause so many packet losses that it will not go unnoticed, making the work of any MPEG forward error correcting code or application-level retransmission extremely difficult.

“They ask you to pay to do their job” (Provisioning Nightmare)

All the above-mentioned issues make it clear that access providers have to pay a heavy operational price to get only minimal and best effort protection. Due to the huge price of these high INP settings (reduced service reach), they can only be applied on an individual basis, assuming a setting can be found to cope with both service and INP requirements. This is a provisioning nightmare: service providers have to develop or buy intelligent network analyzer tools that play with limited INP (RS/interleaver), noise margin, minimum rate, and delay settings and try to limit the rate losses to get a bare minimum INP and/or BER protection.

[1] http://forum.kitz.co.uk/index.php?topic=11113.0

[GigabitEthernet]

Hello asbokid, would it be possible to give a dumbed-down idea of what exactly i24k does? As simple as possible, please .

[snadge]

 i24k changes the amount of memory used for interleaving/de-interleaving from 16k to 24k and is supposed to make it more efficient at it ...or something like that, asbo will explain better

the command arobertson545 talks about to check does not work on 6348 or 6358 as i tried it via DMT Tool telnet commands

I dropped the commands into the script boxes (on their own...I dunno if there is supopsed to be any supporting code) then pressed "execute script" and nothing happened (i24k invokes a reboot when started)

edit: just tried xdslcmd profile --show and adslctl profile --show but they dont work on 6358 (DG834N)

im wondering if the script box is for a different type of script that can invoke these commands? like say I say if I put adslctl configure --i24k on (which works via telnet) into the script box, then invoke "execute script" it does nothing

EDIT: IM starting to wonder if sesdrop = i24k - because i24k switch is missing from DGTeam firmware, yet sesdrop description sounds like its related
.."Enabling this option, it will be possible to reduce/eliminate transmission controls and error corrections on data packets, trying to reduce latency in particular on "Interleaved" path ADSL line. It's recommended not to use this option, because many unwanted reliability issues may occur, but if you have excellent line values, you can try to see its effects.
Selecting: default, the router will use ISP predefined setting, normally disabled. "

can i buy a HG612 device that will work on ADSL2+ ?

[Bald_Eagle1]

can i buy a HG612 device that will work on ADSL2+ ?

I have no idea about all the rest but yes, the HG612 does indeed work on ADSL2+ connections.

asbokid previously has demonstrated that in action in various places.

# xdslcmd profile --show

By default, the HG612 is set to determine all these modulations & set itself up accordingly:-

Modulations:
        G.Dmt   Enabled
        G.lite  Enabled
        T1.413  Enabled
        ADSL2   Enabled
        AnnexL  Enabled
        ADSL2+  Enabled
        AnnexM  Disabled
        VDSL2   Enabled
VDSL2 profiles:
        8a      Enabled
        8b      Enabled
        8c      Enabled
        8d      Enabled
        12a     Enabled
        12b     Enabled
        17a     Enabled
        30a     Enabled
        US0     Enabled
Phone line pair:
        Inner pair
Capability:
        bitswap         On
        sra             Off
        trellis         On
        sesdrop         Off
        CoMinMgn        Off
        24k             On
        phyReXmt(Us/Ds) Off/On
        TpsTc           AvPvAa
        monitorTone:    On
        dynamicD:       On
        dynamicF:       On
        SOS:            On
        Training Margin(Q4 in dB):      -1(DEFAULT)
#

The ADSL graphing scripts could also be easily tweaked slightly to work with the HG612.

HTH.

[Bald_Eagle1]

The ADSL graphing scripts could also be easily tweaked slightly to work with the HG612.

FWIW, the first scripts (Current Stats only at this stage) have been amended to work with a Huawei HG612 on an ADSL/ADSL2/ADSL2+ connection.

They just need testing on a live connection now, for any final tweaking etc.

Anyone? 

[snadge]

thats a 6368 chipset so should work on other 6368 chipset I would imagine... such as Netgear DGND3700