Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread K . S .
Harald Becker  gmx.de> writes:

> 
> Hi Joshua !
> 
>  > Doesn't ntpd already use adjtimex to make that correction?
> 
> That would be great!
> 
> It was about 20 years ago, I used adjtimex to correct the clock of some 
> systems with no permanent Internet connection. Since this I did not look 
> to close to the changes that have gone to the time keeping functions. If 
> ntpd uses adjtimex, it can do all the things I told, just behind the scene.

Harald, when you get around to looking at the code, if you find that it does
in fact do this, I would be interested to know where it is storing the
correction factor for use after a reboot.

Also, do you think there is any real concern about running ntpd on a device
with embedded hardware?  The published hardware specs are:

SoC: Marvell 88F6282 1.6 GHz
CPU: Sheeva CPU core V5TE ARM
RAM: 1GB DDR3
Flash: 512MB NAND Flash

After reading Jim Cathey's comments, and realizing that ntpd resets the
hardware clock every 11 minutes (if I understand correctly), I just want to
know if there is any valid reason to be concerned that running ntpd as a
service could damage the flash memory or some other component, or cause the
device to fail prematurely.  Do you have any thoughts on that?




___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Harald Becker

Hi Joshua !

> Doesn't ntpd already use adjtimex to make that correction?

That would be great!

It was about 20 years ago, I used adjtimex to correct the clock of some 
systems with no permanent Internet connection. Since this I did not look 
to close to the changes that have gone to the time keeping functions. If 
ntpd uses adjtimex, it can do all the things I told, just behind the scene.


Thx, for info.

--
Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Joshua Judson Rosen

On 2014-09-01 07:00, Harald Becker wrote:

Hi !


Actually, the hwclock time is what's inaccurate


