Re: Clocks running 10 minutes slow overnight

nosajay wrote:

I'm having the same problem, it's been going on for a few months now and have been relying on my iPhone for my wake alarm. I just posted the issue in the software threads.  My classic chumby loses over 10 minutes of time though. When I get to it I'll ssh in. Just letting you know you're not the only one.

Ah ha! More clues for the code sleuths out there! It's not isolated to me alone!

--Marc

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

Re: Clocks running 10 minutes slow overnight

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.

Cleaning up any loose bits and bytes.

Re: Clocks running 10 minutes slow overnight

ntpd normally only dies if the time goes insane and it's beyond the ability of the daemon to sync it back again; something like if the clock was 1000s wrong.  This normally shouldn't happen except at potential startup (which is why "ntpdate" is commonly used before hand, to set the clock approximately right).

Very odd...

Re: Clocks running 10 minutes slow overnight

Huh, that /usr/chumby/scripts/sync_time.sh script is...  funky!

Why would you kill ntpd, then run ntpdate, then restart ntpd?  That's just bizarre.

Re: Clocks running 10 minutes slow overnight

who what now?

I see

chumby:/psp# more /usr/chumby/scripts/sync_time.sh
#!/bin/sh
# Options:
# -b   Boot option - allow for large jump in time
OPTS="$*"

if [ ! -e /psp/use_ntp ]; then
    echo 1 >/psp/use_ntp
fi

if [ `cat /psp/use_ntp` -eq 1 ]; then
    # rdate is deprecated - use only if /psp/use_rdate is present
    if [ -e /psp/use_rdate ]; then
    rdate -s time.chumby.com
    else
    NTPSERVER=pool.ntp.org
    [ -f /psp/ntp_server ] && NTPSERVER=$(cat /psp/ntp_server)
    ntpdate ${NTPSERVER}
    fi
    echo `date +%s >/tmp/time_update`
fi

on my 1.7.3 verison firmwared classic.

Cleaning up any loose bits and bytes.

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.

Both were updated to 1.7.3 at the start of this process.

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

Re: Clocks running 10 minutes slow overnight

Both of my C1's have this:

chumby:~# cat /usr/chumby/scripts/sync_time.sh s
#!/bin/sh
#
# sync_time.sh - synchronize with network time source
#
# Ken Steele
# Copyright (c) Chumby Industries, 2007-2008
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

OPTS="$*"

if [ ! -e /psp/use_ntp ]; then
    echo 1 >/psp/use_ntp
fi

if [ "$(cat /psp/use_ntp)" -eq "1" ]; then
    if ps | grep -v grep | grep -q ntpd
    then
        killall ntpd
    fi
    ntpdate pool.ntp.org

        # Disable this functionality for the beta release.
    # Set up a default driftfile if it doesn't exist.
    if [ ! -e /psp/ntp.drift ]
    then
        echo -140.000 > /psp/ntp.drift
    fi

    ntpd -g -x -f /psp/ntp.drift
    echo `date +%s >/tmp/time_update`
fi

/usr/chumby/scripts/save_time

Re: Clocks running 10 minutes slow overnight

what's your "chumby_version -s" output?

Cleaning up any loose bits and bytes.

Re: Clocks running 10 minutes slow overnight

1.0.7, latest for the c1; script matches the one in the tarball at http://forum.chumby.com/viewtopic.php?pid=46120#p46120

Re: Clocks running 10 minutes slow overnight

ah, that's the diff, I'm looking at a classic.

but, yeah, it makes no sense (to me) to kill ntp and run ntpdate then start ntp again.... maybe check to see if it's ok and leave it alone if it's running, and if not, ntpdate and then start it again.

Cleaning up any loose bits and bytes.

Re: Clocks running 10 minutes slow overnight

Hi there,

I am having time issues as well. Here's some output from from my SSH session:


