I thought perhaps I was confusing myself as, even with "transponder time", set in the Time menu, I was seeing NTP time adjustments every 30 minutes in the debug log. I thought, maybe, that some of my initial experiments with NTP server settings were somehow "stuck" in a file somewhere and enigma was ignoring that I wanted to use transponder time.
So, I flashed a clean Release 6.1 and started from there. No restores. Just setup my DVB-T and DVB-S and ran ABM and configured EPG. Left at default "transponder time" and left fake-hwclock as is. Didn't touch ntpdate-sync script.
I've established that an NTP time sync is done after enigma starts and every 30 minutes afterwards, irrespective of the fact that "transponder time" is set. Also, every 30 minutes the time is updated from the transponder. So you have both methods adjusting the clock. In addition, at 30 minutes past each hour, a cron job runs ntpdate-sync and adjusts the time also!
On my box (AX61), enigma starts about 17 seconds after the box is booted (real time of boot 16:20:00) and is using the timestamp from fake-hwclock (in this case 15:58:28 plus 15~17 seconds) . Approximately two seconds later this entry appears in the debug log
Code:
19.9117> 15:58:46.0095 [Console] command: /usr/bin/ntpdate-sync
. The messages file contains the following:
Code:
May 8 15:58:44 ax61 kern.debug kernel: yaffs: yaffs: MTD device 3 either not valid or unavailable
May 8 15:58:44 ax61 kern.info kernel: tntfs info (device mmcblk0p3, pid 2206): ntfs_fill_super(): fail_safe is enabled.
May 8 16:20:26 ax61 daemon.notice ntpdate[2064]: step time server 89.234.64.77 offset +1295.399109 sec
May 8 16:20:26 ax61 daemon.info automount[2089]: key "logs" not found in map source(s).
May 8 16:20:28 ax61 daemon.notice ntpdate[2258]: adjust time server 89.234.64.77 offset +0.000414 sec
May 8 16:30:01 ax61 authpriv.info crond[2291]: pam_unix(crond:session): session opened for user root(uid=0) by (uid=0)
May 8 16:30:01 ax61 cron.info CROND[2292]: (root) CMD (/usr/bin/ntpdate-sync silent)
May 8 16:30:10 ax61 daemon.notice ntpdate[2296]: adjust time server 161.53.78.71 offset +0.281029 sec
May 8 16:30:10 ax61 cron.info CROND[2291]: (root) CMDEND (/usr/bin/ntpdate-sync silent)
May 8 16:30:10 ax61 authpriv.info CROND[2291]: pam_unix(crond:session): session closed for user root
May 8 17:17:01 ax61 cron.info CROND[2402]: (root) CMD (cd / && run-parts /etc/cron.hourly)
May 8 17:17:01 ax61 cron.info CROND[2401]: (root) CMDEND (cd / && run-parts /etc/cron.hourly)
May 8 17:30:01 ax61 authpriv.info crond[2426]: pam_unix(crond:session): session opened for user root(uid=0) by (uid=0)
May 8 17:30:01 ax61 cron.info CROND[2427]: (root) CMD (/usr/bin/ntpdate-sync silent)
May 8 17:30:09 ax61 daemon.notice ntpdate[2431]: step time server 85.91.1.180 offset +1.159089 sec
May 8 17:30:09 ax61 cron.info CROND[2426]: (root) CMDEND (/usr/bin/ntpdate-sync silent)
May 8 17:30:09 ax61 authpriv.info CROND[2426]: pam_unix(crond:session): session closed for user root
There are two entries for ntpdate, one with PID 2064 and one with PID 2258. I am surmising that PID 2258 is the ntpdate-sync command issued at offset time 19.9117 and is setting (adjusting) the time to 16:20:28. The reason for this is that the ntpdate-sync script seems to take 8 or 9 seconds to run and this time would agree with the offset. The PID 2064 steps the time before this at 16:20:26 and there is a corresponding entry in the debug log:
Code:
25.1424> 16:20:26.6393 [NetworkTime] setting E2 time: 1652023226.6392548
I think this initial stepping of the time is coming from one of the networking checks (if-up.d) perhaps?
Subsequent ntp time updates are shown in the debug log (but not in the messages file) at 30 minute intervals.
Code:
< 1825.1441> 16:50:26.6410 [NetworkTime] setting E2 time: 1652025026.640918
< 3625.1450> 17:20:26.6419 [NetworkTime] setting E2 time: 1652026826.6418157
< 5425.1461> 17:50:27.8021 [NetworkTime] setting E2 time: 1652028627.8019857
The cronjob updates at 16:30 and 17:30 shown in the messages file above are not shown in the debug log.
That's all I can work out with my limited knowledge of the system!
I wonder why ntpdate-sync takes 8 or 9 seconds to complete, though? The actual ntp server check would take milliseconds usually. The longest delay I see on a ntp server grab is 28 ms.
Code:
pi@raspberrypiB:~ $ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.28.0 .GPS. 2 l 1 16 377 0.000 -7.488 2.023
o127.127.22.0 .PPS. 0 l - 16 377 0.000 0.001 0.004
3.ie.pool.ntp.o .POOL. 16 p - 512 0 0.000 0.000 0.004
+188.165.3.28 192.168.100.15 2 u 106 512 377 27.635 1.210 0.340
+89.234.64.77 193.120.142.71 2 u 270 512 377 10.171 -0.426 0.136
+162.159.200.1 10.52.9.36 3 u 403 512 377 10.739 -0.525 0.069
+85.91.1.180 217.53.21.92 2 u 507 512 377 10.200 -0.698 0.325
+149.202.156.97 192.168.100.15 2 u 267 512 377 28.075 1.425 0.303
+188.125.64.7 217.146.187.56 2 u 39 512 377 10.202 -0.395 0.082
+162.159.200.123 10.52.9.36 3 u 130 512 377 10.014 -0.881 0.156