Topic: Drifting clock after working perfect for years

I have owned a Chumby classic since it was originally offered and it has served me very well over the years as my primary clock radio/alarm clock. Within the past month or so the clock has drifted and shows quite a bit behind the actual time after just a few hours though. I read threads from years ago that it was perhaps related to secured wireless encryption so I tried it on an unsecured WLAN with no better results. Anyone with ideas on how to fix would be appreciated.

Re: Drifting clock after working perfect for years

The same is happening to me. I tried updating the firmware (Have 1.7.3 now), with no results.

Tested pinging the ntp server, and executing ntpdate to a couple of the time servers listed in /etc/ntp.conf, both run OK. Any other ideas?

chumby:/etc# ping south-america.pool.ntp.org
PING south-america.pool.ntp.org (200.89.75.198): 56 data bytes
64 bytes from 200.89.75.198: seq=0 ttl=52 time=375.3 ms
64 bytes from 200.89.75.198: seq=1 ttl=52 time=342.6 ms
64 bytes from 200.89.75.198: seq=2 ttl=52 time=948.1 ms
64 bytes from 200.89.75.198: seq=3 ttl=52 time=352.7 ms
64 bytes from 200.89.75.198: seq=4 ttl=52 time=307.4 ms
64 bytes from 200.89.75.198: seq=5 ttl=52 time=769.1 ms
64 bytes from 200.89.75.198: seq=6 ttl=52 time=833.5 ms
64 bytes from 200.89.75.198: seq=7 ttl=52 time=737.3 ms
64 bytes from 200.89.75.198: seq=8 ttl=52 time=461.6 ms
64 bytes from 200.89.75.198: seq=9 ttl=52 time=384.7 ms
64 bytes from 200.89.75.198: seq=10 ttl=52 time=448.9 ms
64 bytes from 200.89.75.198: seq=11 ttl=52 time=440.0 ms

--- south-america.pool.ntp.org ping statistics ---
12 packets transmitted, 12 packets received, 0% packet loss
round-trip min/avg/max = 307.4/533.4/948.1 ms

chumby:/etc# ping pool.ntp.org
PING pool.ntp.org (170.210.222.2): 56 data bytes
64 bytes from 170.210.222.2: seq=0 ttl=56 time=433.5 ms
64 bytes from 170.210.222.2: seq=1 ttl=56 time=82.1 ms
64 bytes from 170.210.222.2: seq=2 ttl=56 time=86.2 ms
64 bytes from 170.210.222.2: seq=3 ttl=56 time=97.1 ms
64 bytes from 170.210.222.2: seq=4 ttl=56 time=103.8 ms
64 bytes from 170.210.222.2: seq=5 ttl=56 time=223.7 ms
64 bytes from 170.210.222.2: seq=6 ttl=56 time=125.2 ms
64 bytes from 170.210.222.2: seq=7 ttl=56 time=57.0 ms
64 bytes from 170.210.222.2: seq=8 ttl=56 time=128.0 ms
64 bytes from 170.210.222.2: seq=9 ttl=56 time=123.2 ms
64 bytes from 170.210.222.2: seq=10 ttl=56 time=105.8 ms
64 bytes from 170.210.222.2: seq=11 ttl=56 time=82.3 ms
64 bytes from 170.210.222.2: seq=12 ttl=56 time=103.3 ms
--- pool.ntp.org ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 57.0/134.7/433.5 ms

chumby:~# ntpdate pool.ntp.org
3 May 10:36:40 ntpdate[26701]: step time server 168.181.185.90 offset 755.484377 sec

chumby:/etc# ntpdate south-america.pool.ntp.org
3 May 10:39:33 ntpdate[26779]: step time server 201.217.3.85 offset 5.093600 sec

chumby:/etc# ntpdate pool.ntp.org
3 May 10:40:08 ntpdate[26780]: step time server 168.181.185.90 offset 0.994468 sec

chumby:/etc# ntpdate pool.ntp.org
3 May 10:41:00 ntpdate[26797]: step time server 168.181.185.90 offset 1.396551 sec

Re: Drifting clock after working perfect for years

I have up trying the WiFi workarounds and ended up just plugging in a USB Ethernet dongle... Seems to hold good time that way.

Re: Drifting clock after working perfect for years

I actually have a Control Panel in test that addresses the time drift problem.

If you like, I can get you a copy and you can try it to verify that it works.  It requires putting it on a dongle and booting with it.

Once it's verified, I can push it to production.  It's hard for me to test because my units keep the correct time.  I have tried manually setting the incorrect time then watching to see if it gets corrected, and that works, but I don't have a device that naturally drifts.

Re: Drifting clock after working perfect for years

My time is still drifting.  Has this been pushed to production?

Re: Drifting clock after working perfect for years

creep wrote:

My time is still drifting.  Has this been pushed to production?

Not yet - just added a couple more testers this week.  Contact me through support if you'd like to try it.

Re: Drifting clock after working perfect for years

