• sweh
  • sweh
  • Blue Buddy
  • Offline
  • Registered: 2011-03-19
  • Posts: 194

Re: Clocks running 10 minutes slow overnight

I guess people who have massive problems with times could cheat.  Create a script /psp/myscripts/fix_time.sh

#!/bin/sh
if ps | grep -v grep | grep -q ntpd
then
        killall ntpd
fi
ntpdate pool.ntp.org

Then add a lineto /psp/crontabs/root

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /psp/myscripts/fix_time.sh

You may need to restart cron:

killall cron
/usr/sbin/crond -c /etc/cron/crontabs -S

This is "nasty" from a time perspective.  What we do is force the time to be correct every 5 minutes.  This may create a 'saw tooth' pattern on the clock.  However I don't think this would cause the Chumby software any problems since it tries to do this on a daily basis on the C1

Can someone more knowledge about Chumby verify that this is persistent across reboots?  And that it won't break the control panel? (eg cause a widget to remain on the screen permanently) :-)

  • From: New York City
  • Registered: 2008-05-21
  • Posts: 84

Re: Clocks running 10 minutes slow overnight

diamaunt wrote:

I don't know if 1.7.2 has all the stuff to run ntp, it might not.
you should be able to get it set right with
ntpdate 0.pool.ntp.org
then ntpd -g -x -f /psp/ntp.drift should *keep* it accurate.
unless ntpd dies for some reason.
normally, in 1.7.3, this crontab entry syncs time every day:
0 3 * * * /usr/chumby/scripts/sync_time.sh

you could program it to run hourly, by changing it to
0 * * * * /usr/chumby/scripts/sync_time.sh
if ntpd doesn't want to keep running.

I tried this from your suggestion quoted: 

ntpdate 0.pool.ntp.org

And received this "socket in use" message:

chumby:~# ntpdate 0.pool.ntp.org
31 May 09:02:12 ntpdate[6567]: the NTP socket is in use, exiting
chumby:~#

Is this a help, or shall I try this from the beginning of my SSH session?

Marc Silverman
New York City
SilverMarc.com | Chumbian.com
MY POWER TEAM: Macintosh, iPhone, Chumby, Geocaching, WheresGeorge.

SilverMarc's Website

  • From: Dallas, Tx
  • Registered: 2011-01-08
  • Posts: 1,262

Re: Clocks running 10 minutes slow overnight

SilverMarc wrote:

I tried this from your suggestion quoted: 

ntpdate 0.pool.ntp.org

And received this "socket in use" message:

chumby:~# ntpdate 0.pool.ntp.org
31 May 09:02:12 ntpdate[6567]: the NTP socket is in use, exiting
chumby:~#

Is this a help, or shall I try this from the beginning of my SSH session?

ok, that means that ntp is running, if your clock is off, then you need to kill ntp.

killall ntpd

then run the ntpdate command,

then you can restart ntpd as before.

the ntpdate should step your clock to be accurate

for instance: 

chumby:~# ntpdate pool.ntp.org
31 May 11:14:59 ntpdate[32588]: the NTP socket is in use, exiting
chumby:~# killall ntpd
chumby:~# ntpdate pool.ntp.org
31 May 11:15:14 ntpdate[32606]: adjust time server 216.129.104.26 offset 0.023247 sec
chumby:~# ntpd -g -f /psp/ntp.drift
chumby:~# date
Sat May 31 11:16:50 CDT 2014
chumby:~#
Cleaning up any loose bits and bytes.
  • From: Dallas, Tx
  • Registered: 2011-01-08
  • Posts: 1,262

Re: Clocks running 10 minutes slow overnight

sweh wrote:

Then add a lineto /psp/crontabs/root

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /psp/myscripts/fix_time.sh

You may need to restart cron:

killall cron
/usr/sbin/crond -c /etc/cron/crontabs -S

This is "nasty" from a time perspective.  What we do is force the time to be correct every 5 minutes.  This may create a 'saw tooth' pattern on the clock.  However I don't think this would cause the Chumby software any problems since it tries to do this on a daily basis on the C1

Can someone more knowledge about Chumby verify that this is persistent across reboots?  And that it won't break the control panel? (eg cause a widget to remain on the screen permanently) :-)

you *should* be able to edit the crontab just by doing 

crontab -e

and not have to kill and restart cron.   I think this works on classics and c1/i3,5 but not on the 8 units.  (their link is broken)    or, it may be that I fixed my c1 chumbys to work with crontab properly, I forget smile

Cleaning up any loose bits and bytes.
  • sweh
  • sweh
  • Blue Buddy
  • Offline
  • Registered: 2011-03-19
  • Posts: 194

Re: Clocks running 10 minutes slow overnight

IIRC, chumby "crontab" command assumes /var/spool/cron/crontab/root but the cron daemon is looking in /etc/cron/crontabs so you can't directly use "crontab -e".

