Lantiq DSL Modem - Line Uptime drift (lagging)

How can you possibly claim that? You have a sample size of one device, one chipset and one DSL line.

We don't know the reason for the drift, so how can you possibly know your "fix" will work for everyone? Different firmwares can be tested, yes. But if it's a modem chipset issue, how do you know different chipsets from the same family behave the same? If it's a an issue with values from the DSLAM, how do you know all DSLAMs behave the same?

"Trust me, I play a doctor on TV."

Well then, play the devil's advocate and prove me wrong. It's as simple as that.
I left a step by step guide on how to apply the fix in one of my previous posts for others to test it as well and they are more than welcome to post feedback here.
It's a community forum people.
It's a group effort.
We share our knowledge and help each other. That's how progress is made.

1 Like

Thanks. It worked! I tried on zyxel P2812 modem.

So we now know the fix works for

TP-Link	TD-W8970	Lantiq XWAY VRX268
ZyXEL	P-2812HNU-F1	Lantiq XWAY VRX288

I will keep updating the list with every confirmed report.
Thanks all for your support.

Alright, besides the fact that this is not how any of this works, I'll play along. I restarted my router this morning, so I can't show a huge uptime, but it's already enough:

Fritz!Box 3370 (Lantiq XWAY VRX288), Firmware 5.7.8.9.1.4
Uptime according to system clock: 14h08m55s = 50935 seconds
Uptime according to modem: 13h46m14s = 49574 secs
Which means a drift of 1.0274 for me.

The uptime corrected by your 1.024062, while admittedly an improvement, would still be off by 3 minutes.

Look, I'm not trying to be confrontional, or argue that there is not an issue here. What I am saying is that we don't know the cause, so we don't know the solution. Trying to find a "correction factor" by experimentation/observation is a valiant effort, but it's only a band-aid, and apparantly one that isn't sticking all too well.

Edit: In the end, though, I am not the arbiter here. Submit it to the devs, hear their feedback. Personally, I don't give enough expletives about the uptime the modem reports, and if it's off by 2 or 3% it's no skin off my back.

1 Like

Thank you, you actually proved it for me.
Your calculations are wrong.
You expected that the system uptime should equal to the line uptime (hence the 1.0274 drift factor) and didn't factor in the time it takes to load other modules and the time it takes the line to sync, so 2-3 min between system uptime and line uptime is an acceptable variance.
That's why I said 1.024 is an acceptable median and should work for everyone.

1 Like

Not to put too fine a point on it, but you really need a better theory/model what and why is going on, please. That is quite a level of adhocery. But this should also be easy to test, if say after a few more days of continuous uptime the difference stays at a fixed ~3 minutes your hypothesis might have merit, but if the delta linearly increases with uptime, then it might be time to rethink the theory, no?

You are missing the point I was making, by a bit. This needs to hold for @takimata's line as well.
But, I understand from the terseness of your reply, that you are done discussing this issue. Fine with me, although it is a bit disappointing that we are seemingly completely missing a proper theory why there seems to be an intriguing base10 to base2 mismatch somewhere between the DSL chips (CPE or DSLAM) and the Linux side of Lantiq socs.
Also, if we actually trust the system walltime more, why are we not simply using that and ignore the DSL time?

I am not missing the point and I am not done discussing the issue.
The reason I made this thread is to discuss this issue and hear everyone's input.

You asked for proof that my hypothesis have merit and I gave it to you.
Delta holds, remain constant over a long period of time and across reboots.
The only variable is the modules loading time and line sync time which they hold no bearing.

Maybe a developer can answer that for you.

Some timer designs use 1000 ticks per second
Other timer designs use 1024 ticks per second

This fix is just correcting a wrong assumption about how many ticks are used by the driver.

It not rocket since and is very common.

Not having source or documentation for the driver is why it took so long to find.

The variance in the drift around 1.024 factor is due to natural drift between any two timers.

That can not be guessed it hard coded. That is the reason 1.024 will be the best that can be done to correct the drift