:-( ... bad hardware!


That is very interesting but since this system is always connected to the
Internet, I'm not sure I need to be that concerned about the hardware clock.


If your system is always connected to a functioning Internet connection, you
won't need it, with a running ntpd ... but as you told you are going to record
Satellite or Terrestrial TV, so think about situations where the Internet
connection dropped (for which reason ever). As soon as ntpd can't contact the
public time server, your clock starts to run away from the real time. So it will
depend how long the Connection is missing. For short drop outs, it won't make
much difference, but when the connection is lost for hours, the time drifts away
and your recording time may be too. That is using adjtimex to correct you system
clock to drift as less as possible, will help to solve such Internet drop outs.


Doesn't ntpd already use adjtimex to make that correction?

(I see the adjtimex call in ntpd.c, at least--I haven't yet traced through
 the code to understand what adjustments it's actually making...)

--
"'tis an ill wind that blows no minds."
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Dan Fandrich
On Tue, Sep 02, 2014 at 03:12:45PM -0400, Cathey, Jim wrote:
> This is/was part of a proprietary system, but I do know that it
> kept track of _when_ a time correction was applied, and how much
> was applied, from which it extrapolated the amount of drift the
> clock would have at any point.  In practice it worked out very well,
> provided you did not try to 'correct' the time too much!  The
> main secret is that the HW clock's own time was NEVER changed!
> That gave you the long-term baseline from which you could calculate
> the inherent drift in the system.  The longer you waited before giving
> it a correction, the better the correction was.  Because the HW
> time was never changed, a later correction's timebase was not
> just from the prior correction, but from time zero.

Upstream adjtimex has --review and associated options to work in exactly
this mode.

>>> Dan
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


RE: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Cathey, Jim
>I would HOPE that flash memory has improved in the past 20 years,

The underlying physics really hasn't.  Some devices are more
robust, but the less expensive ones aren't.  They're a lot bigger,
is all.  You need to KNOW where and what is kept, if you want to
have any confidence in the long-term reliability of your system.

>would you care to share the procedure you have used to
>get the time that accurate?  And do you have to run something at every
>reboot to do the time correction, or is this a "set it once and forget it"
>type of thing?

This is/was part of a proprietary system, but I do know that it
kept track of _when_ a time correction was applied, and how much
was applied, from which it extrapolated the amount of drift the
clock would have at any point.  In practice it worked out very well,
provided you did not try to 'correct' the time too much!  The
main secret is that the HW clock's own time was NEVER changed!
That gave you the long-term baseline from which you could calculate
the inherent drift in the system.  The longer you waited before giving
it a correction, the better the correction was.  Because the HW
time was never changed, a later correction's timebase was not
just from the prior correction, but from time zero.

This corrected HW value was applied to the kernel at startup, which
would also add/withhold a microtick every so often (based on the
calculated drift) in order to apply the correction.

You would only have to change the HW clock's stored base time if there
was a battery change, or something like an ESD event wiped out the
clock itself or the clock crystal was changed out.  But then you'd
have to start the recalibration cycle all over again.

Our NTP was tweaked to work with this system.  In fact, it was the
early NTP implementation that was responsible for destroying the
clock EEPROM hardware.  Faces were red.

-- Jim

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread K . S .
Isaac Dunham  gmail.com> writes:
> On Tue, Sep 02, 2014 at 06:23:50PM +0200, Harald Becker wrote:
> > The question is: Does Busybox ntpd activate this 11 minute mode?
> 
> Per adjtimex, eventually it does.

My experience so far is that when ntpd is run at startup it keeps the
hardware clock more or less synchronized.  By which I mean, the hardware
appears to be behind the system clock by a little over 1 second, which
should be enough to get the system clock set at a reasonably close value on
the next reboot, until ntpd has a chance to start.



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread K . S .
Harald Becker  gmx.de> writes:

> Let me give a couple of days, I try to get a closer look at the Busybox 
> adjtimex and send you a step by step description, how to use it.

Thank you, Harald, I would like to see that and will be looking forward to it.




___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread K . S .
Cathey, Jim  ciena.com> writes:

> 
> I don't know how all this is put together on your
> particular system, but I had experience once where
> an ill-advised attempt to keep the HW clock in sync
> resulted in destruction of the system's EEPROM in
> which the time offset and first-order drift correction
> factors were kept.  The adjustment was designed, by
> the system's authors, to be applied MANUALLY, after
> a sufficient amount of time had passed to develop a
> good baseline for drift.  By jinking it automatically,
> rather often, the 10,000-write-cycle EEPROM was destroyed
> in a matter of weeks, as I recall.

I'm not sure what they are using for memory in this device, but the
published specs say this:

RAM: 1GB DDR3
Flash: 512MB NAND Flash

I would assume that the flash memory holds the firmware and that everything
else is written to the DDR3.  At least I would hope that is the case.

Right now I am not using hwclock, just ntpd, and as noted it does seem to be
keeping the hardware clock more or less in sync.

> The moral is, don't go messing with stuff if you don't
> understand how it works.

Well, if I didn't want to be able to record shows on a schedule, that might
be good advice.  I was simply trying to find a workable solution to this
issue.  And anyone else that encounters this problem would likely do the same!

> I am still running one of these systems in my basement,
> it's been running for close to twenty years and without
> connection to the internet, and its clock is as spot-on
> as one could expect.  (Its cron is running sprinklers and
> outdoor lighting, so it's easy to verify the clock by
> observation.)  I've adjusted the clock only a handful of
> times, it learns and refines the drift every time I
> correct it.  Which is not often!

I would HOPE that flash memory has improved in the past 20 years, but since
you brought this up, would you care to share the procedure you have used to
get the time that accurate?  And do you have to run something at every
reboot to do the time correction, or is this a "set it once and forget it"
type of thing?

If I could get it to where the time drift was less than about one second per
week, that would probably be acceptable.



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


RE: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Cathey, Jim
I don't know how all this is put together on your
particular system, but I had experience once where
an ill-advised attempt to keep the HW clock in sync
resulted in destruction of the system's EEPROM in
which the time offset and first-order drift correction
factors were kept.  The adjustment was designed, by
the system's authors, to be applied MANUALLY, after
a sufficient amount of time had passed to develop a
good baseline for drift.  By jinking it automatically,
rather often, the 10,000-write-cycle EEPROM was destroyed
in a matter of weeks, as I recall.

Soldering on replacement parts was required to resurrect
the affected systems.

The moral is, don't go messing with stuff if you don't
understand how it works.

I am still running one of these systems in my basement,
it's been running for close to twenty years and without
connection to the internet, and its clock is as spot-on
as one could expect.  (Its cron is running sprinklers and
outdoor lighting, so it's easy to verify the clock by
observation.)  I've adjusted the clock only a handful of
times, it learns and refines the drift every time I
correct it.  Which is not often!

-- Jim

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Isaac Dunham
On Tue, Sep 02, 2014 at 06:23:50PM +0200, Harald Becker wrote:
> Hi Denys!
> 
> On 02.09.2014 15:52, Denys Vlasenko wrote:
> >$ busybox ntpd --help
> >BusyBox v1.22.1 (2014-02-01 19:25:19 CET) multi-call binary.
> >
> >Usage: ntpd [-dnqNwl] [-S PROG] [-p PEER]...
> >
> >NTP client/server
> >
> > -dVerbose
> > -nDo not daemonize
> > -qQuit after clock is set
> > -NRun at high priority
> > -wDo not set time (only query peers), implies -n
> > -lRun as server on port 123
> > -p PEERObtain time from PEER (may be repeated)
> > -S PROGRun PROG after stepping time, stratum change, and every 11 
> > mins
> >^^
> > use this to periodically set the hw clock
> 
> What about this (from hwclock manpage)?
> 
> Automatic Hardware Clock Synchronization By the Kernel
> 
> You should be aware of another way that the Hardware Clock is kept
> synchronized in some systems. The Linux kernel has a mode wherein it copies
> the System Time to the Hardware Clock every 11 minutes. This is a good mode
> to use when you are using something sophisticated like ntp to keep your
> System Time synchronized. (ntp is a way to keep your System Time
> synchronized either to a time server somewhere on the network or to a radio
> clock hooked up to your system. See RFC 1305).
> 
> This mode (we'll call it "11 minute mode") is off until something turns it
> on. The ntp daemon xntpd is one thing that turns it on. You can turn it off
> by running anything, including hwclock --hctosys, that sets the System Time
> the old fashioned way.
> 
> To see if it is on or off, use the command adjtimex --print and look at the
> value of "status". If the "64" bit of this number (expressed in binary)
> equal to 0, 11 minute mode is on. Otherwise, it is off.
> 
> If your system runs with 11 minute mode on, don't use hwclock --adjust or
> hwclock --hctosys. You'll just make a mess. It is acceptable to use a
> hwclock --hctosys at startup time to get a reasonable System Time until your
> system is able to set the System Time from the external source and start 11
> minute mode.
> 
> 
> The question is: Does Busybox ntpd activate this 11 minute mode?

Per adjtimex, eventually it does.
(Note: it seems that "busybox adjtimex" is equivalent to "adjtimex --print".)
$ adjtimex
mode: 0
-o  offset:   -435
-f  frequency:6028
maxerror: 1600
esterror: 1600
status:   1 (PLL)
-p  timeconstant: 5
precision:1
tolerance:32768000
-t  tick: 1
time.tv_sec:  1409676091
time.tv_usec: 818519
return value: 0 (clock synchronized)

(I'd started "service ntpd" on Alpine about a minute beforehand.
That's Busybox ntpd.)

HTH,
Isaac Dunham
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Harald Becker

Hi Denys!

On 02.09.2014 15:52, Denys Vlasenko wrote:

$ busybox ntpd --help
BusyBox v1.22.1 (2014-02-01 19:25:19 CET) multi-call binary.

Usage: ntpd [-dnqNwl] [-S PROG] [-p PEER]...

NTP client/server

 -dVerbose
 -nDo not daemonize
 -qQuit after clock is set
 -NRun at high priority
 -wDo not set time (only query peers), implies -n
 -lRun as server on port 123
 -p PEERObtain time from PEER (may be repeated)
 -S PROGRun PROG after stepping time, stratum change, and every 11 mins
^^
 use this to periodically set the hw clock


What about this (from hwclock manpage)?

Automatic Hardware Clock Synchronization By the Kernel

You should be aware of another way that the Hardware Clock is kept 
synchronized in some systems. The Linux kernel has a mode wherein it 
copies the System Time to the Hardware Clock every 11 minutes. This is a 
good mode to use when you are using something sophisticated like ntp to 
keep your System Time synchronized. (ntp is a way to keep your System 
Time synchronized either to a time server somewhere on the network or to 
a radio clock hooked up to your system. See RFC 1305).


This mode (we'll call it "11 minute mode") is off until something turns 
it on. The ntp daemon xntpd is one thing that turns it on. You can turn 
it off by running anything, including hwclock --hctosys, that sets the 
System Time the old fashioned way.


To see if it is on or off, use the command adjtimex --print and look at 
the value of "status". If the "64" bit of this number (expressed in 
binary) equal to 0, 11 minute mode is on. Otherwise, it is off.


If your system runs with 11 minute mode on, don't use hwclock --adjust 
or hwclock --hctosys. You'll just make a mess. It is acceptable to use a 
hwclock --hctosys at startup time to get a reasonable System Time until 
your system is able to set the System Time from the external source and 
start 11 minute mode.



The question is: Does Busybox ntpd activate this 11 minute mode?

--
Harald



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Denys Vlasenko
$ busybox ntpd --help
BusyBox v1.22.1 (2014-02-01 19:25:19 CET) multi-call binary.

Usage: ntpd [-dnqNwl] [-S PROG] [-p PEER]...

NTP client/server

-dVerbose
-nDo not daemonize
-qQuit after clock is set
-NRun at high priority
-wDo not set time (only query peers), implies -n
-lRun as server on port 123
-p PEERObtain time from PEER (may be repeated)
-S PROGRun PROG after stepping time, stratum change, and every 11 mins
^^
use this to periodically set the hw clock
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Harald Becker

Hi !

As you already note, the kernel does this update of the hardware clock, 
as long as ntpd gets a synchronized clock.


Beside this, an endless loop is no problem:

#!/bin/sh

# the actual loop as a shell function
clock_update_loop()
{
  while true
do
  sleep 3600
  hwclock -w
done
} 0<>/dev/null 1>&0 2>&0

# and here we start it in background
clock_update_loop &

# successful exit
exit 0


Put this in a file and just run it once on system startup. This shall 
automatically return but keep the loop in memory and running, until you 
send it a SIGTERM signal (kill/killall).


The I/O redirection stuff (0<>...) is to avoid clobbering your console 
output from any output the background loop may do just send it to the 
null device).


--
Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-02 Thread Harald Becker

Hi !

> I appreciate that you would like to know why this isn't working but
> I'm really not too keen on rebooting the device several times a day
> when my original script seems to be working fine.

This is your decision, I fully understand your concerns. Just come back, 
when you have need for this ...


> *adjtimex*: The thing I am wondering is, when you run it does it make
> a change that persists through reboots, or does it need to be run
> each time the system comes up?

I never user the Busybox version of adjtimex, but the original versions 
I used wrote a file in /etc (usually /etc/adjtime). This file contains 
all information the system needs to correct the clock. May be it is 
required to run adjtimex on startup, but then with just some constant 
parameter, pointing it to the file in /etc.


> Where it says:


For a machine connected to the Internet, or equipped with a precision
oscillator or radio clock, the best way is to regulate the system clock
with ntpd(8).  The kernel will automatically update the hardware clock
every eleven minutes.


This is correct, if the clock is marked synchronized, the kernel 
automatically updates the hardware clock periodically. This way you 
don't need to manually update the hardware clock in an extra loop. The 
only concern is the clock drift, when Internet connection is not 
available. As soon as ntpd stops updating the clock, the kernel will no 
longer write to the hardware clock.




But that does not work in the Busybox version of adjtimex.


Let me give a couple of days, I try to get a closer look at the Busybox 
adjtimex and send you a step by step description, how to use it.


--
Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread K . S .
Harald Becker  gmx.de> writes:

> 
> Try this one ...
> 
> start() {
>echo -n "Starting ntpd: "
>/usr/sbin/ntpd -p north-america.pool.ntp.org && echo "OK" || echo 
> "failed"
> }

Nope, and again it did something that when I tried to ssh in, it took a long
time (at least ten seconds) for the prompt to appear.  Reverted to my
original and ntpd runs, and the prompt appears instantaneously when I ssh in.
 
> Are you sure your ntpd (a symlink to /bin/busybox) lives in /usr/sbin ?

# which ntpd
/usr/sbin/ntpd

I appreciate that you would like to know why this isn't working but I'm
really not too keen on rebooting the device several times a day when my
original script seems to be working fine.  And what scares me more is the
delay in getting the prompt from a ssh session - my fear is that one time it
won't come up at all and then I am really screwed, since this is a
"headless" system, with no way to connect a display to see what is
happening.  I appreciate your efforts but you're trying to fix something
that from my point of view, really isn't an issue, because there is no way
anyone will ever be able to read that output anyway.  So whether it echoes
"ok" or "failed" is going to make absolutely no difference to anyone.

By the way, you mentioned adjtimex in another post, but then said "The usage
of *adjtimex* is difficult", and I'm already almost in over my head here. 
The thing I am wondering is, when you run it does it make a change that
persists through reboots, or does it need to be run each time the system
comes up?

But more interesting to me is what I found on this page about adjtimex:

http://linuxcommand.org/man_pages/adjtimex8.html

Where it says:

   For a machine connected to the Internet, or equipped with a precision
   oscillator or radio clock, the best way is to regulate the system clock
   with ntpd(8).  The kernel will automatically update the hardware clock
   every eleven minutes.

I have not been keeping a very close eye on the hardware clock since I
started running ntpd yesterday, and I just now checked it and it seems
pretty accurate (within 1 second), so maybe it is getting updated (I will
know more in a few hours). Further down it says:

   There are several ways to estimate the drift rate.  If your computer
   can be connected to the net, you might run ntpd for at least several
   hours and run "adjtimex --print" to learn what values of tick and freq
   it settled on.

But that does not work in the Busybox version of adjtimex.

I am not too worried about the rare case where this system would not have
access to the internet for several days.  While I grant that could happen,
it would be such a rare occurrence that I don't see it being an actual
problem, and I could always do a manual time setting (using the date
command) each day until the Internet comes back. However, I would like to
see the hardware clock remain reasonably accurate in case anything is
accessing that, so if it turns out that ntpd is not updating it as it should
then I will be looking for a way to run hwclock -w every hour or every few
hours, as mentioned in my previous reply to Isaac Dunham.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread K . S .
I wanted to return to this post because of the discussion of crond:

Isaac Dunham  gmail.com> writes:

> Now, if you want cron to work...:

I would be interested in this only because I think it might be a good idea
to run hwclock -w to update the hardware clock about once per hour.  The
only thing that concerns me about that is I don't know what would happen if
the internet were down for a while.

> ps -ef |grep [c]rond

That returns absolutely nothing.

> If there's a '-c /path/to/crontabs', you need to pass that path to crontab:
> crontab -e -c /path/to/crontabs
> (-c ... replaces /var/spoolcron/crontabs with ...)
> 
> If there's no process, check whether the init scripts start crond:
> grep -r crond /etc

That also returns absolutely nothing.  The init script on this system appear
to be in /etc/init.d and there's nothing in there about crond either.  If I
do "which crond" it returns /usr/sbin/crond, so the crond program exists 
 
> If they start it with a -c option pointing to a non-existant directory
> or without -c, create the appropriate diretory.
> Then run crontab -e as root and save it, whether or not it says something
> meaningful (a commented-out line is fine).
> If there are no init scripts, you will need to create one as well as the
> proper directory.

I suspect the reason they don't enable crond is because this is an embedded
device and I don't think it ever occurred to the designers that there might
be a use for it. When I wrote them about the script I'm using to start ntpd,
the response I got gave me the impression that nobody had considered this
use case before.  They then suggested I use hwclock -w to update the
hardware clock, which is why I think it might be a good idea, but their
suggestion was to run it at statup.  The problem is that if I only run that
at each reboot, the hardware clock will still drift away thereafter (losing
around 20 to 25 seconds per day).  So my thought is that once the system
clock is running accurately, it might be a good idea to reset the hardware
clock.  But if they have provided some mechanism to run jobs on a schedule,
I have no idea what it is.

Failing that, I suppose it would work just as well to run an "endless loop"
script at startup. I don't know offhand how to do an endless loop in a
Busybox shell script, but the idea is that it would do something like this:

sleep 3600
hwclock -w
(loop back to sleep statement - got any idea how to do this?)

This may be a bit inelegant but it should update the hardware clock once an
hour starting one hour after the system comes up.  I suppose it would be
better if before updating the hardware clock, it had a way to check that
ntpd is still working, but I don't really know how to do that either.  Of
course this assumes that during "sleep" there is no significant penalty on
the CPU.

Thanks for the suggestions on this.



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread Harald Becker

Try this one ...

start() {
  echo -n "Starting ntpd: "
  /usr/sbin/ntpd -p north-america.pool.ntp.org && echo "OK" || echo 
"failed"

}

Are you sure your ntpd (a symlink to /bin/busybox) lives in /usr/sbin ?



Well, I had nothing to do with building this system so I have no idea why
the formal correct version doesn't seem to want to work.


It is just ugly ... and now I got interested to see why?



Very interesting, and thank you, but it's not something I am particularly
concerned about at the moment,


Yep ... was to give you some information how it works/what we are 
discussing about.




If nothing else, this has been educational.  I'm still hopeful that the
company that makes this device might have a better solution that will work
without any problems.


That would indeed be the better way ...

--
Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread Harald Becker

Hi !

> Actually, the hwclock time is what's inaccurate

:-( ... bad hardware!


That is very interesting but since this system is always connected to the
Internet, I'm not sure I need to be that concerned about the hardware clock.


If your system is always connected to a functioning Internet connection, 
you won't need it, with a running ntpd ... but as you told you are going 
to record Satellite or Terrestrial TV, so think about situations where 
the Internet connection dropped (for which reason ever). As soon as ntpd 
can't contact the public time server, your clock starts to run away from 
the real time. So it will depend how long the Connection is missing. For 
short drop outs, it won't make much difference, but when the connection 
is lost for hours, the time drifts away and your recording time may be 
too. That is using adjtimex to correct you system clock to drift as less 
as possible, will help to solve such Internet drop outs.


It is your decision, if you use it or not, I just wanted to tell you the 
possibility, if you get in need of a solution without working Internet 
connection.



Although, it might be nice if there were a way to check and see if ntpd is
running, and if so, update the hardware clock from the system clock
periodically.


The usual way is to see output of ps/top if process is running, and a 
ping to the time server (see if working connection). Then ntpd normally 
does it's job pretty well. After that, just watch your time, now and the 
day after and see how much clock difference you get ...


--
Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread K . S .
Harald Becker  gmx.de> writes:

> 
> Hi !
> 
> Only as mail, not on ML.
> 
> May be I can help a bit ...
> 
>  >> start() {
> >>echo -n "Starting ntpd: "
> >>/usr/sbin/ntpd -p north-america.pool.ntp.org && \
> >>echo "OK" || { echo "failed"; exit 1 }
> >> }
> 
> I can't see why this shall not work, except if you have put a space 
> after that backslash (\), which would break the line continuation (same 
> as just putting all on one long line).

When I make that change, though, it doesn't work.  Even if I take out the \
and combine the two lines it doesn't work.  I have no clue why that would be.

> That && and || works as follows, when the program (here ntpd daemon 
> start) succeeds with no failure the command after && is executed ("echo 
> OK"), else the command after || is executed (echo "failed", then exit 
> script).

I understand the reasoning, I'm just saying that twice now I've tried to
make that change and it didn't work.  I actually think it messes up ssh in
some way too, because when I've tried to make that change and then
subsequently tried to ssh in, it takes several seconds to get the command
prompt, whereas normally it comes up almost instantaneously (I was almost
afraid I'd somehow bricked the system at first).

> > No idea why your change didn't seem to work but then it occurred to me that
> > it really makes no difference because in this situation nobody's ever going
> > to see that exit code anyway.
> 
> Isaacs change is, to be just formal correct.

Well, I had nothing to do with building this system so I have no idea why
the formal correct version doesn't seem to want to work.

> start-stop-daemon is a command to handle start/stop of such long lived 
> (so called daemon) processes. It may also be an applet of Busybox (but 
> not all do include this). For it's usage see manpage (e.g. Google 
> "start-stop-daemon manpage").
> 
> What Isaac wanted to say is, this start-stop-daemon checks some error 
> conditions, like accidental duplicate invocation and other well known 
> problems. It thereafter give hints about the problem or the possibility 
> to handle those problems in your script. This may make things more 
> stable and fit the formal definition, but is not required to get things 
> going (would hit you only if go to distribute your system to others).

Very interesting, and thank you, but it's not something I am particularly
concerned about at the moment, in part because if this start-stop-daemon is
optional to a particular build then chances are it's not even included in
this one.

If nothing else, this has been educational.  I'm still hopeful that the
company that makes this device might have a better solution that will work
without any problems.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread K . S .
Harald Becker  gmx.de> writes:

> At second, look at your system, if it has a hardware clock (RTC = real 
> time clock). If your system has such a clock, verify if it keeps a 
> better time (Busybox command hwclock). May be you can copy over the time 
> from your hardware clock to the system clock in some interval (this 
> would be a cronjob solution, or running a small daemon script).

Actually, the hwclock time is what's inaccurate

> In addition, for those systems not (permanently) connected to the 
> Internet, you should know there is an automatic time adjusting feature 
> in Linux. Especially if your system time tend to loss time, or run ahead 
> with a more or less constant amount, you can use *adjtimex* to adjust 
> the time. There you enter correct time at a given point, then wait a 
> known duration (e.g. one day). After that you reenter correct time. This 
> calculates fine grained difference, which then get automatically applied 
> to the system clock, so it will no more drift away so much (even without 
> external sync). Repeating this difference calculating several times may 
> help to get your box to an accurate time (like adjusting an old 
> mechanical wall clock). For usage information see manpage of *adtimex* 
> (8) of the Gnu utilities, and search for "Using adjtimex" in the Web. 
> The usage of *adjtimex* is difficult, but allows for many different time 
> related corrections, so you should know of it's availability (in cases 
> you want to contain your box at accurate time without Internet 
> connection). Both usages, adjtimex and ntpd can be combined. Adjtimex 
> tries to speed up or slow down you system clock at a constant rate, 
> which then may be synchronized when Internet connection is available 
> (e.g. with ntpd).

That is very interesting but since this system is always connected to the
Internet, I'm not sure I need to be that concerned about the hardware clock.
 Although, it might be nice if there were a way to check and see if ntpd is
running, and if so, update the hardware clock from the system clock
periodically.

Thnanks for your informative response!




___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread Harald Becker

Hi !

Only as mail, not on ML.

May be I can help a bit ...

>> start() {

echo -n "Starting ntpd: "
/usr/sbin/ntpd -p north-america.pool.ntp.org && \
echo "OK" || { echo "failed"; exit 1 }
}


I can't see why this shall not work, except if you have put a space 
after that backslash (\), which would break the line continuation (same 
as just putting all on one long line).


That && and || works as follows, when the program (here ntpd daemon 
start) succeeds with no failure the command after && is executed ("echo 
OK"), else the command after || is executed (echo "failed", then exit 
script).



No idea why your change didn't seem to work but then it occurred to me that
it really makes no difference because in this situation nobody's ever going
to see that exit code anyway.


Isaacs change is, to be just formal correct.


And a lot of people use start-stop-daemon, probably because it can handle
various corner cases better.


start-stop-daemon is a command to handle start/stop of such long lived 
(so called daemon) processes. It may also be an applet of Busybox (but 
not all do include this). For it's usage see manpage (e.g. Google 
"start-stop-daemon manpage").


What Isaac wanted to say is, this start-stop-daemon checks some error 
conditions, like accidental duplicate invocation and other well known 
problems. It thereafter give hints about the problem or the possibility 
to handle those problems in your script. This may make things more 
stable and fit the formal definition, but is not required to get things 
going (would hit you only if go to distribute your system to others).


--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread K . S .
Isaac Dunham  gmail.com> writes:

> Really, start()  should be a little more like this:
> 
> start() {
>   echo -n "Starting ntpd: "
>   /usr/sbin/ntpd -p north-america.pool.ntp.org && \
>   echo "OK" || { echo "failed"; exit 1 }
> }

I tried the change you suggested and rebooted and when the device came back
up, I ran ps aux and the ntpd process was nowhere to be seen.  I then tried
my original code, rebooted again, and now I see:

1027 root   0:00 /usr/sbin/ntpd -p north-america.pool.ntp.org

No idea why your change didn't seem to work but then it occurred to me that
it really makes no difference because in this situation nobody's ever going
to see that exit code anyway.  If for some reason ntpd doesn't start after a
reboot it will be very noticeable after a couple of days.

> And a lot of people use start-stop-daemon, probably because it can handle
> various corner cases better.

That part of your reply went right over my head.  Most of my Linux
experience is with Ubuntu and I just don't ever do things like this often,
so what you said there may have made sense to other readers but it didn't to
me.  I don't even have a frame of reference for that comment.

> But in general, that should work, even if it's not the optimal way.
> You won't have more than one instance of ntpd running, for an example
> of the sort of corner cases I mean...

I'm not sure how that could happen anyway since it's only invoked by the
script once.  And I only saw one instance running in the ps aux listing.

If you're trying to point out something that you think I should actually be
concerned about, please try to restate it in the way you'd explain it to a
newbie Linux user, because I'm not getting it.  If that was more of an
academic observation, then I just wish I understood it better.  Either way,
thanks for your comments.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-09-01 Thread Harald Becker

Hi !

> Anyway, what I really want to know is, what's the easiest way to
> make this device keep accurate time?

Ok, you already got a solution for your problem, which runs perfectly 
fine, as long as you have an Internet connection with a not to high latency.


In addition, I like to put my cent to your question, giving some extra 
information, which may be of interest.


First of all, Busybox does not *KEEP* the time. This is the duty of the 
system kernel of your box. Busybox has just some tools to query and set 
the time in the kernel. When the clock of your box constantly steps 
ahead or behind real time, the system timer (maintained by the kernel) 
does not work accurate or at the expected speed. So may be, you can ask 
the manufacturer of the system to fix the time problem.


At second, look at your system, if it has a hardware clock (RTC = real 
time clock). If your system has such a clock, verify if it keeps a 
better time (Busybox command hwclock). May be you can copy over the time 
from your hardware clock to the system clock in some interval (this 
would be a cronjob solution, or running a small daemon script).


In addition, for those systems not (permanently) connected to the 
Internet, you should know there is an automatic time adjusting feature 
in Linux. Especially if your system time tend to loss time, or run ahead 
with a more or less constant amount, you can use *adjtimex* to adjust 
the time. There you enter correct time at a given point, then wait a 
known duration (e.g. one day). After that you reenter correct time. This 
calculates fine grained difference, which then get automatically applied 
to the system clock, so it will no more drift away so much (even without 
external sync). Repeating this difference calculating several times may 
help to get your box to an accurate time (like adjusting an old 
mechanical wall clock). For usage information see manpage of *adtimex* 
(8) of the Gnu utilities, and search for "Using adjtimex" in the Web. 
The usage of *adjtimex* is difficult, but allows for many different time 
related corrections, so you should know of it's availability (in cases 
you want to contain your box at accurate time without Internet 
connection). Both usages, adjtimex and ntpd can be combined. Adjtimex 
tries to speed up or slow down you system clock at a constant rate, 
which then may be synchronized when Internet connection is available 
(e.g. with ntpd).


--
Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-08-31 Thread Isaac Dunham
On Sun, Aug 31, 2014 at 10:45:09PM +, K.S. wrote:
> Isaac Dunham  gmail.com> writes:
> 
> > Yes, it's because of the -q option; remove it if you want ntpd to run
> > as a daemon.
> 
> Thank you.  I did that and now it shows up in the process list, so I hope
> it's actually working!
> 
> > Put a line starting ntpd in the appropriate init script or
> > add an init script starting it.
> > I can't tell you what this looks like in more detail, because I have no
> > idea what init system you use.
> 
> It looks to me like all the init scripts on this system are in /etc/init.d
> and that I should just be able to create a new script in that directory
> called S95ntpd containing the following:
> 
> #!/bin/sh
> #
> # ntpdStarts ntpd
> #
> 
> start() {
>   echo -n "Starting ntpd: "
>   /usr/sbin/ntpd -p north-america.pool.ntp.org
>   echo "OK"
> }
> stop() {
>   echo -n "Stopping ntpd: "
>   killall ntpd
>   echo "OK"
> }
> restart() {
>   stop
>   start
> }
> 
> case "$1" in
>   start)
>   start
>   ;;
>   stop)
>   stop
>   ;;
>   restart|reload)
>   restart
>   ;;
>   *)
>   echo "Usage: $0 {start|stop|restart}"
>   exit 1
> esac
> 
> exit $?
> 
> I want to wait a few hours and make sure that ntpd is really working before
> I install that script, but does the script itself look okay?  I basically
> took another script that was already there and edited it to start ntpd.