chumby:~# crontab -l
crontab: can't open 'root': No such file or directory
chumby:~#
  • From: Dallas, Tx
  • Registered: 2011-01-08
  • Posts: 1,262

Re: Clocks running 10 minutes slow overnight

sweh, you're right, it's one of the things we need to put on duane's list to fix on the c1 and c8 firmware.

it works on the classic.

mount -o remount,rw /
ln -s /psp/crontabs /var/spool/cron/crontabs
mount -o remount,ro /

might have to rm /var/spool/cron/crontabs before the link.

I have a vague memory of fixing that years ago.

Cleaning up any loose bits and bytes.
  • sweh
  • sweh
  • Blue Buddy
  • Offline
  • Registered: 2011-03-19
  • Posts: 194

Re: Clocks running 10 minutes slow overnight

On a C1 we don't need to do any remounting

rmdir /var/spool/cron/crontabs
ln -s /psp/crontabs /var/spool/cron

However that won't carry over a reboot because /var is tmpfs on a C1.  I guess a boot script kludge, maybe in /psp/rfs1/userhook0, would do the job.  /var has been mounted well before that hook is called  (indeed rcS.background makes the empty /var/spool/cron/crontabs directory!)

  • From: Dallas, Tx
  • Registered: 2011-01-08
  • Posts: 1,262

Re: Clocks running 10 minutes slow overnight

if you mount / rw, then you can change /var/spool/cron so it persists across reboots, smile 

modi:~# ls -l /var/spool/cron
total 0
lrwxrwxrwx    1 root     root            13 May 21 08:40 crontabs -> /psp/crontabs
Cleaning up any loose bits and bytes.
  • sweh
  • sweh
  • Blue Buddy
  • Offline
  • Registered: 2011-03-19
  • Posts: 194

Re: Clocks running 10 minutes slow overnight

Not on a C1; /var is tmpfs

# df /var
Filesystem                Size      Used Available Use% Mounted on
none                     32.0M     72.0K     31.9M   0% /var

From /etc/init.d/rcS.background

# Mount extra temp partitions.
mount /var
mount /mnt

# Create some required dirs.
mkdir -p /var/lock/subsystem
mkdir -p /var/run
mkdir -p /var/log
mkdir -p /var/empty
mkdir -p /var/spool/cron/crontabs
mkdir -p /tmp/chumby

60 Reply by sweh (edited by sweh 2014-05-31 17:59:28)

  • sweh
  • sweh
  • Blue Buddy
  • Offline
  • Registered: 2011-03-19
  • Posts: 194

Re: Clocks running 10 minutes slow overnight

