Print

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

[Ixel]

Just to confirm the Draytek does alter sync rate when changing the SNR,

Thats very interesting. Thank you for confirming it.    Previously altering the target SNRm has been impossible.

Anyone on VDSL with a BCM based router want to try and see if it works on theirs too?   Is this something to do with the recent changes.

are the stats below likely to trigger a DLM response or am I safe to leave it?

Sorry its a bit impossible to say from one set of stats.  I cant tell how long a period the ESecs cover. 
232 E/S for a day is perfectly fine.   Your upstream looks more concerning though 

The upstream statistics might be doing what the ASUS modem's statistics do (at least through TC Console, not the web interface). That being it has the ability to fetch the statistics from the DSLAM for the upstream and the DSLAM keeps record of these even when a re-sync occurs. They might be the actual total for the connected port since the port was made active on the DSLAM.

[marjohn56]

That's correct, it's fetching the total FE errors even after a re-sync, so those are the total figures from the DSLAM. I wonder it that's the figures since it was reset, now almost a month or since the DSLAM went live on that circuit.

I have just started to put a program together which will pull the figures down and keep delta stats so makining it easier to see what's happening. Strangely, the telnet interface where I pull the data from does not give me the same amount of information as the web interface, and I have yet to work out how to extract the figures from the web interface. Think I'll email Draytek and ask for an extended console status command.

[marjohn56]

If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed.

Kitz i do think it's going to take a miracle for interleaving to be removed, it's now 7days since capping the sync from 30000 kbps to 25000 kbps even with 100 downstream errored seconds over 24 hours and with my oscillating SNRm this is going to be hard to get interleaving removed 

It's making me think that the sudden increase in sync rate was then just that the Draytek is producing less errors than the HG612 or at least is not reporting them back to the DSLAM, in the same way that Ixel can overide the DSLAM, although as you say the errors look fine.

ES count would have been 24hrs and 30 minutes, or at least the DS one is.

It gets ever more confusing!

[Ixel]

Here's an interesting fact for everyone to chew into . This morning DLM intervened and increased my upstream (by increased, I mean changed profile to be fastpath - roughly two weeks after it was interleaved I believe). However, here's where the interesting bit comes in:

Code: [Select]

Downstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate                       =    128 kbit/s
Max_net_data_rate                       =  49000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      8 ms
INP_min                                 =      3 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

Upstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate                       =    128 kbit/s
Max_net_data_rate                       =  20000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      1 ms
INP_min                                 =      0 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory
Notice the 'min_net_data_rate', it's not roughly half the 'max_net_data_rate', yet it used to be (could this be part of the DLM changes relating to ASSIA patents court case?).

Here's an old sample for comparison:

Code: [Select]

Downstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate                       =  25000 kbit/s
Max_net_data_rate                       =  49000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      8 ms
INP_min                                 =      3 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

Upstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate                       =  10000 kbit/s
Max_net_data_rate                       =  20000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      8 ms
INP_min                                 =      4 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

[kitz]

>> 'min_net_data_rate', it's not roughly half the 'max_net_data_rate'

Thats interesting.   Im pretty certain that in amongst all the stuff Ive read on DLM there was something about a minimum figure and max figure is used, but for what I cant recall where now.   Ive read sooooo much stuff you wont believe, but Ive tried to be methodical about it and only concentrate on each step of the process at any one time, otherwise its information overload.  I'll no doubt come across it again as I work my way through the next step or two.

Problem here is that most routers dont show that info.   The BCMs have a MaxDataRata setting, but I cant recall a Minimum.   These figures dont show up on any of the line stat figures either.  We do get a figure though which is about 1/4 of my sync speed (Number of bits in PMD Data Frame.)

Code: [Select]

L:              20104           5410

Next time I have a few hours (and the will) to go through all the stuff again I will be on the lookout for it.



As an aside.  Whilst making this post Ive just had a resync completely out of the blue.  There is no reason why my line should have resync'd and it wasnt generated at my end.  Its not unusual for my DLM resyncs to occur at 10-11am, yet I cant see that any line params have been changed.   Anyone else have unexplained resyncs this morning at about the time the DLM would force changes? 

[Chrysalis]

yes usually the min is half the max, I seen this when I used my friztbox.

Interesting find ixel.

[Ixel]

>> 'min_net_data_rate', it's not roughly half the 'max_net_data_rate'

Thats interesting.   Im pretty certain that in amongst all the stuff Ive read on DLM there was something about a minimum figure and max figure is used, but for what I cant recall where now.   Ive read sooooo much stuff you wont believe, but Ive tried to be methodical about it and only concentrate on each step of the process at any one time, otherwise its information overload.  I'll no doubt come across it again as I work my way through the next step or two.

