Lantiq DSL Modem - Line Uptime drift (lagging)

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.