(A permanent fix would be to modify rcS.background so that it does 'mkdir -p /var/spool/cron ; ln -s /psp/crontabs /var/spool/cron' instead of the mkdir.  That's one potential way Duane can fix the firmware without needed to recompile the crontab command).

  • From: Dallas, Tx
  • Registered: 2011-01-08
  • Posts: 1,262

Re: Clocks running 10 minutes slow overnight

well, it seems that I'm just getting things wrong all over the place smile

do you have an alias in root's .profile?

alias crontab="crontab -c /psp/crontabs"

or did I put that in mine *scratching head*

Cleaning up any loose bits and bytes.
  • sweh
  • sweh
  • Blue Buddy
  • Offline
  • Registered: 2011-03-19
  • Posts: 194

Re: Clocks running 10 minutes slow overnight

That alias isn't on either of my C1s

  • andom
  • New member
  • Offline
  • Registered: 2009-06-20
  • Posts: 3

Re: Clocks running 10 minutes slow overnight

sweh wrote:

I guess people who have massive problems with times could cheat.  Create a script /psp/myscripts/fix_time.sh

#!/bin/sh
if ps | grep -v grep | grep -q ntpd
then
        killall ntpd
fi
ntpdate pool.ntp.org

Then add a lineto /psp/crontabs/root

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /psp/myscripts/fix_time.sh

You may need to restart cron:

killall cron
/usr/sbin/crond -c /etc/cron/crontabs -S

This is "nasty" from a time perspective.  What we do is force the time to be correct every 5 minutes.  This may create a 'saw tooth' pattern on the clock.  However I don't think this would cause the Chumby software any problems since it tries to do this on a daily basis on the C1

Can someone more knowledge about Chumby verify that this is persistent across reboots?  And that it won't break the control panel? (eg cause a widget to remain on the screen permanently) :-)


Since I had the same problem (two chumby classic losing half an hour per day) I would like to add here what I found (firmware 1.7.3):
Ntpd seems not to work correctly (offset becomes larger over time), so maybe this is the reason why they implemented the sync_time.sh script

The script /usr/chumby/scripts/sync_time.sh is scheduled in crontab to run just once per day (3 am). I found that changing the crontab entry to run it every 5 minutes helps.

  • Registered: 2009-11-28
  • Posts: 73

Re: Clocks running 10 minutes slow overnight

Okay, this is driving me a little crazy.

I've got an original chumby classic, which was losing time constantly.  So I read through this thread, got the gist of things, and enabled ntp.  Or so I thought.

Anyway, here's my /psp/rfs/rcS file:

chumby:/psp/rfs1# cat rcS
#! /bin/sh

echo "Starting udevd as daemon"
/sbin/udevd --daemon

# wait for USB subsystem to finish loading
/usr/chumby/scripts/wait_for_usb

mkdir -p /mnt/usb
mount /mnt/usb || rmdir /mnt/usb

# run any scripts for debug configuration of chumby from a USB thumb drive
if [ -x /mnt/usb/userhook0 ]; then
  # Run in context of current script so it can change PATH and other
  # environment variables.
  . /mnt/usb/userhook0
fi
# run any scripts for debug configuration of chumby from /psp
if [ -x /psp/rfs1/userhook0 ]; then
  # Run in context of current script so it can change PATH and other
  # environment variables.
  . /psp/rfs1/userhook0
fi

# Display the chumby logo
unzip -p /bitmap/chumby_logo.zip >/dev/fb

# Start mountmon
echo "Starting mountmon as daemon"
mountmon --daemon

# link crontabs
ln -s /etc/cron/crontabs/root /var/spool/cron/crontabs/root

hwversion=`/usr/chumby/scripts/chumby_version -h`

if [ "$hwversion" == "3.8" ]; then
    # touch screen
    insmod /drivers/chumby-tsc2100.ko version038=1

    # chumby sensor driver
    insmod /drivers/chumby_sense1.ko version038=1
else
    # touch screen
    insmod /drivers/chumby-tsc2100.ko

    # chumby sensor driver
    insmod /drivers/chumby_sense1.ko
fi

# check if this is the first time that chumby has been run and set
# touch screen settings
if [ -f /psp/firsttime ]; then
    FIRSTTIME=`cat /psp/firsttime`
    if [ "$FIRSTTIME" -eq "1" ]; then
        if [ "$hwversion" == "3.8" ]; then
            echo -n "101,3909,3984,-3815" >/psp/ts_settings
        else
            echo -n "136,3768,3835,-3540" >/psp/ts_settings
        fi
    fi
fi

# restore touch screen settings from /psp if present
if [ -e /psp/ts_settings_backup ]; then
    cp /psp/ts_settings_backup /psp/ts_settings
    rm /psp/ts_settings_backup
fi

# restore touch screen settings from USB if present
if [ -e /mnt/usb/ts_settings ]; then
    cp /mnt/usb/ts_settings /psp
fi


# chumby udma driver
insmod /drivers/chumby_udma.ko

echo 0 > /proc/sys/sense1/spkmute
usleep 500000
echo 1 > /dev/dsp
echo 1 > /proc/sys/sense1/spkmute
usleep 500000

# Initially disable touch click
echo 0 > /proc/chumby/touchscreen/touchclick

# sound drivers
insmod /drivers/snd-rawmidi.ko
insmod /drivers/snd-seq-midi.ko
insmod /drivers/snd-usb-lib.ko
insmod /drivers/snd-hwdep.ko
insmod /drivers/snd-usb-audio.ko
insmod /drivers/usbhid.ko


# set the speaker mute based on previous speaker settings
if [ -e /psp/mute ]; then
    echo -n "Restoring mute setting: "
    chumby_set_volume --master_mute `cat /psp/mute`
fi

# set the volume
if [ -e /psp/volume ]; then
    echo -n "Restoring volume setting: "
    chumby_set_volume --master_volume `cat /psp/volume`
fi

# set the speaker panning
if [ -e /psp/pan ]; then
    echo -n "Restoring speaker pan setting: "
    chumby_set_volume --master_panning `cat /psp/pan`
fi


# chumby aux timer
insmod /drivers/chumby_timer.ko
mknod /dev/timerx c `cat /proc/devices |awk '/timer/ {print $1}'` 0
mknod /dev/timerm c `cat /proc/devices |awk '/timer/ {print $1}'` 1

# chumby accelerometer
insmod /drivers/chumby_accel.ko
mknod /dev/accel c `cat /proc/devices |awk '/accel/ {print $1}'` 0

# chumby switch
mknod /dev/switch c `cat /proc/devices |awk '/switch/ {print $1}'` 0

# chumby daughter card id
mknod /dev/dcid c `cat /proc/devices |awk '/dcid/ {print $1}'` 0

# chumby udma
mknod /dev/udma c `cat /proc/devices |awk '/udma/ {print $1}'` 1

# After kernel modules have been loaded, trigger events for usb hotplug devices
echo "Triggering udevd events for usb devices"
udevtrigger --subsystem-match=usb_device --subsystem-match=block

# start multi-purpose monitor (headphone jack, battery level, network status)
headphone_mgr &

# start and fork opening animation
if [ ! -f /psp/UPDATE1 ]; then
    /usr/chumby/scripts/start_opening_anim &
fi

ifconfig lo 127.0.0.1

# load wired Ethernet drivers
insmod /drivers/usbnet.ko
insmod /drivers/asix.ko

# load wifi driver
insmod /drivers/rt73.ko

#
# start the network
#
if [ -e /mnt/usb/network_config ]; then
    cp /mnt/usb/network_config /psp
    /usr/chumby/scripts/start_network
else
    if [ -e /psp/network_config ]; then
        /usr/chumby/scripts/start_network
    else
        ifconfig rausb0 up
    fi
fi

# run any scripts for debug configuration of chumby from a USB thumb drive
if [ -x /mnt/usb/userhook1 ]; then
  /mnt/usb/userhook1
fi
# run any scripts for debug configuration of chumby from /psp
if [ -x /psp/rfs1/userhook1 ]; then
  /psp/rfs1/userhook1
fi

# run any scripts for debug configuration of chumby from a USB thumb drive
if [ -x /mnt/usb/debugchumbyearly ]; then
  /mnt/usb/debugchumbyearly
fi

# attempt to restore time based on the crypto processor's uptime counter
/usr/chumby/scripts/restore_time

# sync time if the network is running
running=`ifconfig rausb0 |grep RUNNING`
if [ -z "$running" ]; then
    echo "Network is down.  Network time not updated."
else
    /usr/chumby/scripts/sync_time.sh -b &
fi

# webserver
/usr/sbin/httpd -h /www

# Check for hostname
HOSTNAME="$(hostname)"
if [ "${HOSTNAME}" = "chumby" ]
then
  echo "Creating default hostname: "
  HOSTNAME="$(default_hostname)"
  [ "${HOSTNAME}" ] && echo "${HOSTNAME}" >/psp/hostname
  echo "New hostname: ${HOSTNAME}"
fi

#zeroconf - howl
echo "Starting zeroconf service"
PATH=/usr/chumby/scripts:/usr/sbin:${PATH} service_control zeroconf start

# Start howl daemon
echo "Starting chumbhowld service"
PATH=/usr/chumby/scripts:${PATH} service_control chumbhowld start

# start crond
/usr/sbin/crond -c /etc/cron/crontabs

# make sure that the opening animation has completed before proceeding
if [ ! -f /psp/UPDATE1 ]; then
    /usr/chumby/scripts/wait_for_opening
fi

# check to see if an update of RFS2 is needed
if [ -f /psp/UPDATE1 ]; then
    UPDATE_URL=`cat /psp/UPDATE1`

    # check to see if there was a problem connecting to the network
    if [ ! -e /tmp/chumby/network_status.xml ]; then
        network_errors=`/usr/chumby/scripts/network_status.sh |grep error`
    else
        network_errors=`cat /tmp/chumby/network_status.xml |grep error`
    fi

    if [ -z "$network_errors" -o "$UPDATE_URL" == "update1" ]; then
        # update if there are no network errors or updating via USB
        echo "Updating RFS2.."
        if [ -e /psp/UPDATE1_MD5 ]; then
            /usr/chumby/scripts/update.sh `cat /psp/UPDATE1` NETWORK `cat /psp/UPDATE1_MD5` >/tmp/update1.log 2>&1
            if [ "$?" -eq "0" ]; then
                # RFS2 update succeeded, remove flags
                rm -f /psp/UPDATE1
                if [ -e /psp/save_update1 ]; then
                    rm -f /psp/save_update1
                fi
            fi
        else
            /usr/chumby/scripts/update.sh `cat /psp/UPDATE1` >/tmp/update1.log 2>&1
            if [ "$?" -eq "0" ]; then
                # RFS2 update succeeded, remove flags
                rm -f /psp/UPDATE1
                if [ -e /psp/save_update1 ]; then
                    rm -f /psp/save_update1
                fi
            fi
        fi
    else
        # set save_update1 to ensure that /psp/UPDATE1 is not removed when setting to factory defaults
        touch /psp/save_update1
    fi
fi

# set paranoid boot flag/semaphore
echo "Clearing paranoid boot flag"
flash_eraseall /dev/mtd7
nandwrite /dev/mtd7 /usr/chumby/msp_00_64k_no_oob.bin 0x70000

# start resident portion of btplay
echo "Starting btplay daemon"
/usr/sbin/btplayd >/dev/null 2>&1 &

# run any scripts for debug configuration of chumby from a USB thumb drive
if [ -x /mnt/usb/userhook2 ]; then
  /mnt/usb/userhook2
fi
# run any scripts for debug configuration of chumby from /psp
if [ -x /psp/rfs1/userhook2 ]; then
  /psp/rfs1/userhook2
fi

# run any scripts for debug configuration of chumby from a USB thumb drive
if [ -x /mnt/usb/debugchumby ]; then
  /mnt/usb/debugchumby
fi

/usr/chumby/scripts/start_intro

# start chumby backup alarm daemon
/bin/chumbalarmd

if [ -e /psp/missed_alarm ]; then
    # chumbalarmd has detected that an alarm was missed, allow chumbalarmd to fire the backup alarm
    # start_control_panel will be called automatically from chumbalarmd
    rm /psp/missed_alarm
    sync
else
    # henry - enable logins
    /usr/chumby/scripts/start_control_panel >/dev/null 2>&1 &
fi

/usr/bin/ntpdate pool.ntp.org

ntpd -g -x -f /psp/ntp.drift

So I reboot, and the time seems more or less correct.  But after a few days, the clock has drifted upward of 10m slow again.  And here's where it gets just downright weird:

chumby:/psp/rfs1# ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 tock9.usshc.com .GPS.            1 u  114  128  377   62.065  440867. 8382.70
 resolver1.level .STEP.          16 u    - 1024    0    0.000    0.000   0.000
 time-c.nist.gov .ACTS.           1 u   32  128  377   23.050  449602. 9762.22
 clock.xmission. .GPS.            1 u   84  128  377   93.089  441734. 8337.62

chumby:/psp/rfs1# ls -al /psp/ntp.drift
ls: /psp/ntp.drift: No such file or directory

So while it sees some ntp peers, it hasn't actually locked to any of them, and it's now ~440 seconds off from all of the stratum 1 clocks it sees, except for resolver1.level3.net, which it sees as being stratum 16?  And it's not actually writing out its drift file?

What the heck?  Is the hardware clock losing time so fast that ntpd can't apply discipline to it?

  • Registered: 2009-11-28
  • Posts: 73

Re: Clocks running 10 minutes slow overnight

I updated the ntp config to write out a log file to /psp/ntp.log, and herein it gets interesting:

21 May 09:02:05 ntpd[19050]: logging to file /psp/ntp.log
21 May 09:02:05 ntpd[19050]: precision = 30.000 usec
21 May 09:02:05 ntpd[19050]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
21 May 09:02:05 ntpd[19050]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
21 May 09:02:05 ntpd[19050]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
21 May 09:02:05 ntpd[19050]: Listening on interface #2 rausb0, 192.168.1.187#123 Enabled
21 May 09:02:05 ntpd[19050]: kernel time sync status 0040
21 May 09:02:05 ntpd[19050]: frequency initialized 0.000 PPM from /psp/ntp.drift
21 May 09:02:05 ntpd[19050]: frequency initialized 0.000 PPM from /psp/ntp.drift
21 May 13:07:01 ntpd[19050]: synchronized to 198.60.22.240, stratum 1
21 May 13:08:10 ntpd[19050]: synchronized to 204.2.134.164, stratum 2
21 May 13:13:29 ntpd[19050]: synchronized to 198.60.22.240, stratum 1
21 May 13:13:29 ntpd[19050]: frequency error 1048 PPM exceeds tolerance 500 PPM
21 May 13:16:15 ntpd[19050]: synchronized to 204.2.134.164, stratum 2
21 May 13:16:15 ntpd[19050]: frequency error 1552 PPM exceeds tolerance 500 PPM
21 May 13:18:52 ntpd[19050]: no servers reachable
21 May 14:35:16 ntpd[19050]: synchronized to 198.60.22.240, stratum 1
21 May 14:35:16 ntpd[19050]: frequency error 1754 PPM exceeds tolerance 500 PPM
21 May 14:40:14 ntpd[19050]: no servers reachable
21 May 14:58:35 ntpd[19050]: synchronized to 198.60.22.240, stratum 1
21 May 14:58:35 ntpd[19050]: frequency error 1784 PPM exceeds tolerance 500 PPM
21 May 14:59:55 ntpd[19050]: no servers reachable
21 May 15:20:05 ntpd[19050]: synchronized to 129.250.35.251, stratum 2
21 May 15:20:05 ntpd[19050]: frequency error 1842 PPM exceeds tolerance 500 PPM
21 May 15:21:09 ntpd[19050]: frequency error 1844 PPM exceeds tolerance 500 PPM
21 May 15:22:14 ntpd[19050]: synchronized to 198.60.22.240, stratum 1
21 May 15:23:36 ntpd[19050]: frequency error 879 PPM exceeds tolerance 500 PPM
21 May 15:24:42 ntpd[19050]: no servers reachable
21 May 17:05:47 ntpd[19050]: synchronized to 209.118.204.201, stratum 2
21 May 17:05:47 ntpd[19050]: frequency error 2141 PPM exceeds tolerance 500 PPM
21 May 17:09:03 ntpd[19050]: synchronized to 204.2.134.164, stratum 2
21 May 17:09:03 ntpd[19050]: frequency error 1782 PPM exceeds tolerance 500 PPM
21 May 17:10:44 ntpd[19050]: frequency error 2144 PPM exceeds tolerance 500 PPM
21 May 17:11:57 ntpd[19050]: synchronized to 198.60.22.240, stratum 1
21 May 17:11:57 ntpd[19050]: frequency error 2146 PPM exceeds tolerance 500 PPM
21 May 17:15:07 ntpd[19050]: no servers reachable

Note the timestamps!  ntpd starts up, reads ntp.drift and then four hours later finally decides that it's found a clock to sync with, by which time the system clock has drifted so far that it's not actually willing to make the adjustment.  Bizarre.

So let's run in debug mode?

chumby:/psp# ntpd -g -f /psp/ntp.drift -x -l /psp/ntp.log -d
ntpd 4.2.4p5@1.1541 Wed Feb 10 00:25:11 UTC 2010 (1)
addto_syslog: logging to file /psp/ntp.log
addto_syslog: logging to file /psp/ntp.log
addto_syslog: precision = 30.000 usec
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
addto_syslog: no IPv6 interfaces found
addto_syslog: no IPv6 interfaces found
addto_syslog: Listening on interface #1 lo, 127.0.0.1#123 Enabled
addto_syslog: Listening on interface #2 rausb0, 192.168.1.187#123 Enabled
local_clock: time 0 offset 0.000000 freq 0.000 state 0
addto_syslog: kernel time sync status 0040
addto_syslog: frequency initialized 500.000 PPM from /psp/ntp.drift
addto_syslog: frequency initialized 500.000 PPM from /psp/ntp.drift
peer_crypto_clear: at 0 next 0 assoc ID 41161
peer_clear: at 0 next 1 assoc ID 41161 refid INIT
newpeer: 192.168.1.187->204.235.61.9 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
peer_crypto_clear: at 0 next 0 assoc ID 41162
peer_clear: at 0 next 2 assoc ID 41162 refid INIT
newpeer: 192.168.1.187->206.209.110.2 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
peer_crypto_clear: at 0 next 0 assoc ID 41163
peer_clear: at 0 next 3 assoc ID 41163 refid INIT
newpeer: 192.168.1.187->198.55.111.5 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
peer_crypto_clear: at 0 next 0 assoc ID 41164
peer_clear: at 0 next 4 assoc ID 41164 refid INIT
newpeer: 192.168.1.187->204.2.134.163 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
local_clock: time 0 offset 0.000000 freq 500.000 state 1
report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
transmit: at 1 192.168.1.187->204.235.61.9 mode 3
auth_agekeys: at 1 keys 1 expired 0
timer: interface update
addto_syslog: no IPv6 interfaces found
addto_syslog: no IPv6 interfaces found
receive: at 1 192.168.1.187<-204.235.61.9 mode 4 code 1 auth 0
peer 204.235.61.9 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
clock_filter: n 1 off 5.118948 del 0.067689 dsp 7.937516 jit 0.000031, age 0
transmit: at 2 192.168.1.187->206.209.110.2 mode 3
receive: at 2 192.168.1.187<-206.209.110.2 mode 4 code 1 auth 0
peer 206.209.110.2 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
clock_filter: n 1 off 5.148208 del 0.057118 dsp 7.937517 jit 0.000031, age 0
transmit: at 3 192.168.1.187->198.55.111.5 mode 3
receive: at 3 192.168.1.187<-198.55.111.5 mode 4 code 1 auth 0
peer 198.55.111.5 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
clock_filter: n 1 off 5.170437 del 0.112604 dsp 7.937516 jit 0.000031, age 0
transmit: at 4 192.168.1.187->204.2.134.163 mode 3
receive: at 4 192.168.1.187<-204.2.134.163 mode 4 code 1 auth 0
peer 204.2.134.163 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)
clock_filter: n 1 off 5.204724 del 0.123038 dsp 7.937517 jit 0.000031, age 0
auth_agekeys: at 60 keys 1 expired 0
transmit: at 66 192.168.1.187->206.209.110.2 mode 3
receive: at 66 192.168.1.187<-206.209.110.2 mode 4 code 1 auth 0
clock_filter: n 2 off 6.632560 del 0.044467 dsp 3.937765 jit 1.484352, age 0
transmit: at 67 192.168.1.187->204.235.61.9 mode 3
receive: at 67 192.168.1.187<-204.235.61.9 mode 4 code 1 auth 0
clock_filter: n 2 off 6.649085 del 0.056454 dsp 3.937772 jit 1.530137, age 0
transmit: at 69 192.168.1.187->198.55.111.5 mode 3
receive: at 69 192.168.1.187<-198.55.111.5 mode 4 code 1 auth 0
clock_filter: n 2 off 6.687666 del 0.107122 dsp 3.937772 jit 1.517229, age 0
transmit: at 70 192.168.1.187->204.2.134.163 mode 3
receive: at 70 192.168.1.187<-204.2.134.163 mode 4 code 1 auth 0
clock_filter: n 2 off 6.734952 del 0.106801 dsp 3.937772 jit 1.530228, age 0
auth_agekeys: at 120 keys 1 expired 0
transmit: at 129 192.168.1.187->206.209.110.2 mode 3
receive: at 129 192.168.1.187<-206.209.110.2 mode 4 code 1 auth 0
clock_filter: n 3 off 8.009031 del 0.077609 dsp 1.938004 jit 2.244881, age 0
transmit: at 132 192.168.1.187->204.235.61.9 mode 3
receive: at 132 192.168.1.187<-204.235.61.9 mode 4 code 1 auth 0
clock_filter: n 3 off 8.082046 del 0.056280 dsp 1.938018 jit 2.327373, age 0
transmit: at 133 192.168.1.187->198.55.111.5 mode 3
transmit: at 133 192.168.1.187->204.2.134.163 mode 3
receive: at 133 192.168.1.187<-198.55.111.5 mode 4 code 1 auth 0
clock_filter: n 3 off 8.119555 del 0.118584 dsp 1.938012 jit 2.318146, age 0
receive: at 133 192.168.1.187<-204.2.134.163 mode 4 code 1 auth 0
clock_filter: n 3 off 8.120716 del 0.137090 dsp 1.938007 jit 2.282909, age 0
transmit: at 194 192.168.1.187->206.209.110.2 mode 3
receive: at 194 192.168.1.187<-206.209.110.2 mode 4 code 1 auth 0
clock_filter: n 4 off 9.660483 del 0.087679 dsp 0.938195 jit 3.279037, age 0
transmit: at 197 192.168.1.187->204.2.134.163 mode 3
receive: at 197 192.168.1.187<-204.2.134.163 mode 4 code 1 auth 0
clock_filter: n 4 off 9.770656 del 0.107652 dsp 0.938190 jit 3.305830, age 0
transmit: at 198 192.168.1.187->204.235.61.9 mode 3
receive: at 198 192.168.1.187<-204.235.61.9 mode 4 code 1 auth 0
clock_filter: n 4 off 9.774090 del 0.038323 dsp 0.938208 jit 3.381273, age 0
transmit: at 199 192.168.1.187->198.55.111.5 mode 3
receive: at 199 192.168.1.187<-198.55.111.5 mode 4 code 1 auth 0
clock_filter: n 4 off 9.801782 del 0.088111 dsp 0.938205 jit 3.365361, age 0
auth_agekeys: at 240 keys 1 expired 0
transmit: at 259 192.168.1.187->206.209.110.2 mode 3
receive: at 259 192.168.1.187<-206.209.110.2 mode 4 code 1 auth 0
clock_filter: n 5 off 11.331488 del 0.067640 dsp 0.438321 jit 4.305341, age 0
transmit: at 262 192.168.1.187->204.2.134.163 mode 3
receive: at 262 192.168.1.187<-204.2.134.163 mode 4 code 1 auth 0
clock_filter: n 5 off 11.426539 del 0.105108 dsp 0.438319 jit 4.312551, age 0
transmit: at 263 192.168.1.187->204.235.61.9 mode 3
receive: at 263 192.168.1.187<-204.235.61.9 mode 4 code 1 auth 0
clock_filter: n 5 off 11.421503 del 0.063630 dsp 0.438327 jit 4.369329, age 0
transmit: at 265 192.168.1.187->198.55.111.5 mode 3
receive: at 265 192.168.1.187<-198.55.111.5 mode 4 code 1 auth 0
clock_filter: n 5 off 11.492415 del 0.110222 dsp 0.438333 jit 4.395664, age 0
auth_agekeys: at 300 keys 1 expired 0
timer: interface update
addto_syslog: no IPv6 interfaces found
addto_syslog: no IPv6 interfaces found
transmit: at 324 192.168.1.187->206.209.110.2 mode 3
receive: at 324 192.168.1.187<-206.209.110.2 mode 4 code 1 auth 0
clock_filter: n 6 off 13.087355 del 0.055836 dsp 0.188400 jit 5.390925, age 0
transmit: at 327 192.168.1.187->204.235.61.9 mode 3
transmit: at 327 192.168.1.187->204.2.134.163 mode 3
receive: at 327 192.168.1.187<-204.235.61.9 mode 4 code 1 auth 0
clock_filter: n 6 off 13.121146 del 0.043954 dsp 0.188395 jit 5.392715, age 0
receive: at 327 192.168.1.187<-204.2.134.163 mode 4 code 1 auth 0
clock_filter: n 6 off 13.130597 del 0.101628 dsp 0.188398 jit 5.348189, age 0
transmit: at 328 192.168.1.187->198.55.111.5 mode 3
receive: at 328 192.168.1.187<-198.55.111.5 mode 4 code 1 auth 0
clock_filter: n 6 off 13.154256 del 0.084444 dsp 0.188390 jit 5.383440, age 0

