Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: FTTC DLM MTBE behaviour?  (Read 5654 times)

Ixel

  • Kitizen
  • ****
  • Posts: 1087
FTTC DLM MTBE behaviour?
« on: November 04, 2012, 09:12:58 AM »

This isn't an issue, more of a question.

I was wondering, based on observations, if anyone knows roughly what the ES or CRC's have to be before DLM may take action in a negative way? The reason I ask this is because, for the moment, I've managed to get myself back on 'fastpath', albeit with a speed cap. I'll explain what I did in order for this to perhaps encourage DLM to get me back there to start with.

Approximately 10 days ago I decided to go back to my Fritz!Box and cap myself to a much lower speed, eventually I set myself to 40 megabits downstream, with no cap on the upstream. My objective was to keep the error seconds under at least 75, or further if I could (under 50). A few days into that experiment DLM decided to reduce my INP from 4 to 3. After 7 days into the experiment I lost hope with DLM switching me back so I decided to go back to the HG612 since it synced better and surprisingly had less errors than my Fritz!Box, though it was capped at 60 megabits downstream due to the DLM altering the min/max rates as a result of me doing so. A few days later (today in other words) at 4am or so DLM resynced me, and to my amazement, though it hasn't removed the downstream cap, it did remove INP and delay altogether! Sadly, I fear I may lose 'fastpath' as my error seconds have gone up to over 100 ES in around 5 hours of sync uptime :(. If that rate of ES continues I am expecting to probably get around 300-400 ES in a 24 hour period I imagine.

I've also read, on the TalkTalk forum, that Biohead did a test where his cabinet, like mine, is ECI hardware. He was using an ECI modem but wanted to use Huawei presumably for line stats, so he lost 'fastpath' apparently during that time of using the Huawei. When he went back to the ECI he shortly got back 'fastpath'. I wonder if it's worth me finding an ECI modem on eBay or somewhere and trying that on my line?

Code: [Select]
BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# xdslcmd info --stats
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max:    Upstream rate = 27652 Kbps, Downstream rate = 85332 Kbps
Path:   0, Upstream rate = 20000 Kbps, Downstream rate = 59999 Kbps

Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        13.0            9.7
Attn(dB):        0.0             0.0
Pwr(dBm):        12.4            4.8
                        VDSL2 framing
                        Path 0
B:              239             236
M:              1               1
T:              64              5
R:              0               16
S:              0.1273          0.3771
L:              15081           5410
D:              1               1
I:              240             255
N:              240             255
                        Counters
                        Path 0
OHF:            9133198         310238
OHFErr:         127             57
RS:             0               542951
RSCorr:         0               406
RSUnCorr:       0               0

                        Path 0
HEC:            915             0
OCD:            0               0
LCD:            0               0
Total Cells:    2153866054              0
Data Cells:     690838          0
Drop Cells:     0
Bit Errors:     0               0

ES:             156             362
SES:            5               0
UAS:            249             249
AS:             18678

                        Path 0
INP:            0.00            0.00
PER:            2.03            6.12
delay:          0.00            0.00
OR:             90.32           203.67

Bitswap:        203             12

Total time = 1 days 14 hours 55 min 2 sec
FEC:            0               0
CRC:            127             0
ES:             156             362
SES:            5               0
UAS:            249             249
LOS:            4               0
LOF:            5               0
Latest 15 minutes time = 10 min 2 sec
FEC:            0               0
CRC:            5               0
ES:             3               3
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
Previous 15 minutes time = 15 min 0 sec
FEC:            0               0
CRC:            8               0
ES:             7               1
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
Latest 1 day time = 14 hours 55 min 2 sec
FEC:            0               0
CRC:            127             0
ES:             113             138
SES:            5               0
UAS:            22              22
LOS:            4               0
LOF:            5               0
Previous 1 day time = 24 hours 0 sec
FEC:            0               0
CRC:            0               0
ES:             43              224
SES:            0               0
UAS:            227             227
LOS:            0               0
LOF:            0               0
Since Link time = 5 hours 11 min 17 sec
FEC:            0               406
CRC:            127             57
ES:             100             50
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
Logged

biohead

  • Member
  • **
  • Posts: 65
Re: FTTC DLM MTBE behaviour?
« Reply #1 on: November 04, 2012, 05:39:30 PM »

Funnily enough, I only swapped back to the ECI after reading on here that the HG612 doesn't play 100% nicely with ECI hardware.

And it's just too much of a coincidence that my pings lowered and download speeds increased just a few days after plugging the ECI back in, to the same values they were before I originally swapped to the HG612.
« Last Edit: November 04, 2012, 06:34:41 PM by biohead »
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #2 on: November 04, 2012, 06:11:11 PM »

Funnily enough, I only swapped back to the ECI after reading on here that the HG612 doesn't play 100% nicely with ECI hardware.

And it's just too much of a coincident that my pings lowered and download speeds increased just a few days after plugging the ECI back in, to the same values they were before I originally swapped to the HG612.

