Vix 5.1.006. Time wrong

[twol]

I already offered birdman to make the necessary changes to the recipe, so that OpenViX gets a synchronous NTP sync btw.


Some other possible optimization would be to have ntpdate-sync create/delete flagfiles that indicate success (or fail) of the sync.
Currently E2 simply assumes that the call to ntpdate-sync is successful and the time WAS synced, but in reality it might as well fail and even if it succeeds, it only WILL (in the future) adjust the clock, relative to the time of calling it.

Gesendet von meinem SM-N910F mit Tapatalk

Thanks, I appreciate the openness - I think that ongoing conversations are good, especially when they are open and everybody is aware of the issues and actions available

[Joe_90]

Sure - thanks for the open comments.

It doesn't really matter if the time is synced one or ten times in a minute at start up providing it doesn't result in the time stepping forward into the future which will mess up all sorts of record/zap timers. What is a concern to me is that there are checks to see if the box has been brought up by a powertimer but these checks take place very early (about 23 seconds into the debug log) seemingly before there is a current time set. The time comparison is with the stored fake-hwclock.data which is (should be) always in the past, so the criterion for comparison with the stored powertimer wake-up always results in a fail, therefore the box stays in tuned mode (not standby as intended).

I don't know what the solution to this is but all I know is that the behaviour of my box is not as intended. The hardware setup (USB WiFi stick and router) has not changed but the start-up process has.

[birdman]

The log entry shows this:
One stepping, two slewings and several seconds in between.

It might look strange inside the syslog, but it works.

No - it doesn't, as enigma2 start up with an incorrect time (in the past) and starts to run scheduling items with this incorrect time.

It's also very wrong for those who have multiple active interfaces.

If one wants to get rid of the multiple runs in short sequence, there is no other option as really making the ifup sync synchronous, but that would slow down boot for everybody.

I'd be more than happy to wait an extra 2 or 3s for the time to be correct before enigma2 started, which is what Vix was always doing until your changes went in.

[ccs]

I'd vote for an extra 3 seconds boot time if it meant a 100% reliable (and predictable) solution.

[Joe_90]

No - it doesn't, as enigma2 start up with an incorrect time (in the past) and starts to run scheduling items with this incorrect time.

It's also very wrong for those who have multiple active interfaces.

I'd be more than happy to wait an extra 2 or 3s for the time to be correct before enigma2 started, which is what Vix was always doing until your changes went in.

@birdman - if you have the time to code a foreground version of the initial time setup using ntpdate-sync I can test it extensively on my system and measure the delay on boot. The HD51 has a super-fast boot in any case as it takes no more than 35 seconds from completely powered off to initial channel tune. My GB Quad + takes about 90 seconds (IIRC) and the MB Twin takes forever...

[SpaceRat]

I'd vote for an extra 3 seconds boot time if it meant a 100% reliable (and predictable) solution.

The problem is: It's far more ... more like 15 seconds, some users even observed 30 sec.

[birdman]

@birdman - if you have the time to code a foreground version of the initial time setup using ntpdate-sync I can test it extensively on my system and measure the delay on boot. The HD51 has a super-fast boot in any case as it takes no more than 35 seconds from completely powered off to initial channel tune. My GB Quad + takes about 90 seconds (IIRC) and the MB Twin takes forever...

I posted one in this thread earlier, I think.
However, since running it from a sysvinit script rather than ifup changes it I'm about to produce a new version.

[birdman]

The problem is: It's far more ... more like 15 seconds, some users even observed 30 sec.

I've just timed ntpdate -q on some systems here. Given that most of the time is spent waiting for network responses the speed of the system shouldn't make much difference.
They took 6.7s.

But, if that worries you then you could use ntpclient (from

http://doolittle.icarus.com/ntpclient/

) which will set the system time in 0.067s. Not as much checking as ntpdate, but good enough....

[SpaceRat]

No - it doesn't, as enigma2 start up with an incorrect time (in the past) and starts to run scheduling items with this incorrect time.

Then there is a coding issue inside E2 itself
There is a variable m_time_ready somewhere and no time related checks should be done before it has been set <full stop>.

m_time_ready gets set by
- the very first DVB sync (If the box is set to use DVB time)
- the very first NTP sync done by E2 itself (If the box is set to use NTP time), with the quirk that it doesn't really check/wait for success, because m_time_ready gets set when ntpdate-sync gets started, not when ntpdate-sync really sets the time several seconds later.

Actually, it would help a lot if ntpdate-sync would maintain a flagfile, e.g. /tmp/time_synced so that E2 can really know if and when time has been NTP synced.
This would also be pre-requisite to make time syncing try NTP first and fall back to DVB if NTP fails (once or multiple times).

As a side note:
There is a known bug in some box drivers, which has been reported to the vendors, the HD51 is among the buggy ones.

On non-buggy boxes, the time from fake-hwclock is used for a very limited time span:

lrwxrwxrwx    1 root     root          22 Jan 14 13:48 S01fake-hwclock -> ../init.d/fake-hwclock
...
lrwxrwxrwx    1 root     root          21 Jan 14 13:48 S67stb-hwclock -> ../init.d/stb-hwclock