This is conjecture at this point, a compelling story, but really just that IMHO a story.

This is also what makes this a story/heuristic. IMHO the question really is, what is the rationale for correcting the returned number, based on our theory. A look at the lantiq driver source shows:

"/**
   PM synchronization modes.
*/
typedef enum
{
   /**
   Free synchronization.
   PM will be synchronized to its startup time. After start of the PM no further
   synchronization to an external clock source is done. */
   DSL_PM_SYNC_MODE_FREE = 0,
   /**
   System time synchronization.
   PM will be synchronized to the system time. The time base is derived from the
   DSL_SysTimeGet function (OS specific). */
   DSL_PM_SYNC_MODE_SYS_TIME = 1,
   /**
   External synchronization.
   PM will be synchronized to the external time network time.
   The host application should call the the function DSL_PM_15MinElapsedExtTrigger
   each 15 minutes. In addition the bOneDayElapsed parameter should be set
   accordingly. */
   DSL_PM_SYNC_MODE_EXTERNAL = 2
} DSL_PM_SyncModeType_t;"

If you would ask me, which you did not, I would say the 1024 timer story we came up with is not as clear cut as we seem to think...

I am not saying, that I know better, and ultimately the 1024 "correction" might be the best we can do. BUT I am sure that the least we should do is to report both the veridical counter as maintained by the dsl subsystem as well as the estimated corrected value.

That said, I only use the output of lantiq_dsl.sh for quick on-line checking of the status, so I do not really care about the truthfulness of the returned values (at least not, if the error is in the single digit percent range).

Nope, I measured the time since the dsl0 interface came up, according to the system logfile. The system itself was actually running for a day before that. Also, my system doesn't take 3 minutes to boot, and my line doesn't need 3 minutes to synchronize, neither would explain the discrepancy.

(I would appreciate if you didn't work off the assumption that I'm completely thick and just measuring anything to disprove you. I am not your enemy, even if you by now probably think I am.)

1 Like

Never crossed my mind that you are thick.
I am actually enjoying having an intelligent conversation with everyone who participated in this topic and getting the feeling that we are going somewhere.

I ran the numbers that you provided, line uptime multiplied by a drift factor of 1.0274 resulted in the system uptime that you provided.

1 Like

For what it's worth, My 'IPv4 Upstream' Connected time in the status page is 10d 13h 41m 52s, while the DSL uptime is 10d 7h 44m 8s, which is 913312 seconds vs. 891848. That is a ratio of 1.024067.

I have a ZyXEL P-2812HNU-F1.

That's not how it's calculated, the connected time is using system time clock so it's ticking at the same rate of 1024. while the dsl line uptime ticking @1000 hence the drift or lag we are having.
And if u want to do proper calculations it's system uptime not connection uptime - modules loading time - line sync time = dsl line uptime * drift factor.
if you adjust your drift factor so system uptime = dsl line uptime * drift factor then your are doing it wrong.
cause you didn't account for the modules loading time + line sysc time in which both variables usually account for 1~3 min difference between system uptime and dsl line uptime.


if u checked the screenshot I posted before, lookup the difference column. it's the time it takes the system to load other system modules after boot + line sync time which differ with each boot. once it was 1min 31sec another time it was 2min 5sec. what's important is that delta equals zero with each reading within a system uptime like it's shown in the difference column 2:05 delta remained the same across 4 readings until I rebooted again but delta remained equal to zero across the 1:36 readings for a drift factor of 1.024062.
It's not easy to grasp at first but I hope I explained it in an easy way. and if you have questions feel free to ask.

I can't use my system uptime, because that is 42 days. The DSL reset itself 10 days ago. But the WAN uptime should be equal to the DSL uptime. No need for estimations on module load times.

System uptime is not needed in anyway, it's just used as a reference.
Just do the modification listed in my previous post and you will know it's working when your connection uptime is shown as less than your DSL line uptime by a few seconds.
And let me know how it went.

Still going strong

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.