chumby:~# ntpq -n -c peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
199.7.177.206   .INIT.          16 u    -   64    0    0.000    0.000   0.000
169.229.70.201  .INIT.          16 u    -   64    0    0.000    0.000   0.000
209.118.204.201 .INIT.          16 u    -   64    0    0.000    0.000   0.000
192.241.167.38  .INIT.          16 u    -   64    0    0.000    0.000   0.000
chumby:~#

Any ideas? I don't think my clock has set itself in a while as it's about 5 minutes fast.

Thanks in advance, Raster

Re: Clocks running 10 minutes slow overnight

How long after starting ntp did you run that command?

it's saying that it can not reach any NTP server at all.  Either you run the command very quickly after startup so it had no chance to talk to any, or else your router/firewall/ISP/something is blocking NTP traffic.

38 (edited by SilverMarc 2014-05-30 15:44:48)

Re: Clocks running 10 minutes slow overnight

sweh wrote:

How long after starting ntp did you run that command?

it's saying that it can not reach any NTP server at all.  Either you run the command very quickly after startup so it had no chance to talk to any, or else your router/firewall/ISP/something is blocking NTP traffic.

It is now the end of the day, the Chumby has been running all day. I did the "settings" thing and was able to ssh right in this time. The clock is 16 minutes slow after the full day, and here is the report:

BusyBox v1.6.1 (2011-11-14 17:44:07 PST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

chumby:~# ntpq -n -c peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 162.243.72.74   209.51.161.238   2 u   57   64  377   15.399  997756. 7942.76
 198.55.111.50   216.229.0.50     3 u    -   64  367   81.854  999239. 9300.91
 192.241.226.180 216.218.192.202  2 u   23   64  377  110.722  998652. 7820.55
 208.53.158.34   206.108.0.132    2 u   21   64  377   65.048  998681. 7846.12

chumby:~# driftfile /psp/ntp.drift
-sh: driftfile: not found
chumby:~# 
Marc Silverman
New York City
SilverMarc.com | Chumbian.com
MY POWER TEAM: Macintosh, iPhone, Chumby, Geocaching, WheresGeorge.

Re: Clocks running 10 minutes slow overnight

sweh wrote:

How long after starting ntp did you run that command?

it's saying that it can not reach any NTP server at all.  Either you run the command very quickly after startup so it had no chance to talk to any, or else your router/firewall/ISP/something is blocking NTP traffic.

I ran the command about an hour after I rebooted the infocast 3.5. I also tried pinging the servers it listed and had no problems with that so I don't think it should be an access issue. Should I wait longer before running the command again?

If it helps, I'm running software version 1.07.

Thanks, raster

Re: Clocks running 10 minutes slow overnight

@raster - "ping" uses ICMP packets.  NTP uses "udp" packets.  This definitely looks like a network issue at your end.

Can you do "ntpdate -d 199.7.177.206" ?  That will try to talk to one of the servers you listed and report on its results.

41 (edited by sweh 2014-05-30 16:19:48)

Re: Clocks running 10 minutes slow overnight

@SilverMarc - that's very odd.  It's saying it can reach these servers but isn't able to actually agree that any of them have a good time.

Maybe let's see if we can force a time...

Something like:

killall ntpd
ntpdate 199.7.177.206
ntpd -g -x -f /psp/ntp.drift
Then wait a minute and do "ntpq -n -c peer"
Then wait a few minutes (at least 15) and then do another "ntpq -n -c peer"

Re: Clocks running 10 minutes slow overnight

sweh, it also looks like it thinks that the date is 11.5 days off (offset in the 999,000 second range).

that's pretty wacky.

Cleaning up any loose bits and bytes.

Re: Clocks running 10 minutes slow overnight

SilverMarc wrote:

chumby:~# driftfile /psp/ntp.drift
-sh: driftfile: not found

that should be 'cat /psp/ntp.drift'

also, can you do a 'date' command while you're in there.

just 'date'

ie:
chumby:~# date
Fri May 30 19:50:19 CDT 2014

Cleaning up any loose bits and bytes.

Re: Clocks running 10 minutes slow overnight

sweh wrote:

@raster - "ping" uses ICMP packets.  NTP uses "udp" packets.  This definitely looks like a network issue at your end.

Can you do "ntpdate -d 199.7.177.206" ?  That will try to talk to one of the servers you listed and report on its results.


Thanks sweh. Here are the results:

chumby:~# ntpdate -d 199.7.177.206
30 May 20:02:27 ntpdate[10991]: ntpdate 4.2.4p5@1.1541 Sat Nov  6 02:03:43 UTC 2010 (1)
Looking for host 199.7.177.206 and service ntp
host found : ntp2.h.vporn.com
transmit(199.7.177.206)
receive(199.7.177.206)
transmit(199.7.177.206)
receive(199.7.177.206)
transmit(199.7.177.206)
receive(199.7.177.206)
transmit(199.7.177.206)
receive(199.7.177.206)
transmit(199.7.177.206)
server 199.7.177.206, port 123
stratum 2, precision -22, leap 00, trust 000
refid [199.7.177.206], delay 0.09390, dispersion 0.00099
transmitted 4, in filter 4
reference time:    d733a3ec.b2c8abd0  Fri, May 30 2014 19:42:20.698
originate timestamp: d733a80a.78f84e68  Fri, May 30 2014 19:59:54.472
transmit timestamp:  d733a8a4.28ca1cef  Fri, May 30 2014 20:02:28.159
filter delay:  0.10214  0.10802  0.09390  0.10254
         0.00000  0.00000  0.00000  0.00000
filter offset: -153.725 -153.724 -153.726 -153.725
         0.000000 0.000000 0.000000 0.000000
delay 0.09390, dispersion 0.00099
offset -153.726519

30 May 20:02:28 ntpdate[10991]: step time server 199.7.177.206 offset -153.726519 sec

It seems like it's communicating but I'm not sure what it means.

Re: Clocks running 10 minutes slow overnight

diamaunt wrote:

sweh, it also looks like it thinks that the date is 11.5 days off (offset in the 999,000 second range).

that's pretty wacky.

No, the offset is in ms, so that's 999 seconds, 16.5 minutes which matches SilverMarc's report

Re: Clocks running 10 minutes slow overnight

@raster - OK, now that's very confusing.  The machine can see the remote hosts and get a value... but ntpd doesn't like it!  Very odd...

What does "ntpq -n -c peer" say now?

Also "grep -v '^#' /etc/ntp.conf"  and "cat /psp/ntp.drift"

Re: Clocks running 10 minutes slow overnight

Thanks for your help sweh. Here's the output from those commands. Since I last responded, I set the time manually and then re-checked the 'use internet to set time' on the infocast.

chumby:~# ntpq -n -c peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 107.170.242.27  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 198.60.22.240   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 169.229.70.95   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 70.33.227.188   .INIT.          16 u    -   64    0    0.000    0.000   0.000
chumby:~# grep -v '^#' /etc/ntp.conf

driftfile /psp/ntp.drift

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server pool.ntp.org


chumby:~# cat /psp/ntp.drift
-58.412
chumby:~#

Re: Clocks running 10 minutes slow overnight

sweh wrote:

No, the offset is in ms, so that's 999 seconds, 16.5 minutes which matches SilverMarc's report

Doh, right...

Cleaning up any loose bits and bytes.

Re: Clocks running 10 minutes slow overnight

@raster - well, that's got me beat.  Unless there's a problem with the infocast, I can't see why ntpd isn't working for you.  That's just odd.

Re: Clocks running 10 minutes slow overnight

sweh - Thanks anyway. It's probably something with my network setup that's causing this.

About 8 months ago, I started running a dd-wrt router behind my combination 2wire modem/router. The 2wire is configured to have the dd-wrt run in a dmz+ zone with no ports being blocked. However, I don't know if that's actually happening or not. I haven't had any issues with anything else (that I know of) but I guess you never know until you run into something like this.

Anyway, If this is the only problem I have, I can live with it.

Thanks again.