Is http-time service required?

Help and Support Vero 4K / Vero 4K +
1

I stopped and disabled this service and enabled the ntp service to point to my local ntp servers.

All seems fine, but I just wanted to make sure that this service wasn’t explicitly required for any OSMC task.

2

I seem to recall that there are three phases to getting the correct time:

fake-hwclock - this is read from a file that is updated with date/time at various points.
http-time - this is a rough-and-ready time from an http source.
NTP - the most accurate but sometimes blocked by ISPs (I don’t know why, either) and also takes a bit longer before OSMC syncs with it

So http-time is rough ‘n’ ready - and is also obtained faster than NTP, so the log date/times will tend to be be more accurate than if you wait for OSMC to sync with NTP.

Or something to that effect. :wink:

1 Like
3

I have 4 local NTP servers that the Vero 4K gets the time from, and it’s syncing fine, so I’m not worried about that.

Why would the Vero 4K use fake-hwclock when there appears to be a real RTC (aml_vrtc)? There is a device at /dev/rtc0 and interface using files in the /sys/class/rtc/rtc0 directory. Also, ntp has no problem finding a local clock using “server 127.127.1.0”.

4

That’s an interesting observation. Perhaps @sam_nazarko can clarify the situation.

I can tell you that running hwclock doesn’t work, either for /dev/rtc or /dev/rtc0:

osmc@osmc:~$ sudo hwclock -r --debug
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc to wait for clock tick timed out...synchronization failed
osmc@osmc:~$ sudo hwclock -f /dev/rtc0 -r --debug
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc0 to wait for clock tick timed out...synchronization failed

Edit: No rtc in dmesg, either.

5

It looks like the kernel driver for the hardware isn’t installed, even though a driver does exist. hwclock uses the driver via ioctl.

Some low-level part of Linux does seem to know about the hardware though, as the following show UTC time ticking:

watch -n 1 cat /sys/class/rtc/rtc0/time

And, according to /sys/cclas/rtc/rtc/hctosys, the system time was set from this clock at boot.

6

Here’s something you can try. Add these two lines to /etc/rc.local

cat /etc/fake-hwclock.data > /tmp/clock.test
cat /sys/class/rtc/rtc0/time >> /tmp/clock.test

Looks to me like it’s not battery-backed.

7

The SoC supports an RTC, but we don’t utilise one.
Device Tree has an entry for RTC as it’s derived from a reference board. It will probably set your date to 1st January 2015, as defined:


        rtc{
                compatible = "amlogic, aml_vrtc";
                alarm_reg_addr = <0xc81000a8>;
                timer_e_addr = <0xc1109988>;
                init_date = "2015/01/01";
                status = "okay";
        };
10

So, is http-time service required for correct operation at boot? What about the fake-hwclock service?

12

The only thing to be careful of is time jumps. CEC does not like them, and last time I checked, still doesn’t use a monotonic clock which can cause problems.

I’d keep fake-hwclock on, but you might want to disable HTTP If you don’t want your device contacting external servers.

13

OK, I’ve disabled only http-time, and I don’t use CEC.

Mostly, I was worried about what would happen at boot if the time was wildly off because the system had been unplugged for a while. While it’s plugged in, NTP will keep it accurate.

14

You won’t have problems with continuous time. Only jumps cause an issue.

Sam