So fake-hwclock gets used in runlevel S from level 1 to 67 (max) only.
In level 67, the time from the front panel RTC (/proc/stb/fp/rtc) gets restored (Except when the box was fully powered off before), but most boxes will restore their RTC time even earlier, when their drivers load (level 5 or level 65).

Some box' drivers will not properly restore or report the FP RTC time though, but instead constantly report "0".

You can easily check yourself if your box is affected:

root@duo2 ~ # cat /proc/stb/fp/rtc
1516644354
root@quad4k ~ # cat /proc/stb/fp/rtc
1516644367
root@solo2 ~ # cat /proc/stb/fp/rtc
1516644379
root@sf4008 ~ # cat /proc/stb/fp/rtc
1516644396

None of the above is affected, they all have a proper time not later than in level 67 of runlevel S, far before E2 starts.

The driver big has been reported will hopefully be fixed ASAP.

[ccs]

.... ET10K

root@et10000:~# cat /proc/stb/fp/rtc
0

(I use DVB time.)

[birdman]

But, if that worries you then you could use ntpclient which will set the system time in 0.067s. Not as much checking as ntpdate, but good enough....

Or even less time...

Here I set the local clock to 10:00 (I've switched off the ntp daemon for the testing), wait 1s then run ntpclient. It sets the system time (correct to 1s comparing it visually with other systems and my radio-controlled clock) in <0.02s.

root@gmllaptop:/l......./ntpclient-2015# date 01231000; date; sleep 1; time ./ntpclient -h pool.ntp.org -c 1 -s; date
Tue 23 Jan 10:00:00 GMT 2018
Tue 23 Jan 10:00:00 GMT 2018
43121 66876.701   29653.0      5.8     -68.3      0.0  28267889

real    0m0.019s
user    0m0.000s
sys     0m0.004s
Tue 23 Jan 18:34:36 GMT 2018

[SpaceRat]

I posted one in this thread earlier, I think.
However, since running it from a sysvinit script rather than ifup changes it I'm about to produce a new version.

Actually I would be fine with making it a SysVinit-Script ... it's also a system service unit in systemd.

Tiny problem though:
It would need to start after networking and right after networking you can't be 100% sure networking is really fully up already (If networking doesn't get a DHCP reply within 3 seconds, it will background that, resulting in the very same problem).
If you make it synchronous after networking but before dropbear and telnet get started, you might end with the machine becoming unreachable ... so you need to put it after dropbear and telnet.
And actually SysVinit scripts are not supposed to be run synchronously (anymore). They only are run synchronously in yocto due to a yocto specific limitation (No support for boot concurrency) ... currently.

It would probably be much easier to let ntpdate-sync create the mentioned /tmp/ntp-synced flagfile and let E2 wait for that (rather then the pure ntpdate-sync call) in order to set m_time_ready = true.

Remember:
We are discussing a problem that
- occurs with boxes from one vendor only, because it's actually a bug inside the driver not allowing access to the FP RTC (Which E2 later also uses to monitor bad DVB syncs, so it's necessary anyways!).
- applies to a non-default setting, I would guess that ~90% of users just keep the default setting of "DVB sync".

[birdman]

But, if that worries you then you could use ntpclient (from

http://doolittle.icarus.com/ntpclient/

) which will set the system time in 0.067s. Not as much checking as ntpdate, but good enough....

However, ntpdate itself can be run with a -p1 option to only get one sample, and then takes 0.7 seconds on my et8000.

root@et8000:~# time ntpdate -q -p 1 ntp.ubuntu.com 
server 91.189.91.157, stratum 2, offset 0.000598, delay 0.11975
server 91.189.94.4, stratum 2, offset 0.000928, delay 0.04651
server 91.189.89.199, stratum 2, offset 0.001112, delay 0.04568
server 91.189.89.198, stratum 2, offset 0.001159, delay 0.04585
23 Jan 18:41:11 ntpdate[1397]: adjust time server 91.189.89.199 offset 0.001112 sec

real    0m0.740s
user    0m0.010s
sys     0m0.007s

That should be good enough.

[birdman]

It would need to start after networking and right after networking you can't be 100% sure networking is really fully up already (If networking doesn't get a DHCP reply within 3 seconds, it will background that, resulting in the very same problem).

So it could check that it has a route to the NTP server (which can be done without sending any packets - hopefully in python).

We are discussing a problem that
- occurs with boxes from one vendor only, because it's actually a bug inside the driver not allowing access to the FP RTC

Neither of my boxes has an RTC at all.

[SpaceRat]

But, if that worries you then you could use ntpclient

To annoy you even more:
We will go from bad to worse.

Latest development in oe-a 4.2 has revealed another, much bigger problem:
Some vendors advertise large flash sizes (up to 1024 MB), but actually for a lot of them you can only flash images with about 96MB in size, so with what's currently pre-loaded in most distros, just about any byte we add can render the image unflashable (via USB, online flash does work with larger images even on those boxes).

In addition, I got a new job lately, so I don't have 12h a day left for E2 anymore ...