Interestingly, I have a few Chumby "classics" that I purchased around 2008/2009 timeframe, which just recently started losing a lot of time.  I've relied on them as Internet clocks and having the "correct" time, because they sync with the Internet (ntp), but recently ALL OF THEM AT THE SAME TIME started drifting large amount of time ... sometimes several minutes per hour ... whereas up until recently, they were all reliable.

Although I'm perplexed as to how this started happening, given that nothing has changed ... but from this thread it sounds like I'm not the only one who is experiencing this?

I have the "classic" Chumbies with the leather case (tan, red, and blue ... one of each), which all have the 1.7.2 firmware.  I haven't touched the software on them in several years, and every time I hard boot one, the time goes back to normal, but then quickly drifts.

If there is a "fix", could you please send it to me?  Although I'd appreciate knowing what had changed to start causing all of my devices to start losing time all at the same time, and after all these years?  Thanks!

Re: Drifting clock after working perfect for years

dfilip wrote:

Interestingly, I have a few Chumby "classics" that I purchased around 2008/2009 timeframe, which just recently started losing a lot of time.  I've relied on them as Internet clocks and having the "correct" time, because they sync with the Internet (ntp), but recently ALL OF THEM AT THE SAME TIME started drifting large amount of time ... sometimes several minutes per hour ... whereas up until recently, they were all reliable.

Although I'm perplexed as to how this started happening, given that nothing has changed ... but from this thread it sounds like I'm not the only one who is experiencing this?

I have the "classic" Chumbies with the leather case (tan, red, and blue ... one of each), which all have the 1.7.2 firmware.  I haven't touched the software on them in several years, and every time I hard boot one, the time goes back to normal, but then quickly drifts.

If there is a "fix", could you please send it to me?  Although I'd appreciate knowing what had changed to start causing all of my devices to start losing time all at the same time, and after all these years?  Thanks!

FYI - I received a new control panel from Duane (2.8.87b4) which fixed this problem on three Chumby Classics.

Re: Drifting clock after working perfect for years

Seems like my chumby has been working fine since we set our clocks back on Nov. 6.  It's been a week and there has been no drifting.  I have not had to reset my time at all.  Previously I had to reset once a day.  Anybody else experiencing this?

Was a new control panel released or could there be a bug with DST on the chumby?

Re: Drifting clock after working perfect for years

Spoke too soon, noticed drifting today.

Re: Drifting clock after working perfect for years

I have been having the same problem. After a reboot the time is correct but it then starts drifting.

Re: Drifting clock after working perfect for years

I recently replaced my router (about a month ago) and my chumby hasn't drifted since the change.

Re: Drifting clock after working perfect for years

Has this come back for anyone recently?  I have tried clearing the cache and rebooting the chumby which helps for about a day, but then it seems to drift again (sometimes several minutes/hour!).

Re: Drifting clock after working perfect for years

4+ years later, I finally found this thread and... thank you, Duane!  I'd put my old Chumby One in the to-be-recycled pile several years back because even after adding an hourly ntpdate reset into the system cron, the clock was drifting badly enough to make it useless as an alarm clock.  But with the latest firmware and control panel installed, it's back to keeping perfect time.  Not bad for a weird device I bought a decade ago from a semi-defunct company. smile

Out of curiosity and if you remember: what was the bug?

Re: Drifting clock after working perfect for years

We don't really know what the bug is - the device works perfectly normally except for this - the "fix" is to simply sync with the time with the Internet more frequently.

Re: Drifting clock after working perfect for years

Is it possible that this is a side effect of the retention battery dying? When I had my Chumby open for unrelated surgery I noticed there's a battery in there. After a decade, it is incredibly still holding 3v, but it's surely getting weaker.  Indeed, there seems to be plenty of evidence that it isn't holding the time at all:

chumby-30-02-02:/sys/devices/platform/mmp-rtc/rtc/rtc0 # cat date
1970-01-04
chumby-30-02-02:/sys/devices/platform/mmp-rtc/rtc/rtc0 # cat time
22:28:01

The problem with this theory is that the RTC isn't used once the kernel kicks off.  Once the network is up and you usually hit an NTP server, set the linux clock and use the software clock instead of the RTC. Many devices will use NTP to try to steer the system clock against the RTC clock, but I don't see that happening here. The internal NTP does not seem to run and discipline the clock, so... who knows where it is going.

It seems like NTP should be running continuously instead of in one-shot mode. It would constantly account for drift and keep the system clock super-precise. However, this would be at the cost of 3M of memory, and I have to think that there was probably some reason this wasn't done in the first place. (Perhaps due to the D-Link kerfuffle over the NTP pool?)

There's also a bizarre little crypto processor in there with its own uptime clock...?

tl;dr: Replacing the battery inside a Chumby might help the time drift, but it technically shouldn't. Forcing ntp to run continuously instead of in one-shot mode would almost certainly help, but at what cost?

Re: Drifting clock after working perfect for years

There's supposed to be a cron job that fires once a day to reset the clock - one of the more common fixes for the drift is to make it fire more frequently.