Really, start()  should be a little more like this:

start() {
echo -n "Starting ntpd: "
/usr/sbin/ntpd -p north-america.pool.ntp.org && \
echo "OK" || { echo "failed"; exit 1 }
}

And a lot of people use start-stop-daemon, probably because it can handle
various corner cases better.
But in general, that should work, even if it's not the optimal way.
You won't have more than one instance of ntpd running, for an example
of the sort of corner cases I mean...

HTH,
Isaac Dunham
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-08-31 Thread K . S .
Isaac Dunham  gmail.com> writes:

> Yes, it's because of the -q option; remove it if you want ntpd to run
> as a daemon.

Thank you.  I did that and now it shows up in the process list, so I hope
it's actually working!

> Put a line starting ntpd in the appropriate init script or
> add an init script starting it.
> I can't tell you what this looks like in more detail, because I have no
> idea what init system you use.

It looks to me like all the init scripts on this system are in /etc/init.d
and that I should just be able to create a new script in that directory
called S95ntpd containing the following:

#!/bin/sh
#
# ntpdStarts ntpd
#

start() {
echo -n "Starting ntpd: "
/usr/sbin/ntpd -p north-america.pool.ntp.org
echo "OK"
}
stop() {
echo -n "Stopping ntpd: "
killall ntpd
echo "OK"
}
restart() {
stop
start
}

