getTime.sh giving inconsistent times

[dsandber]

I'm running getTime.sh every ten minutes as a cron job on Tiny Core 4.7.5

The time it's getting is jumping erratically forward and backward.  Here's a log I made that logs the time before and after getTime.sh is called:


Starts off normally:

Before Date Change: Sat Jun 21 02:00:57 UTC 2014
After Date Change : Sat Jun 21 02:00:58 UTC 2014

Before Date Change: Sat Jun 21 02:10:02 UTC 2014
After Date Change : Sat Jun 21 02:10:03 UTC 2014
.
.
.

[yikes]
Before Date Change: Sat Jun 21 02:30:01 UTC 2014
After Date Change: Sat Jun 21 03:26:49 UTC 2014

.
.
.

[yikes]
Before Date Change: Sat Jun 21 04:50:01 UTC 2014
After Date Change : Sat Jun 21 03:53:18 UTC 2014

[yikes]
Before Date Change: Sat Jun 21 04:00:01 UTC 2014
After Date Change : Sat Jun 21 04:56:47 UTC 2014

[yikes]
Before Date Change: Sat Jun 21 05:00:01 UTC 2014
After Date Change : Sat Jun 21 04:03:17 UTC 2014

[yikes]
Before Date Change: Sat Jun 21 04:10:01 UTC 2014
After Date Change : Sat Jun 21 05:06:47 UTC 2014

[yikes]
Before Date Change: Sat Jun 21 05:10:01 UTC 2014
After Date Change : Sat Jun 21 04:13:17 UTC 2014

[yikes]
Before Date Change: Sat Jun 21 04:20:01 UTC 2014
After Date Change : Sat Jun 21 05:16:47 UTC 2014

.
.
.

Any idea why this would happen?  Any idea how to fix this? 

[bmarkus]

Why are you running it in every 10 minutes?

Did you try 5.3.x version of piCore?

[dsandber]

I'm running it every ten minutes because I wanted to adjust for clock drift.  I could run it every day instead but it won't fix the fact that I'm getting the correct time +/- two hours!

It's installed in an embedded device that's across the world so I don't know how to upgrade it to the newest version of Tiny Core.  I  SSHed in and ran tce-update but everything was already up to date.

I can fix this by installing a newer version of busybox that has ntpd and then running that instead of getTime.sh.  But it seemed so strange to me that getTime.sh would be so inaccurate that I thought I should ask about it.

[bmarkus]

From you opening post it is not clear, wether the system date is correct and getTine.sh is setting a worong time or system clock date is false. Can you provides figures on your system clock drift?

In normal case I can't imagine a case where getTime.sh is required in every 10 minutes. Its purpose to setup time once at startup as RPI has no RTC built in. If system clock has an erratic drift or random jumps it indicates a hw or sw failure. In this case fix the machine.

If you just want to keep system time accurate, use ntpd but never use a radical time setup like getTime.sh

[dsandber]

Not sure I'm understanding.  If getTime.sh gets the time accurately, why would it matter if it was called once a week or once every ten minutes?

How can I provide the system drift information you want? 

The system clock is perhaps a bit inaccurate, but it's certainly not shifting by 1.5 hrs in a ten minute interval.  To me it seems like the script must be obtaining the wrong time, or obtaining the correct time and then setting the time incorrectly. 

Happy to provide any information you need to figure this out, just let me know what...

Also happy to drop it if you don't think it might be an issue for others -- the ntpd solution works well.

[dsandber]

Oh, one thing I forgot to say.  I have the same code deployed on two Raspberry Pis and the same thing is happening on both.  So it's unlikely to be a hardware issue.

[bmarkus]

getTime.sh in 4.x is using the now obsolate NIST DAYTIME service which is unrealible and not available in certain countries. However it doesn't explain to set a false time.

In current TC versions including piCore getTime.sh is using ntpservice; BusyBox ntp client now part of the base system. On 4.x you can use ntp.tcz extension from the 5.x repo.

An ntp client (ntpd) is adjusting system time smoothly, avoiding big jumps specially setting time back which may case issues for applications. It is why a brute force setting with getTime.sh must be avoided except initial setup.