I see. I'm expecting DLM to put INP back up to 2 or 3 again soon, as I'm getting roughly 1 error second every 2 minutes or so on average, with about 1-2 CRC for each error second. At INP 3 I believe I got about 1-2 ES every 40-60 minutes on average. Perhaps these 1-2 CRC's I'm mostly continually getting are caused by an incompatibility which then makes DLM take action. If DLM takes action then I will buy an unlocked ECI modem on eBay and hope that resolves it.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 25684
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC DLM MTBE behaviour?
« Reply #3 on: November 04, 2012, 06:13:27 PM »

Now where is that Bald_Eagle1? Perhaps Mrs Eagle is ensuring that the Eagles' Nest is fully refurbished in time for this Christmas? (Rhetorical questions.)

  :D
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #4 on: November 04, 2012, 06:19:24 PM »

Now where is that Bald_Eagle1? Perhaps Mrs Eagle is ensuring that the Eagles' Nest is fully refurbished in time for this Christmas? (Rhetorical questions.)

  :D

Ha. Would be interesting to see what his thoughts are on the current connection state.
Logged

biohead

  • Member
  • **
  • Posts: 65
Re: FTTC DLM MTBE behaviour?
« Reply #5 on: November 04, 2012, 06:40:56 PM »

I'd like to be able to unlock my ECI modem and pull what stats I can from it, as without them I've not been able to show/prove a difference when the HG612 is in use to the ECI one. Until we have some actual numbers and stats, there's not much more we can make from it.

If anyone has a right angled pin header they wish to donate to the cause feel free to get in touch  ;)

I'm also hoping to pick up one of Asbokid's HG610 units (mainly for my own use on a separate adsl line), and see if that does the same to my fttc line as the HG612 does.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 25684
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC DLM MTBE behaviour?
« Reply #6 on: November 04, 2012, 06:45:16 PM »

Quote
If anyone has a right angled pin header they wish to donate to the cause feel free to get in touch  ;)

b*cat extends his paw and gives biohead a gentle pat.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #7 on: November 04, 2012, 07:01:30 PM »

Well, temptation has drawn me to buying an unlocked ECI modem on eBay. Hopefully it'll be here by the end of next week, it will be interesting to see if DLM puts INP back up to 2-3+ before it arrives. If I'm right, based on past observations, DLM will increase INP if the ES is around 200+ in a 24 hour period, but not immediately. What DLM seems to like, again not immediately, has been stated in my first post. I've also observed that DLM seems to operate between four INP settings, at least for my line, I've had INP 0, 3, 4 and 5. Interleaving depth I've noticed mainly follows the sync speed and only changes when INP changes, unless someone has observed different behaviour from that.

Anyway, any further thoughts on my current connection are welcome, but hopefully the ECI will reduce these rather almost continual 1-2 CRC errors every minute or two that I'm getting.
Logged

biohead

  • Member
  • **
  • Posts: 65
Re: FTTC DLM MTBE behaviour?
« Reply #8 on: November 05, 2012, 11:34:57 AM »

Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #9 on: November 05, 2012, 12:44:23 PM »

Just found a tad more on mixing Modems to DSLAMs:
http://beusergroup.co.uk/technotes/index.php?title=Diary_of_an_FTTC_Install#Interesting_Notes

Very interesting information. I hope the attainable rate isn't hugely different on my line though as I may just go short of 20000Kbps upload :(, as well as download not quite achieveing the full 80000 (once DLM uncaps my profile, and of course if I allow it by not using a cap on my Fritz!Box, sticking to the Huawei or using the ECI which should hopefully arrive tomorrow).

On an additional note, I'm amazed that DLM didn't intervene this morning and re-apply INP, given my ES and CRC's were both about 600-700 range in a 24 hour period. Perhaps it has a delay before taking another action, or recognises that the CRC's themselves are not significantly high (e.g. 20+ per minute, where as mine are about 1-2 per minute). If Royal Mail are efficient then I should be receiving the unlocked ECI tomorrow.
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #10 on: November 05, 2012, 08:33:20 PM »

Something of interest I thought I'd share here as well as earlier on the TBB forum. Hopefully I can try it out tomorrow if the modem arrives in the post.

A command that interests me (g997cdrtcg / g997cdrtcs)...
AKA G997_ChannelDataRateThresholdConfigGet / G997_ChannelDataRateThresholdConfigSet:

Code: [Select]
static const DSL_char_t g_sG997cdrtcg[] =
#ifndef DSL_CPE_DEBUG_DISABLE
   "Long Form: %s" DSL_CPE_CRLF
   "Short Form: %s" DSL_CPE_CRLF
   DSL_CPE_CRLF
   "Input Parameter" DSL_CPE_CRLF
#if (DSL_CPE_MAX_DEVICE_NUMBER > 1)
   "- DSL_uint32_t nDevice (optional, not used in the 'backward compatible' mode)" DSL_CPE_CRLF