case "$1" in
  start)
start
;;
  stop)
stop
;;
  restart|reload)
restart
;;
  *)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac

exit $?

I want to wait a few hours and make sure that ntpd is really working before
I install that script, but does the script itself look okay?  I basically
took another script that was already there and edited it to start ntpd.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: What's the easiest way to make Busybox keep correct time?

2014-08-31 Thread Isaac Dunham
On Sun, Aug 31, 2014 at 07:04:52PM +, K.S. wrote:
> As I mentioned in a previous message, I am in the process of setting up a a
> small backend receiver box for free-to-air satellite television that
> includes Busybox.  It has the ability to record programs on a schedule, and
> for some unknown reason it appears the designers forgot to implement a way
> to keep the time set correctly.  Right now it appears to be losing about one
> second per hour, give or take a little, which means that after a couple of
> days it's a full minute off, which is really bad when you are trying to
> accurately schedule recordings.
> 
> I read in one of these threads that I can correct the time by entering this
> at the command prompt:
> 
> ntpd -q -p pool.ntp.org
> 
> And that does work, but it only sets the time once, and does not keep the
> time accurate over any long period (is that because of the -q option?)

Yes, it's because of the -q option; remove it if you want ntpd to run
as a daemon.

> Anyway, what I really want to know is, what's the easiest way to make this
> device keep accurate time?  I assume that I need something that will run in
> the background and periodically query the time server and adjust the time,
> and also some way to make sure that gets started after every reboot.  This
> seems like this should be very easy, but I'll ask you experts, what would be
> the easiest or best way?
> 
> I will note that it does not appear as if crontab is fully implemented,
> because if I try to run crontab with the -l or -e option it displays,
> "crontab: can't change directory to '/var/spool/cron/crontabs': No such file
> or directory".  So if there is a way to do this that doesn't involve using
> crontab, that might be better, although reliability is my #1 concern.
> 
Put a line starting ntpd in the appropriate init script or
add an init script starting it.
I can't tell you what this looks like in more detail, because I have no
idea what init system you use.

You do not want to run ntpd from cron; busybox cron eventually gives up 
if there's too big a jump in time. (At least, that's how I interpret
the logs I've had...)


Now, if you want cron to work...:
ps -ef |grep [c]rond
If there's a '-c /path/to/crontabs', you need to pass that path to crontab:
crontab -e -c /path/to/crontabs
(-c ... replaces /var/spoolcron/crontabs with ...)

If there's no process, check whether the init scripts start crond:
grep -r crond /etc

If they start it with a -c option pointing to a non-existant directory
or without -c, create the appropriate diretory.
Then run crontab -e as root and save it, whether or not it says something
meaningful (a commented-out line is fine).
If there are no init scripts, you will need to create one as well as the
proper directory.


HTH,
Isaac Dunham

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox