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

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.

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

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

Spoke too soon, noticed drifting today.

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

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.

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

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?

Well, my Chumby Classic has started drifting as well.  Is there a link to where I can find the new firmware and control panel?