Problem here is that most routers dont show that info.   The BCMs have a MaxDataRata setting, but I cant recall a Minimum.   These figures dont show up on any of the line stat figures either.  We do get a figure though which is about 1/4 of my sync speed (Number of bits in PMD Data Frame.)

Code: [Select]

L:              20104           5410

Next time I have a few hours (and the will) to go through all the stuff again I will be on the lookout for it.



As an aside.  Whilst making this post Ive just had a resync completely out of the blue.  There is no reason why my line should have resync'd and it wasnt generated at my end.  Its not unusual for my DLM resyncs to occur at 10-11am, yet I cant see that any line params have been changed.   Anyone else have unexplained resyncs this morning at about the time the DLM would force changes?

Yeah, it's unfortunate that most modems don't display that data. I'm hoping the rumour of ASUS locking down TC is not true, if that happens then I'll probably sell the router on or take it back for a refund/credit note. Anyway, my guess is your connection might have had its minimum sync rate altered to like mine is now (128Kbps), presumably under DLM's changes regarding the ASSIA patents court case.

[marjohn56]

@Kitz

No retrains here, 37 hours uptime since the last re-sync when I changed the SNR.

[Jasonkruys]

I've been up for 45 days now, and still interleaving is not relenting. As far as I can see, I have very few errored seconds. Do my stats on mydslwebstats offer any kind of clue to you knowledgeable folk as to whether I might ever come back off of interleaving? I was off for a couple of months once upon a time!
Sent from my Lumia 1520 using Tapatalk (with free typos)

[marjohn56]

I can see no rhyme or reason with the way the DLM operates, yours looks very clean.

[Ixel]

I've been up for 45 days now, and still interleaving is not relenting. As far as I can see, I have very few errored seconds. Do my stats on mydslwebstats offer any kind of clue to you knowledgeable folk as to whether I might ever come back off of interleaving? I was off for a couple of months once upon a time!
Sent from my Lumia 1520 using Tapatalk (with free typos)

If Sky provision their FTTC services on DLM's 'standard' profile then it's no surprise that you're not on fastpath yet. Looking at your graphs and entering the average ES daily (around 30-40 error seconds each day I see for the last couple of days mostly), on Kitz's DLM calculator it shows the status as 'amber', meaning no change is necessary. I'm not sure what thresholds the Kitz's DLM calculator follows, but I'm guessing it's not the ones shown in Zen's FTTC training document from a few years ago. To get a 'green' status on DLM's 'standard' profile the calculator shows you need less than 15 errored seconds in a 24 hour uptime period. If this is the case then Zen's document is clearly wrong, as going by the document your line should've had a change (unless you have a large caution counter or w/e it's called).

[marjohn56]

I've just had a look at the web stats, the only thing that stands out is on the US snrm, I wonder if the DLM is looking at that in some way. I am also on Sky and unless I have been put on a fast profile I would have thought my ES was sufficient to trigger the DLM. Of course I am not complaining.

[kitz]

on Kitz's DLM calculator it shows the status as 'amber',

Its currently set for WBC 20/21CN rather than FTTC.    and although its dead easy for me to change the parameters, it seems pretty obvious that fttc is using a different set of figures for the 'speed' profile. 
I guess I really need to build 2, or  probably better add an option to select FTTC/WBC.   That said, if it showing as amber now on WBC then because the fttc params are stricter, then it wont be green for fttc either.

[kitz]

or  probably better add an option to select FTTC/WBC.

Done.

[Chrysalis]

I've been up for 45 days now, and still interleaving is not relenting. As far as I can see, I have very few errored seconds. Do my stats on mydslwebstats offer any kind of clue to you knowledgeable folk as to whether I might ever come back off of interleaving? I was off for a couple of months once upon a time!
Sent from my Lumia 1520 using Tapatalk (with free typos)

If Sky provision their FTTC services on DLM's 'standard' profile then it's no surprise that you're not on fastpath yet. Looking at your graphs and entering the average ES daily (around 30-40 error seconds each day I see for the last couple of days mostly), on Kitz's DLM calculator it shows the status as 'amber', meaning no change is necessary. I'm not sure what thresholds the Kitz's DLM calculator follows, but I'm guessing it's not the ones shown in Zen's FTTC training document from a few years ago. To get a 'green' status on DLM's 'standard' profile the calculator shows you need less than 15 errored seconds in a 24 hour uptime period. If this is the case then Zen's document is clearly wrong, as going by the document your line should've had a change (unless you have a large caution counter or w/e it's called).

of course this is dependent on what profile he/she is on.

I think sky are not using the performance profile, my guess is based on the fact their own ADSL DLM is very conservative, they seem to like to play it safe.