Curiouser and curiouser!  As I speculated, it sees some clocks but it doesn't actually sync with them and it keeps falling further and further behind.  Why doesn't it sync?  Well, here I'm kind of at the edge of my ntpd experience -- maybe we could send David Mills a few free Chumbys and see if he gets inspired? smile

  • Registered: 2009-11-28
  • Posts: 73

Re: Clocks running 10 minutes slow overnight

Digging a little further into the ntpd man pages, I think that using the -x flag on a machine with a seriously flaky hardware clock might be problematic:

-x
Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete. This option can be used with the -g and -q options. See the tinker command for other options. Note: The kernel time discipline is disabled with this option.

If I'm reading this right: with the -x flag, ntpd will allow up to 600 seconds of lag without panicing, but will attempt to slew the system clock slowly to fix it, taking up to 2000 seconds (33 minutes) per second of adjustment.  So if the system clock is losing time faster than roughly two seconds per hour (and in my case it's clearly losing something closer to a second per minute!), ntpd will never successfully catch up to real time.

But of course without the -x flag, ntpd's default step threshold is 0.128s and that might not do either.  Time to go play with the tinker command...

67 Reply by fabulist (edited by fabulist 2015-07-10 08:36:27)

  • Registered: 2015-07-10
  • Posts: 1

Re: Clocks running 10 minutes slow overnight

I had this problem for about a week and it got solved without tweaking the internals of the Chumby using reruns of the show "Sons of Anarchy."  Please bear with my explanation:

Like the OP of this thread, I use an original Chumby as an alarm clock.  Over the last 7 years and couple of moves, it always kept perfect time.  About two weeks ago, the time started to drift.  I had not made any changes to the setup, network, etc.  So I started reading this thread and was ready to jump in and start tweaking the various commands discussed here, until a couple of nights ago, we fired up Netflix on my AppleTV to watch SOA and noticed that the picture quality was poor and that it had to stop and buffer frequently.  I immediately knew what the problem was:  like with most modern routers, mine supports two different frequencies, 2.4GHZ and 5GHZ.  The 5GHZ channel is a lot faster and all the newer WIFI gadgets in my house use that channel, including the AppleTV.  My Chumby, however, can only use the 2.4GHZ channel. 

I am sure you can see where this is going.  The AppleTV had dropped off the 5GHZ channel and logged itself into the much slower 2.4GHZ channel which explained the poor quality of the image and the buffering.  It was also hogging the bandwidth so badly (or interfering with the Chumby's radio signal) that the Chumby was unable to get NTP updates and was getting off-sync with the current time.  As soon as I got the AppleTV logged into the 5GHZ channel, the Chumby started showing the correct time.

I am frankly a bit miffed at Apple for the AppleTV's poor behavior when sharing a channel with the Chumby (or maybe it's the Chumby that is not behaving well).  But before delving into the guts of your Chumby, it would make sense to check all the other WiFi devices running in the house and get as many of them on the 5 GHZ channel as possible to give the Chumby a clear communication channel.  At the moment, the Chumby is the only device in my house that uses 2.4GHZ.  Everything else, including our phones, use the 5GHZ radio, so there is no conflict whatsoever.

  • From: Australia
  • Registered: 2009-03-19
  • Posts: 505

Re: Clocks running 10 minutes slow overnight

This is an interesting theory.
I have had the Chumby time drift problem with two different devices, an Infocast 3.5 and a Sony Dash. The main thing that they have in common is their position in the kitchen (the Dash replaced the Infocast in the exact same place), and that this position makes them the wireless-connected Chumby device farthest away from the wireless access point. I have six other Chumbys/Infocasts in operation that all keep time. They are all either closer to the WAP or on ethernet, so I will look into this issue further.

69 Reply by travisd (edited by travisd 2015-07-26 18:53:42)

  • Registered: 2008-12-02
  • Posts: 5

Re: Clocks running 10 minutes slow overnight

Just stumbled into this one after hearing from my better half that she wasn't happy that Chumby (classic) was ~20+ minutes slow. We basically use it for a clock in the TV room.

I did the upgrade to 1.7.3 (it was on 1.7.2).  Logging in via sshd, ntpd was not running. I started it, but am not clear if that's just a kludge, or of it's supposed to be running all of the time?

Edit to add:

Seeing similar behavior to others.

Even after doing a successful manual ntpdate against pool.ntp.org,  seems to be rapidly loosing time.

chumby:/var/log# ntpq -n -c peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 198.211.33.111  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 216.152.240.220 164.67.62.194    2 u   71   64   32   86.102  12913.8 4563.68
 208.53.158.34   204.2.134.163    3 u    6   64   37   35.043  14604.0 4785.82
 198.55.111.5    127.67.113.92    2 u    3   64   37   86.776  14704.8 4861.90

chumby:/var/log# chumby_version -s
1.7.3