The difference between Line Uptime and the other timers on the Overview page still matches the Handyman calculation. That is, the time in seconds shown by that timer needs to be multiplied by 1.024 to match the other timers. The System and Network uptime values have a different start time, by a few minutes, System first, then the DSL connection is established, and only then does the PPPoE for the Network start up.
I don't know for sure all three timers depend on the same internal "tick", the same quartz crystal, or if the Line Uptime uses a "tick" in the DSL signalling, but in my experience, the Handyman-observed ratio has worked on my hardware. He gave us 6 decimal places, which has been reported as being correct by several independent observers.
This is the sort of precision that you would expect from the clock on your wall, maybe not quite at the level of a clock synced to NTP, but adequate for human perception. You can look at the three figures and tell the difference between a power cut and the DSL dropping.
I have, incidentally, known the PPPoE go down without the DSL being affected. It's unusual, but they are different things.
And let me repeat this: thermal effects on quartz crystals need an extreme temperature variation to reach 20 seconds per day. We're talking halt-and-catch-fire levels as the maximum. The 1.024 factor is over 30 minutes per day.
These are two very distinct effects.
The changes between v19.07 and v20.02 change how that 1.024 factor can be applied. The new system is more efficient but, somewhere between the Lantiq chip and the Luci page displayed, a calculation is done, taking timer "ticks" and converting them to days, hours, minutes, and seconds.
I know this problem was noticed about a year ago. v20.02 has been in development a long time. I am surprised that nobody seems to know where a correction factor could be applied (this is not a question of whether it should be applied at user level or pre-installed).
I have doubts whether any firmware-blob will be found that fixes this problem. We are talking rather old hardware now. But if one is found, DOCUMENT IT! Tell everyone that they don't need to correct the drift problem.
Remember, I am using a version of OpenWRT which is specifically built for this hardware. The drift problem is not subtle (30+ minutes per day!) and it's not new.
If there is some magic firmware-blob that corrects the drift, but doesn't work on a Home Hub (Assume that's possible) the correction factor, clearly documented, can be applied just to the Home Hub. Could be a conditional, could be a clearly labelled line that is normally commented out, there are several ways of doing such things.
If I had a clock on my wall that drifted over 30 minutes per day, it had better have serious individual value.