Time...

I have a small problem with RISC OS 5.22 under RPCEmu

DST and TimeZone is OK at boot, but after a few seconds the system act as if TimeZone was 0 and DST not active (configure options are still good). It seems to be a bad interaction with the SyncClock module.

ROS 5.20/5.21 did not have this problem.

DST and TimeZone is OK at boot, but after a few seconds the system act as if TimeZone was 0 and DST not active (configure options are still good). It seems to be a bad interaction with the SyncClock module.

ROS 5.20/5.21 did not have this problem.

What problem? The Greenwich Meridian runs through France (just West of Le Mans IIRC¹) now if you were talking about Eire not having -1 that would be different :)

¹ I believe this puts over 90% of France in timezone 0

Ha ha, very funny.

Seriously though, if timezone setting is indeed broken like this, I’ll hold off installing 5.22/23 on RPCEmu until it is fixed. I don’t need any more time related issues on RPCEmu. The nasty messing up of time stamps on reading from image files (SparkFS/StrongHelp) is more than enough… :(

Seriously though, if timezone setting is indeed broken like this, I’ll hold off installing 5.22/23 on RPCEmu until it is fixed.

OK. Seriously then:

The SyncClock module is the issue, there was a daylight saving issue noted some while back and having done a quick search for the response from Dave Symes he identified the fix

The original suggestion bounced around was deleting the module but the configuration change is the proper method. The emulator then uses the system time.

I created a small obey file in boot.predesk
| Don’t use SyncClock in RPCEmu
| Does nothing in other installs as this is a RPCEmu pseudo-module
*SyncClock 0

Ah, yes. I now remember reading that thread at the time and thinking it wouldn’t affect my setup as the host’s hardware clock is on UTC (as it should be).

Funny thing, memory. I find I easily forget about things I think I don’t need to remember… :)

Funny thing, memory. I find I easily forget about things I think I don’t need to remember… :)

Strange timing – a comment from my director¹ was “I don’t know how you remember all these things” I explained that I forget stuff like birthdays, including my own.

¹ Twice this week

The Greenwich Meridian runs through France (just West of Le Mans IIRC1) […] I believe this puts over 90% of France in timezone 0

Unfortunately this is both correct and incorrect. Yes, the meridian runs through France. But alas you have failed to take into account latitude and the fact that we’re talking about a wobbly spherical object.

Consider this:
http://www.timeanddate.com/worldclock/sunearth.html?iso=20150621T2010
This summer solstice. Ten past eight (UTC). Twilight for me (10pm local), daylight for you (9pm local). The dead of night for parts of Africa also on the meridian.

It’s a slightly different story the other side of the year at the winter solstice:
http://www.timeanddate.com/worldclock/sunearth.html?iso=20151222T1610
Ten past four (UTC and UK local) the UK is mostly in twilight while for me (ten past five local) it is just beginning. Spain is still in daylight. That part of Africa that was in darkness gets another hour and a half (or so) this time of year.

This summer solstice. Ten past eight (UTC). Twilight for me (10pm local), daylight for you (9pm local). The dead of night for parts of Africa also on the meridian.

Ah, the muddled thinking that equates available daylight to a specific time on the clock.

You’ll be talking about farmers needing specific sun positions to milk the cows next.

Ah, the muddled thinking that equates available daylight to a specific time on the clock.

No more or less muddled than suggesting that a country at a different latitude would be at the same timezone because it is in some otherwise arbitrary line. As I said, it’s a wobbly sphere we’re dealing with.

You’ll be talking about farmers needing specific sun positions to milk the cows next.

Judging by the magazine racks, the French are big on gardening according to the position of the moon, so I wouldn’t be surprised if there are farmers who think the sun should be in a specific position in the sky . . . and indeed if we refer to fixed time (like UTC and not CE(S)T), the sun is in specific places each hour – that’s how sun dials work. ;-)

No more or less muddled than suggesting that a country at a different latitude

Time has no fixed relationship with available daylight – ask the Hebrideans.

like UTC

Time zone 0. Groundhog time…

You’ll be talking about farmers needing specific sun positions to milk the cows next.