#endif
   "- DSL_uint8_t nChannel" DSL_CPE_CRLF
   "- DSL_AccessDir_t nDirection" DSL_CPE_CRLF
   "   upstream = 0" DSL_CPE_CRLF
   "   downstream = 1" DSL_CPE_CRLF
   DSL_CPE_CRLF
   "Output Parameter" DSL_CPE_CRLF
   "- DSL_Error_t nReturn" DSL_CPE_CRLF
#if (DSL_CPE_MAX_DEVICE_NUMBER > 1)
   "- DSL_uint32_t nDevice (optional, not used in the 'backward compatible' mode)" DSL_CPE_CRLF
#endif
   "- DSL_uint8_t nChannel" DSL_CPE_CRLF
   "- DSL_AccessDir_t nDirection" DSL_CPE_CRLF
   "   upstream = 0" DSL_CPE_CRLF
   "   downstream = 1" DSL_CPE_CRLF
   "- DSL_uint32_t nDataRateThresholdUpshift" DSL_CPE_CRLF
   "- DSL_uint32_t nDataRateThresholdDownshift" DSL_CPE_CRLF
   DSL_CPE_CRLF "";

Is this possibly a command that will restrict the maximum downstream/upstream to what you specify (specifically the set command that is)?

For example, I imagine if I wanted to set on the downstream a max rate of 70,000 Kbps and a min rate of 60,000 Kbps I would do the following...
Code: [Select]
g997cdrtcs 0 1 70000 60000
That's assuming that's what it does, and that's also assuming I'm right in believing it's channel 0.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 25684
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC DLM MTBE behaviour?
« Reply #11 on: November 06, 2012, 12:18:54 AM »

Quote
If anyone has a right angled pin header they wish to donate to the cause feel free to get in touch  ;)

b*cat extends his paw and gives biohead a gentle pat.

There is a block of five right-angle header-pins, sulking in The Cattery, whilst awaiting a new caring, home.  :-X
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #12 on: November 06, 2012, 09:52:15 AM »

Just an update to say to others that I've received the unlocked ECI modem this morning and so far (touch wood) there has been absolutely no errors on the upstream or downstream, unless the GUI is wrong (which I hope not). I usually have errors within at least 5 minutes of sync, but I've been synced for nearly 30 minutes without any so far.

At this time, it appears true that you should use an ECI modem on an ECI cabinet, my Fritz!Box 7390 and HG612 both produced errors within 5 minutes of sync uptime. My attainable rates are slightly different however, downstream is virtually identical to the HG612 for me (85000Kbps or so), but the upstream has lost about 7 megabits (attainable is just below 20000Kbps). Nevermind though, so long as it remains stable (virtually error free), keeps me on fastpath and doesn't drop further, I'm happy :).

I will begin my hunt for commands on telnet and update again once I know more for those who are interested, probably in a different thread though.
Logged

biohead

  • Member
  • **
  • Posts: 65
Re: FTTC DLM MTBE behaviour?
« Reply #13 on: November 06, 2012, 10:26:49 AM »

Ixel: can you access the GUI through LAN port 1, or like the hg612 do you have to use LAN2?
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1087
Re: FTTC DLM MTBE behaviour?
« Reply #14 on: November 06, 2012, 10:40:39 AM »

Ixel: can you access the GUI through LAN port 1, or like the hg612 do you have to use LAN2?

I was unable to access it through LAN1, due to the fact I'm guessing it's purely setup for PPPoE, LAN2 works fine for me.

Some interesting stats:
Code: [Select]
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh pmcctg 0 1
nReturn=0 nChannel=0 nDirection=1 nElapsedTime=4201 bValid=1 nCodeViolations=0 nFEC=0

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh pmcctg 0 0
nReturn=0 nChannel=0 nDirection=0 nElapsedTime=4221 bValid=1 nCodeViolations=0 nFEC=0

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lsg 1 1
nReturn=0 nDirection=1 nDeltDataType=1 LATN=178 SATN=170 SNR=112 ATTNDR=85765760 ACTPS=-901 ACTATP=-3

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lsg 0 1
nReturn=0 nDirection=0 nDeltDataType=1 LATN=0 SATN=0 SNR=61 ATTNDR=19633716 ACTPS=-901 ACTATP=103

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lspbg 1
nReturn=0 nDirection=0 LATN[0]=125 LATN[1]=285 LATN[2]=454 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=134 SATN[1]=283 SATN[2]=453 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=111 SNR[1]=108 SNR[2]=115 SNR[3]=-32768 SNR[4]=-32768

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lspbg 0
nReturn=0 nDirection=0 LATN[0]=11 LATN[1]=211 LATN[2]=334 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=15 SATN[1]=209 SATN[2]=334 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=60 SNR[1]=61 SNR[2]=61 SNR[3]=-32768 SNR[4]=-32768

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997csg 0 1
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59996000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0

Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997csg 0 0
nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19460000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0
Logged
 

anything