Page 1 of 2
Clock issue with Meteohub ** solved **
Posted: Sat Feb 16, 2008 4:15 am
by cbhiii
Hello,
I have an issue with the time kept by Meteohub after a reboot is performed. I have noticed this problem twice now and think that maybe it is a bug.
Tonight I logged into Meteohub at 20:33 at left the screen wait there. I then waited until 20:54 and performed a reboot. When the unit finished booting the time displayed was 20:45.
In a few minutes the clock updated itself to the NTP server and corrected itself, but on two other occasions the clock was more than 1000 seconds off and then stopped the NTP process from running. So the clock won't update going forward.
Can you see this issue?
Re:Clock issue with Meteohub
Posted: Sat Feb 16, 2008 11:09 am
by admin
Hi,
NTP tries to keep the clock in sync with time servers from the internet. NTP does this by adjusting the clock speed so that the local clock runs a little slower or faster until the correct time is reached. This is a big advantage compared to setting the time manually, as you don't have jumps in the flow of time, especially no jumps back in time, which might cause trouble with certain applications. However, when the gap between local hardware time and real time is too big, NTP gives up and proposes to set the time manually.
This is what you did. What puzzles me is, that after having the time set manually (and having pressed \"save\") your Meteohub does not set the time you entered to its hardware clock. It certainly should do this.
I will give it a try on my test systems.
Re:Clock issue with Meteohub
Posted: Sat Feb 16, 2008 6:22 pm
by cbhiii
From what I can tell the issue seems to be that the time is not being stored very often in Meteohub (or Slug) and that when I press REBOOT, the unit's clock might be 10 minutes behind when the reboot is finished. Sometimes it's 15 or 20 minutes behind the correct time. It's as if the hub isn't keeping track of the current time in it's memory.
The clock on my WMR200 was about 18 hours off and I have since corrected this so maybe that has something to do with it as well. I'm not using the clock in the WMS200 and am using the Meteohub to time my entries and send them to Weather Underground.
Cheers.
Re:Clock issue with Meteohub
Posted: Sat Feb 16, 2008 8:05 pm
by admin
I checked the code. Every time the data is set manually it is also enforced that this is stored to the hw clock of the NSLU2.
\"/bin/date %s 2>/dev/null >/dev/null; /sbin/hwclock --systohc 2>/dev/null >/dev/null\"
Furthermore ervery 2 hours actual time is store to hw clock:
\"44 */2 * * * /sbin/hwclock -w\"
Do you have an old Meteohub version running? Before 1.8 that has not been handled correctly... as far as I can remember.
Re:Clock issue with Meteohub
Posted: Sun Feb 17, 2008 3:58 am
by cbhiii
I'm running 1.9b now and will be upgrading to 2.0a in a few. I will pay close attention to find out what is taking place and let you know. Thanks.
Re:Clock issue with Meteohub
Posted: Sun Feb 17, 2008 5:07 am
by cbhiii
I completed the update to version 2.0a with no problems.
I retested Meteohub's clock to see what would happen after a reboot.
At 21:50 Meteohub has the correct time. At 21:50 I did a reboot of Meteohub.
After the reboot the clock in Meteohub shows 21:17 which is 43 minutes wrong. My weather data being sent to Weather Underground is also now wrong.
Since this time is over 1000 seconds wrong the NTP daemon will not update the clock properly.
From system log:
Feb 16 21:51:21 (none) user.notice shutdown[3495]: shutting down for system reboot
Feb 16 21:51:21 (none) syslog.info System log daemon exiting.
Feb 16 21:17:11 (none) syslog.info syslogd started: BusyBox v1.01 (2006.06.09-14:27+0000)
Feb 16 21:17:11 (none) user.notice kernel: klogd started: BusyBox v1.01 (2006.06.09-14:27+0000)
From ntp log:
16 Feb 21:20:45 ntpd[1511]: synchronized to 129.6.15.28, stratum 1
16 Feb 21:20:45 ntpd[1511]: time correction of 2234 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
Is there a way for Meteohub to not loose the correct time when a reboot is performed?
Thanks.
Re:Clock issue with Meteohub
Posted: Sun Feb 17, 2008 2:21 pm
by admin
I checked with my meteohub. whatever time i set, this time is again there after reboot. No idea why that is not the case with your NSLU2.
Do I have a chance to get on your system? Please send a mail with logon details to \"info(at)meteohub.de\" if you can do that.
I will do some googling, if there are certain types of hardware that do have problems with keeping the time during power-off or reboot.
Re:Clock issue with Meteohub
Posted: Sun Feb 17, 2008 2:26 pm
by admin
some NSLU2 seem to be impacted by a problem setting system time to the hw clock.
http://www.nslu2-linux.org/wiki/SlugOS/ ... ksOddsEnds
As stated before, I would need access to your Meteohub, to dig into this.
Re:Clock issue with Meteohub
Posted: Mon Feb 18, 2008 1:11 am
by cbhiii
I will try to set up this access. I will let you know as soon as it is ready. Thanks!
Re:Clock issue with Meteohub
Posted: Tue Feb 19, 2008 2:49 am
by cbhiii
I have access setup through the internet to my meteohub.
I emailed '
info@meteohub.de' with my IP address and password. Thanks!
Re:Clock issue with Meteohub
Posted: Wed Feb 20, 2008 2:32 am
by admin
I did some tests on your system and could reproduce the symptoms you have described. Sorry to say, but this really looks like a problem with the hw clock in the NSLU2 which seems to have problems in certain situations.
As far as I could analyze, the hw clock can be set by setting a date manually, but after waiting 10 minutes and doing a reboot, the hw clock seems to be stuck to the time when it was manually set the last time. I will implement a work around for this in the next update, by saving the system time to the hardware clock on every reboot or shut down. This should at least fix the problem for reboots (triggered manually or by a software update installation).
Let's see whether the next update can fix this.
Re:Clock issue with Meteohub
Posted: Sun Mar 16, 2008 1:56 am
by mvpel
My unit reset to 1999 when I removed and restored power while moving it from one room to the other. Perhaps the unit isn't updating the hardware clock properly?
14 Mar 12:26:34 ntpd[16254]: synchronized to 69.60.124.59, stratum 2
14 Mar 12:33:42 ntpd[16254]: synchronized to 63.240.161.99, stratum 2
30 Nov 00:01:06 ntpd[1581]: logging to file /data/log/ntp.log
30 Nov 00:01:06 ntpd[1581]: precision = 93.000 usec
30 Nov 00:01:06 ntpd[1581]: Listening on interface wildcard, 0.0.0.0#123 Disabled
30 Nov 00:01:06 ntpd[1581]: Listening on interface lo, 127.0.0.1#123 Enabled
30 Nov 00:01:06 ntpd[1581]: Listening on interface eth0:0, 192.168.1.77#123 Enabled
30 Nov 00:01:06 ntpd[1581]: Listening on interface eth0, 192.168.221.11#123 Enabled
30 Nov 00:01:06 ntpd[1581]: kernel time sync status 0040
30 Nov 00:01:06 ntpd[1581]: frequency initialized 5.875 PPM from /var/spool/ntp/ntp.drift
30 Nov 00:01:06 ntpd[1581]: frequency initialized 5.555 PPM from /var/spool/ntp.drift
30 Nov 00:04:20 ntpd[1581]: synchronized to 64.202.112.75, stratum 1
30 Nov 00:04:20 ntpd[1581]: time correction of 261666049 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
15 Mar 14:48:01 ntpd[1572]: logging to file /data/log/ntp.log
I'm running 2.0d, upgraded from what I received from Ambient Weather earlier this week. Is it possible to log in to the unit to a shell and update the sanity limit, perhaps, as a workaround?
Ambient sent me a refurbished unit, so perhaps it's an older chipset.
Re:Clock issue with Meteohub
Posted: Wed Mar 19, 2008 7:52 pm
by mvpel
On Linux 2.4.20, the \"-g\" option to ntpd allows the client to violate its 1000-second limit once, permitting an initial sync at startup.
Re:Clock issue with Meteohub
Posted: Wed Mar 19, 2008 8:52 pm
by admin
Hi, that is a very good hint!
I Will test this. I can't see anything wrong in forcing the time update regardless what the delta to the hardware clock is.
Anybody out there having concerns?
Re:Clock issue with Meteohub
Posted: Wed Mar 19, 2008 9:37 pm
by mvpel
The sanity check is to prevent way-out-of-sync timeservers from mis-setting the system's clock, but that doesn't happen very often with most timeservers, and if the pool.ntp.org servers are used, I think it can never happen due to the monitoring of the pool systems offered in the DNS response.
Also, by only ignoring the 1000-second step limit on the first sync, it reduces the risk even further.
You could also consider using ntpdate against two or three pool servers (0 through 2.pool.ntp.org) in addition to the user-configured servers for the initial clock set, too.