Last weeks news (-: http://tvnz.co.nz/national-news/cows-milked-in-darkness-could-help-insomniacs-video-6303148

Ah, yes. I now remember reading that thread at the time and thinking it wouldn’t affect my setup as the host’s hardware clock is on UTC (as it should be).

It will. Even in UK there is DST.

Indeed. DST doesn’t even make a difference. Time is off by 2 to 4 hours, depending on various settings. I guess the mention of ‘raw time’ in the other thread somehow led me to believe that syncing something to the host’s UTC should make sure RISC OS stays on UTC as well. Apparently not.

Unfortunately, switching SyncClock off (which is actually no different from removing the module – it becomes a piece of dead code) causes considerable time drift. So if I want to use this version of the OS, I’ll have to figure out exactly what has been changed here or write my own sync code.

Unfortunately, switching SyncClock off (which is actually no different from removing the module – it becomes a piece of dead code) causes considerable time drift.

Interesting, I don’t get the time drift. How long does your setup take to drift by a perceptible amount?

It starts almost immediately. Roughly one second per fifteen minutes. I let it run for four hours and it had gone up to fifteen seconds.
That may not seem much, but this machine (and RPCEmu) is on 24/7, so the difference will be around a minute and a half per day. I simply don’t accept that.

On a related note, it seems that if NetTime is unable to sync with the server it will give up but will not disable the slewing. I had this last night when my OLED failed to turn off at midnight. The last time sync was about 4pm, and the time was 23h35, so it managed to lose 25 minutes in eight hours. Hmm.

It starts almost immediately. Roughly one second per fifteen minutes.

Reproducible, if I run a few processor intensive tasks.

…or write my own sync code.

Adding a call to Territory_ReadCurrentTimeZone to SyncClock, after the call to Territory_ConvertOrdinalsToTime, and adding the value returned in R1 to the 5-byte value in the block before the call to Territory_SetTime seems to work. Anyone see any pitfalls here?

Now to find an easy way to identify the OS versions where this is necessary…

Now to find an easy way to identify the OS versions where this is necessary…

The first report from anyone of time sync issues was back in May 2014 on a version of 5.21.
A change to SyncClock obviously only affects RPCEmu installs.

Weirdest thing is, the change doesn’t seem to bother RISC OS 4.39, 5.21 (pre May 2014) or 6.20. I need to run more tests, but the quick check I did earlier shows that even with that extra bit of code in, the time is correctly synced. Which actually seems impossible. I would expect it to jump ahead with the same amount of time as it’s corrected with on 5.22/23. I’m missing something again… :(

I would expect it to jump ahead with the same amount of time as it’s corrected with on 5.22/23. I’m missing something again… :(

I have a vague recollection of Sprow / Steve/ Jeffrey explaining a change that meant that something previously ignored was now picked up¹. Could be muddling things, I’ve been to sleep a few times since.

¹ In which case the broken bit wouldn’t care which way round things were.

That could be it. I get the impression Territory_SetTime doesn’t use the buffer provided. It does use something, because if I kill SyncClock the time starts to drift at an alarming rate (this is on RO 4.39), but no matter what I put in the buffer – even totally ridiculous values – with SyncClock running, time is neatly kept in sync with the host’s clock.

On a related note, it seems that if NetTime is unable to sync with the server it will give up but will not disable the slewing. I had this last night when my OLED failed to turn off at midnight. The last time sync was about 4pm, and the time was 23h35, so it managed to lose 25 minutes in eight hours. Hmm.

Just to give this a prod again. I looked at my Pi’s time just now and it was incorrect. By several minutes. In the course of a day and a half. Not as bad as the above, but still unacceptable. This is a continuing issue, it is only today that I have chosen to post a message about it. The time is usually…incorrect, by numerous minutes.

*NetTime_Status
Current time:    Sunday, 2 August 2015 12:01:14.86
Status:          Sleeping
Last adjustment: 1 day 14 hours 45 minutes 58 seconds ago
Last delta:      4744.981076 seconds fast
Last server:     devrandom.pl
Last protocol:   SNTP
Poll interval:   30 minutes
*NetTime_Kick
*NetTime_Status
Current time:    Sunday, 2 August 2015 12:08:46.39
Status:          Sleeping
Last adjustment: 7 seconds ago
Last delta:      430.771774 seconds slow
Last server:     uk.pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes
*

I would report this as a bug, but I’m not getting any response.

Could somebody please either:

• Force NetTime to keep retrying on schedule and not throw in the towel

or:

• Instruct NetTime, if it gives up, to IMMEDIATELY cancel any slewing applied. The clock will then drift according to inaccuracies in timekeeping and not artificially entire minutes per day thanks to uncontrolled slewing.

I don’t know why NetTime is having problems, maybe “devrandom.pl” (however it managed to get that address…) just didn’t want to reply? I don’t know. What I do know is the mechanism designed to keep the clock accurate is making it worse.

I have ClockSync on my phone to tell me the NTP time, and according to that, RISC OS is already two and a half seconds slow in the course of writing this message. Was it trying to correct for the previous 430 seconds after having force-set the time to be correct? Bug, surely?

*NetTime_Kick
*NetTime_Status
Current time:    Sunday, 2 August 2015 12:23:43.63
Status:          Sleeping
Last adjustment: 0 seconds ago
Last delta:      2.739643 seconds slow
Last server:     uk.pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes
*

Force NetTime to keep retrying on schedule and not throw in the towel

It will keep retrying even if one of the servers is uncontactable (see ‘machine.c’ in NetTime, both the DNS and server failures end up back in Sleeping state on SHORT_TIMER).

Instruct NetTime, if it gives up, to IMMEDIATELY cancel any slewing applied. The clock will then drift according to inaccuracies in timekeeping and not artificially entire minutes per day thanks to uncontrolled slewing.

That should also be happening. There’s a default callback every hour that tries to set the time from the HW clock, but which has lower priority than NetTime, therefore for the (in your case) 30 mins while the NetTime slew is in progress the default callback will be declined (see rtclock_fg_callback in RTC).

One extra angle here is the Pi may not have a HW RTC (you don’t mention that), so RTC_Read might fail if the HAL says there’s no chip, or it ends up comparing itself with the soft clock which is of course drifting too as it runs off the same centisecond ticker. You can experiment from BASIC what the outcome of those questions will be, I suspect we need to jiggle the logic of rtclock_fg_callback so that there’s an ‘else’ to default it back to no slew.

There is an RTC – http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=4D-RaspberryPi-PowerControl-RealTimeClock-Temp-RTCT

If the module will try every hour, why the 1 day 14 hours (etc) since the last update, along with the very wrong time?