I have a small embedded linux machine. Moxa UC-7112 Plus that I want to
use as NTP server. http://www.moxa.com/product/UC-7110-LX.htm
Its has MOXA ART ARM9 32-bit 192 MHz processor CPU.

Here are statistics I collected after using it a bit.  This is using gpsd
2.33 to collect NMEA, PPS.


     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
+SHM(0)          .NMEA.           0 l    8   16  377    0.000  -21.691
7.812
*SHM(1)          .PPS.            0 l    1   16  377    0.000  -17.105
7.81

ntpq> cv
status=0101 clk_noreply, last_clk_noreply,
device="SHM/Shared memory interface", timecode=, poll=54, noreply=78,
badformat=0, baddata=0, fudgetime1=0.000, stratum=0, refid=PPS, flags=0
ntpq> rv
status=09e4 leap_none, sync_telephone, 14 events, event_peer/strat_chg,
version="ntpd 4.1.1@1.786 Tue Sep 11 19:14:27 CDT 2007 (1)",
processor="armv4tl", system="Linux2.6.9-uc0", leap=00, stratum=1,
precision=-7, rootdelay=0.000, rootdispersion=32.592, peer=4253,
refid=PPS, reftime=cd44982f.b9359791  Tue, Feb 17 2009  9:58:07.723,
poll=4, clock=cd449838.649a9973  Tue, Feb 17 2009  9:58:16.392, state=4,
offset=-13.494, frequency=142.853, jitter=7.908, stability=4.197

root@Moxa:~# cat /proc/cpuinfo
Processor    : ARM922Tid(wb) rev 1 (v4l)
BogoMIPS    : 76.59
Features    : swp half thumb
CPU implementer    : 0x66
CPU architecture: 4
CPU variant    : 0x0
CPU part    : 0x526
CPU revision    : 1
Cache type    : VIVT write-back
Cache clean    : cp15 c7 ops
Cache lockdown    : format B
Cache format    : Harvard
I size        : 16384
I assoc        : 2
I line length    : 16
I sets        : 512
D size        : 16384
D assoc        : 2
D line length    : 16
D sets        : 512

Some gpsd messages in case :
gpsd: <= GPS: $GPZDA,020012.000,17,02,2009,,*58
gpsd: carrier-detect on /dev/ttyM1 changed to 0
gpsd: carrier-detect on /dev/ttyM1 changed to 1
gpsd: ntpshm_pps: precision -6

ntp.conf
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.411 refid NMEA
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid PPS

I am curious if the platform is the limitation, or if there are things that
can be done to make this work well as a NTP server, because now the accuracy
is unacceptable.  Ideas?

cnm3332@gmail.com (Christopher Mire) writes:

>I have a small embedded linux machine. Moxa UC-7112 Plus that I want to
>use as NTP server. http://www.moxa.com/product/UC-7110-LX.htm
>Its has MOXA ART ARM9 32-bit 192 MHz processor CPU.

>Here are statistics I collected after using it a bit.  This is using gpsd
>2.33 to collect NMEA, PPS.

"a bit" means what? Remember that ntpd takes 1 hour to cut the error by
half. Thus unless you ran this for more than 10 hours, these offsets mean
nothing.




>     remote           refid      st t when poll reach   delay   offset
>jitter
>==============================================================================
>+SHM(0)          .NMEA.           0 l    8   16  377    0.000  -21.691
>7.812
>*SHM(1)          .PPS.            0 l    1   16  377    0.000  -17.105
>7.81

>ntpq> cv
>status=0101 clk_noreply, last_clk_noreply,
>device="SHM/Shared memory interface", timecode=, poll=54, noreply=78,
>badformat=0, baddata=0, fudgetime1=0.000, stratum=0, refid=PPS, flags=0
>ntpq> rv
>status=09e4 leap_none, sync_telephone, 14 events, event_peer/strat_chg,
>version="ntpd 4.1.1@1.786 Tue Sep 11 19:14:27 CDT 2007 (1)",
>processor="armv4tl", system="Linux2.6.9-uc0", leap=00, stratum=1,
>precision=-7, rootdelay=0.000, rootdispersion=32.592, peer=4253,
>refid=PPS, reftime=cd44982f.b9359791  Tue, Feb 17 2009  9:58:07.723,
>poll=4, clock=cd449838.649a9973  Tue, Feb 17 2009  9:58:16.392, state=4,
>offset=-13.494, frequency=142.853, jitter=7.908, stability=4.197

>root@Moxa:~# cat /proc/cpuinfo
>Processor    : ARM922Tid(wb) rev 1 (v4l)
>BogoMIPS    : 76.59
>Features    : swp half thumb
>CPU implementer    : 0x66
>CPU architecture: 4
>CPU variant    : 0x0
>CPU part    : 0x526
>CPU revision    : 1
>Cache type    : VIVT write-back
>Cache clean    : cp15 c7 ops
>Cache lockdown    : format B
>Cache format    : Harvard
>I size        : 16384
>I assoc        : 2
>I line length    : 16
>I sets        : 512
>D size        : 16384
>D assoc        : 2
>D line length    : 16
>D sets        : 512

>Some gpsd messages in case :
>gpsd: <= GPS: $GPZDA,020012.000,17,02,2009,,*58
>gpsd: carrier-detect on /dev/ttyM1 changed to 0
>gpsd: carrier-detect on /dev/ttyM1 changed to 1
>gpsd: ntpshm_pps: precision -6

>ntp.conf
>server 127.127.28.0 minpoll 4 maxpoll 4
>fudge 127.127.28.0 time1 0.411 refid NMEA
>server 127.127.28.1 minpoll 4 maxpoll 4 prefer
>fudge 127.127.28.1 refid PPS

>I am curious if the platform is the limitation, or if there are things that
>can be done to make this work well as a NTP server, because now the accuracy
>is unacceptable.  Ideas?

On 2009-02-18, Unruh <unruh-spam@physics.ubc.ca> wrote:

> cnm3332@gmail.com (Christopher Mire) writes:
>
>>I have a small embedded linux machine. Moxa UC-7112 Plus that I want
>>to use as NTP server. http://www.moxa.com/product/UC-7110-LX.htm Its
>>has MOXA ART ARM9 32-bit 192 MHz processor CPU.
>
>>Here are statistics I collected after using it a bit. This is using
>>gpsd 2.33 to collect NMEA, PPS.
>
> "a bit" means what? Remember that ntpd takes 1 hour to cut the error
> by half. Thus unless you ran this for more than 10 hours, these
> offsets mean nothing.

Poppycock.

A snapshot is merely a snapshot regardless of when it is taken.

Long term performance is what's important. It may be evaluated through
the use of multiple snapshots (over a suitable period) or by summarizing
the statistics files.

> [---=| TOFU protection by t-prot: 53 lines snipped |=---]

--> http://www.netmeister.org/news/learn2quote.html

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

On Tue, 17 Feb 2009 04:17:44 GMT, Christopher Mire wrote:
> I have a small embedded linux machine. Moxa UC-7112 Plus that I want to
> use as NTP server. http://www.moxa.com/product/UC-7110-LX.htm
> Its has MOXA ART ARM9 32-bit 192 MHz processor CPU.
>
> Here are statistics I collected after using it a bit.  This is using gpsd
> 2.33 to collect NMEA, PPS.
>
>
>      remote           refid      st t when poll reach   delay   offset
> jitter
>==============================================================================
> +SHM(0)          .NMEA.           0 l    8   16  377    0.000  -21.691
> 7.812
> *SHM(1)          .PPS.            0 l    1   16  377    0.000  -17.105
> 7.81
>
> ntpq> cv
> status=0101 clk_noreply, last_clk_noreply,
> device="SHM/Shared memory interface", timecode=, poll=54, noreply=78,
> badformat=0, baddata=0, fudgetime1=0.000, stratum=0, refid=PPS, flags=0
> ntpq> rv
> status=09e4 leap_none, sync_telephone, 14 events, event_peer/strat_chg,
> version="ntpd 4.1.1@1.786 Tue Sep 11 19:14:27 CDT 2007 (1)",
> processor="armv4tl", system="Linux2.6.9-uc0", leap=00, stratum=1,
> precision=-7, rootdelay=0.000, rootdispersion=32.592, peer=4253,
precision=-7 is not that spectacular.
Are there other options for clocks on the board?
/hjj

Steve Kostecke <kostecke@ntp.org> writes:

>On 2009-02-18, Unruh <unruh-spam@physics.ubc.ca> wrote:

>> cnm3332@gmail.com (Christopher Mire) writes:
>>
>>>I have a small embedded linux machine. Moxa UC-7112 Plus that I want
>>>to use as NTP server. http://www.moxa.com/product/UC-7110-LX.htm Its
>>>has MOXA ART ARM9 32-bit 192 MHz processor CPU.
>>
>>>Here are statistics I collected after using it a bit. This is using
>>>gpsd 2.33 to collect NMEA, PPS.
>>
>> "a bit" means what? Remember that ntpd takes 1 hour to cut the error
>> by half. Thus unless you ran this for more than 10 hours, these
>> offsets mean nothing.

>Poppycock.

>A snapshot is merely a snapshot regardless of when it is taken.

But a snapshot taken before the system has settled down to its long term
behaviour is especially useless. The way ntp works is that intially it
takes a while to settle down to its long term behaviour. With PPS control
it usually settles down to usec offset but it takes of order of 10 hours to
do so. Thus snapshots taken long before that are especially useless. If
after 10 hours the system still has msec offsets from a PPS then there is
something seriously wrong.


>Long term performance is what's important. It may be evaluated through
>the use of multiple snapshots (over a suitable period) or by summarizing
>the statistics files.

Long term performance with completely rediculous short term performance (
17ms from a PPS control) means nothing. 

IF his system has been running for 10 hours or more and he has 17ms
offsets, his system is broken. If it has been running for only 1 hour then
that kind of offset is not at all unusual.

And a single snapshot is all I need to tell me that.



>> [---=| TOFU protection by t-prot: 53 lines snipped |=---]

>--> http://www.netmeister.org/news/learn2quote.html

>-- 
>Steve Kostecke <kostecke@ntp.org>
>NTP Public Services Project - http://support.ntp.org/

Unruh <unruh-spam@physics.ubc.ca> wrote:
> But a snapshot taken before the system has settled down to its long term
> behaviour is especially useless. The way ntp works is that intially it
> takes a while to settle down to its long term behaviour. With PPS control
> it usually settles down to usec offset but it takes of order of 10 hours to
> do so. Thus snapshots taken long before that are especially useless. If
> after 10 hours the system still has msec offsets from a PPS then there is
> something seriously wrong.

He is not using a PPS in the sense that you are talking about.
He uses the PPS support in gpsd which is written in user space and
will settle to around 10us on a fast system that is not overloaded.
On a slow embedded board it may be different, I have no experience
with running gpsd on those.

On Feb 19, 11:32=A0am, Rob <nom...@example.com> wrote:
> Unruh <unruh-s...@physics.ubc.ca> wrote:
> > But a snapshot taken before the system has settled down to its long ter=
m
> > behaviour is especially useless. The way ntp works is that intially it
> > takes a while to settle down to its long term behaviour. With PPS contr=
ol
> > it usually settles down to usec offset but it takes of order of 10 hour=
s to
> > do so. Thus snapshots taken long before that are especially useless. If
> > after 10 hours the system still has msec offsets from a PPS then there =
is
> > something seriously wrong.
>
> He is not using a PPS in the sense that you are talking about.
> He uses the PPS support in gpsd which is written in user space and
> will settle to around 10us on a fast system that is not overloaded.
> On a slow embedded board it may be different, I have no experience
> with running gpsd on those.

The server is not running all the time, and it used on platform that
once
booted, which need accurate time within minutes.  We already run these
tools on a fast x86 machine, and it syncs very quickly and provides
very
good accuracy.  We are trying to migrate to the MOXA board, but
performance is much poorer.  I was more curious about things I could
configure so that NTP would be usable on this slower machine, even if
it took longer to get stable.  Should I look into increasing baud rate
of
serial, less polling interval, etc?  The linux distro is very small,
and provides
practically no tools, I'm not even sure how loaded the processor
becomes
with gpsd and ntpd.  Is there an effective way of checking that it is
not
too much for machine?  Thanks.

cnm3332@gmail.com <cnm3332@gmail.com> wrote:
> practically no tools, I'm not even sure how loaded the processor
> becomes
> with gpsd and ntpd.  Is there an effective way of checking that it is
> not
> too much for machine?  Thanks.

gpsd is not particularly efficient (i.e. it will use some cpu), but
it is no problem on a PC.

You can always try the command "uptime" to see the load average of the
system, it should be well below 1.00
You can also run "ps ax" and see what times appear in the TIME column
for gpsd and ntpd.   Compare those with the uptime of the system, to see
how much CPU each of them uses.
You could also use "top" to see what is running.

Rob <nomail@example.com> writes:

>Unruh <unruh-spam@physics.ubc.ca> wrote:
>> But a snapshot taken before the system has settled down to its long term
>> behaviour is especially useless. The way ntp works is that intially it
>> takes a while to settle down to its long term behaviour. With PPS control
>> it usually settles down to usec offset but it takes of order of 10 hours to
>> do so. Thus snapshots taken long before that are especially useless. If
>> after 10 hours the system still has msec offsets from a PPS then there is
>> something seriously wrong.

>He is not using a PPS in the sense that you are talking about.
>He uses the PPS support in gpsd which is written in user space and
>will settle to around 10us on a fast system that is not overloaded.
>On a slow embedded board it may be different, I have no experience
>with running gpsd on those.

I will accept 10usec, which is way way better than 17msec. Again, if he was
connected for 10 hours ( well lets say 7 hr if your long term accuracy is
10usec) and he has 17 msec offset something is very wrong. If he was
connected on hour, it is to be expected. Thus, how long was he connected?

cnm3332@gmail.com writes:

>On Feb 19, 11:32=A0am, Rob <nom...@example.com> wrote:
>> Unruh <unruh-s...@physics.ubc.ca> wrote:
>> > But a snapshot taken before the system has settled down to its long ter=
>m
>> > behaviour is especially useless. The way ntp works is that intially it
>> > takes a while to settle down to its long term behaviour. With PPS contr=
>ol
>> > it usually settles down to usec offset but it takes of order of 10 hour=
>s to
>> > do so. Thus snapshots taken long before that are especially useless. If
>> > after 10 hours the system still has msec offsets from a PPS then there =
>is
>> > something seriously wrong.
>>
>> He is not using a PPS in the sense that you are talking about.
>> He uses the PPS support in gpsd which is written in user space and
>> will settle to around 10us on a fast system that is not overloaded.
>> On a slow embedded board it may be different, I have no experience
>> with running gpsd on those.

>The server is not running all the time, and it used on platform that
>once
>booted, which need accurate time within minutes.  We already run these

Then do not use ntp. Its behaviour is converging to the correct time is
very very slow. It is a completely inappropriate tool for the requirement
that you have. chrony is much better.

>tools on a fast x86 machine, and it syncs very quickly and provides
>very
>good accuracy.  We are trying to migrate to the MOXA board, but
>performance is much poorer.  I was more curious about things I could
>configure so that NTP would be usable on this slower machine, even if
>it took longer to get stable.  Should I look into increasing baud rate
>of
>serial, less polling interval, etc?  The linux distro is very small,

It is the algorithm that is at fault, not the machine. (well, the machine
may also be at fault, but the algorithm simply cannot supply the accuracy
you wish at the speed you want it).

>and provides
>practically no tools, I'm not even sure how loaded the processor
>becomes
>with gpsd and ntpd.  Is there an effective way of checking that it is
>not
>too much for machine?  Thanks.

ps
top

Anyway, it isnot too much. Far far slower machines can handle it.

On Feb 19, 3:16=A0pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
> cnm3...@gmail.com writes:
> >On Feb 19, 11:32=3DA0am, Rob <nom...@example.com> wrote:
> >> Unruh <unruh-s...@physics.ubc.ca> wrote:
> >> > But a snapshot taken before the system has settled down to its long =
ter=3D
> >m
> >> > behaviour is especially useless. The way ntp works is that intially =
it
> >> > takes a while to settle down to its long term behaviour. With PPS co=
ntr=3D
> >ol
> >> > it usually settles down to usec offset but it takes of order of 10 h=
our=3D
> >s to
> >> > do so. Thus snapshots taken long before that are especially useless.=
 If
> >> > after 10 hours the system still has msec offsets from a PPS then the=
re =3D
> >is
> >> > something seriously wrong.
>
> >> He is not using a PPS in the sense that you are talking about.
> >> He uses the PPS support in gpsd which is written in user space and
> >> will settle to around 10us on a fast system that is not overloaded.
> >> On a slow embedded board it may be different, I have no experience
> >> with running gpsd on those.
> >The server is not running all the time, and it used on platform that
> >once
> >booted, which need accurate time within minutes. =A0We already run these
>
> Then do not use ntp. Its behaviour is converging to the correct time is
> very very slow. It is a completely inappropriate tool for the requirement
> that you have. chrony is much better.
>
> >tools on a fast x86 machine, and it syncs very quickly and provides
> >very
> >good accuracy. =A0We are trying to migrate to the MOXA board, but
> >performance is much poorer. =A0I was more curious about things I could
> >configure so that NTP would be usable on this slower machine, even if
> >it took longer to get stable. =A0Should I look into increasing baud rate
> >of
> >serial, less polling interval, etc? =A0The linux distro is very small,
>
> It is the algorithm that is at fault, not the machine. (well, the machine
> may also be at fault, but the algorithm simply cannot supply the accuracy
> you wish at the speed you want it).
>
> >and provides
> >practically no tools, I'm not even sure how loaded the processor
> >becomes
> >with gpsd and ntpd. =A0Is there an effective way of checking that it is
> >not
> >too much for machine? =A0Thanks.
>
> ps
> top
>
> Anyway, it isnot too much. Far far slower machines can handle it.

We have been using NTP for long time, and it always converged to
sub millisecond accuracy very quickly.  Of course we used burst
and iburst options in conf file, but I had disabled those on MOXA
board, out of worries about CPU usage.  I would say our
requirements are at least 100usec accuracy for time, and that it
synchronize within 5 minutes.  NTP on our fast x86 machine
always satisifed this, but having trouble on MOXA board.

I was not aware of other programs for this purpose.  I'm guessing
chrony can act as NTP server for other machines running NTP
to get time from?  Does it provide level of accuracy and
convergence time required?

The data was collected after about 30 minutes I believe.  I guess
I'm so used to super fast convergence, that 30 minutes seemed
like long time.

Thanks for tip on uptime/ ps ax will try.  Doesn't have top program
built in, may try compiling it if first method doesnt work out. Thanks
for the help so far, much appreciated.

Unruh wrote:

> Then do not use ntp. Its behaviour is converging to the correct time is
> very very slow. It is a completely inappropriate tool for the requirement
> that you have. chrony is much better.

chrony is excluded because it doesn't support locally attached reference 
clocks.
> 

Hans J=F8rgen Jakobsen wrote:

> precision=3D-7 is not that spectacular.
> Are there other options for clocks on the board?

Exactly, although the convergence time requirements are also unrealistic =

for ntpd.

precision -7 tends to suggest the hardware is using a 10ms clock with no =

interpolation, which means that times read by the application, and in=20
ntpd offsets, have a built in 10ms peak to peak error term.

Once converged to a network source, one would expect up to an order of=20
magnitude better setting for the time than indicated by the offset, but=20
you will still only be able to read it to 10ms.  I'm not sure that there =

will be enough noise in the SHM PPS readings to dither them=20
successfully, so there is some risk that it will hop between two 10ms ste=
ps.

On Feb 19, 1:56=A0am, David Woolley
<da...@ex.djwhome.demon.co.uk.invalid> wrote:
> Hans J=F8rgen Jakobsen wrote:
> > precision=3D-7 is not that spectacular.
> > Are there other options for clocks on the board?
>
> Exactly, although the convergence time requirements are also unrealistic
> for ntpd.
>
> precision -7 tends to suggest the hardware is using a 10ms clock with no
> interpolation, which means that times read by the application, and in
> ntpd offsets, have a built in 10ms peak to peak error term.
>
> Once converged to a network source, one would expect up to an order of
> magnitude better setting for the time than indicated by the offset, but
> you will still only be able to read it to 10ms. =A0I'm not sure that ther=
e
> will be enough noise in the SHM PPS readings to dither them
> successfully, so there is some risk that it will hop between two 10ms ste=
ps.

Hm, so perhaps hardware is not ideal for NTP server then.  I think I
will
start looking at other embedded systems then, maybe sticking with
x86 like via eden or something.  Is there anyway I can know accuracy
of clock?  People have recommendations on what small systems
I should try?

You may want to use mlockall() to lock ntp into RAM and prevent it from
being swapped.  You may also need to use sched_setscheduler() to make it a
real-time process with a high priority.  These changes will require a
little hacking.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

>>> In article <871vtsy3ud.fsf@thumper.dhh.gt.org>, John Hasler <john@dhh.gt.org> writes:

John> You may want to use mlockall() to lock ntp into RAM and prevent it
John> from being swapped.  You may also need to use sched_setscheduler() to
John> make it a real-time process with a high priority.  These changes will
John> require a little hacking.

mlockall() and sched_setscheduler() should be discovered automatically by
the 'configure' step.  I think mlockall() is the default on many OSes that
provide it, and the -N option probably controls the priority setting.

-- 
Harlan Stenn <stenn@ntp.org>
http://ntpforum.isc.org  - be a member!

cnm3332@gmail.com writes:

>On Feb 19, 3:16=A0pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
>> cnm3...@gmail.com writes:
>> >On Feb 19, 11:32=3DA0am, Rob <nom...@example.com> wrote:
>> >> Unruh <unruh-s...@physics.ubc.ca> wrote:
>> >> > But a snapshot taken before the system has settled down to its long =
>ter=3D
>> >m
>> >> > behaviour is especially useless. The way ntp works is that intially =
>it
>> >> > takes a while to settle down to its long term behaviour. With PPS co=
>ntr=3D
>> >ol
>> >> > it usually settles down to usec offset but it takes of order of 10 h=
>our=3D
>> >s to
>> >> > do so. Thus snapshots taken long before that are especially useless.=
> If
>> >> > after 10 hours the system still has msec offsets from a PPS then the=
>re =3D
>> >is
>> >> > something seriously wrong.
>>
>> >> He is not using a PPS in the sense that you are talking about.
>> >> He uses the PPS support in gpsd which is written in user space and
>> >> will settle to around 10us on a fast system that is not overloaded.
>> >> On a slow embedded board it may be different, I have no experience
>> >> with running gpsd on those.
>> >The server is not running all the time, and it used on platform that
>> >once
>> >booted, which need accurate time within minutes. =A0We already run these
>>
>> Then do not use ntp. Its behaviour is converging to the correct time is
>> very very slow. It is a completely inappropriate tool for the requirement
>> that you have. chrony is much better.
>>
>> >tools on a fast x86 machine, and it syncs very quickly and provides
>> >very
>> >good accuracy. =A0We are trying to migrate to the MOXA board, but
>> >performance is much poorer. =A0I was more curious about things I could
>> >configure so that NTP would be usable on this slower machine, even if
>> >it took longer to get stable. =A0Should I look into increasing baud rate
>> >of
>> >serial, less polling interval, etc? =A0The linux distro is very small,
>>
>> It is the algorithm that is at fault, not the machine. (well, the machine
>> may also be at fault, but the algorithm simply cannot supply the accuracy
>> you wish at the speed you want it).
>>
>> >and provides
>> >practically no tools, I'm not even sure how loaded the processor
>> >becomes
>> >with gpsd and ntpd. =A0Is there an effective way of checking that it is
>> >not
>> >too much for machine? =A0Thanks.
>>
>> ps
>> top
>>
>> Anyway, it isnot too much. Far far slower machines can handle it.

>We have been using NTP for long time, and it always converged to
>sub millisecond accuracy very quickly.  Of course we used burst
>and iburst options in conf file, but I had disabled those on MOXA
>board, out of worries about CPU usage.  I would say our
>requirements are at least 100usec accuracy for time, and that it
>synchronize within 5 minutes.  NTP on our fast x86 machine

Youwill not get that from ntp. Mills has explicitely stated that he is
completely uninterested in any questin of speed of convergence of ntp. For
him the slow convergence is a feature, not a bug.


>always satisifed this, but having trouble on MOXA board.

>I was not aware of other programs for this purpose.  I'm guessing
>chrony can act as NTP server for other machines running NTP
>to get time from?  Does it provide level of accuracy and
>convergence time required?

Ye, Yes. BUT. It cannot ( yet) get its time from a hardware clock (eg PPS).
I have been meaning to try to add that but I am busy doing my physics, and
a bit scared about messing up since I do not have that much faith in my
coding skills, or in roperly designing the interface to a=a hardware clock
in chrony.



>The data was collected after about 30 minutes I believe.  I guess
>I'm so used to super fast convergence, that 30 minutes seemed
>like long time.

Wait 10 hours and then look at the data. ntp is espeically intollerant of
rate errors. Recent linux kernels have a bug in their tsc calibration
routines and will make 50PPM errors in the clock rate on bootup. ntp takes
about 8-10 hours to correct these errors (experimental evidence).



>Thanks for tip on uptime/ ps ax will try.  Doesn't have top program
>built in, may try compiling it if first method doesnt work out. Thanks
>for the help so far, much appreciated.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:

>Unruh wrote:

>> Then do not use ntp. Its behaviour is converging to the correct time is
>> very very slow. It is a completely inappropriate tool for the requirement
>> that you have. chrony is much better.

>chrony is excluded because it doesn't support locally attached reference 
>clocks.

Agreed. I was so concentrated on the rate question I negected the fact that
he is running a PPS clock. 
So at present he is stuck. Make sure you have no /etc/ntp/drift file. Use
-g, and use the iburst, etc to try to reduce the startup transientx.

>> 

On Feb 20, 10:27=A0pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
> >Unruh wrote:
> >> Then do not use ntp. Its behaviour is converging to the correct time i=
s
> >> very very slow. It is a completely inappropriate tool for the requirem=
ent
> >> that you have. chrony is much better.
> >chrony is excluded because it doesn't support locally attached reference
> >clocks.
>
> Agreed. I was so concentrated on the rate question I negected the fact th=
at
> he is running a PPS clock.
> So at present he is stuck. Make sure you have no /etc/ntp/drift file. Use
> -g, and use the iburst, etc to try to reduce the startup transientx.
>
>

So, I will need to let NTP run for long time, to build correct drift
file, which might
help with accuracy and sync time?   So should this be my ntp conf file
for
doing this

ntp.conf
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 burst iburst refid NMEA
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 burst iburst refid PPS

Not sure I understand need for -g option though.
I'm was looking at other computers to try, something
small and low power, and found this neat little thing:
http://www.axiomtek.com/Download/Spec/ebox530-820-fl.pdf

cnm3332@gmail.com wrote:

> 
> ntp.conf
> server 127.127.28.0 minpoll 4 maxpoll 4
> fudge 127.127.28.0 burst iburst refid NMEA

I don't believe that burst and iburst are meaningful for reference 
clocks.  To get an accurate drift file, you want a large maxpoll, 
although, in practice, you may find that minpoll and maxpoll are ignored 
for your reference clock.

> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 burst iburst refid PPS
> 

On Thu, 19 Feb 2009 13:14:01 -0800 (PST), cnm3332@gmail.com wrote:
> On Feb 19, 1:56�am, David Woolley
><da...@ex.djwhome.demon.co.uk.invalid> wrote:
>> Hans J�rgen Jakobsen wrote:
>> > precision=-7 is not that spectacular.
>> > Are there other options for clocks on the board?
>>
>> Exactly, although the convergence time requirements are also unrealistic
>> for ntpd.
>>
>> precision -7 tends to suggest the hardware is using a 10ms clock with no
>> interpolation, which means that times read by the application, and in
>> ntpd offsets, have a built in 10ms peak to peak error term.
>>
>> Once converged to a network source, one would expect up to an order of
>> magnitude better setting for the time than indicated by the offset, but
>> you will still only be able to read it to 10ms. �I'm not sure that there
>> will be enough noise in the SHM PPS readings to dither them
>> successfully, so there is some risk that it will hop between two 10ms steps.
>
> Hm, so perhaps hardware is not ideal for NTP server then.  I think I
> will
> start looking at other embedded systems then, maybe sticking with
> x86 like via eden or something.  Is there anyway I can know accuracy
> of clock?  People have recommendations on what small systems
> I should try?

Or you should look at soekris.com. I have no personal exp.
PHK and other has written something about these boards.
http://phk.freebsd.dk/soekris/pps/
Warning: You are entering an area that will take much of your time :)
/hjj

In article <ZlLnl.12817$Db2.742@edtnps83>, Unruh <unruh-spam@physics.ubc.ca> writes:

> cnm3332@gmail.com writes:
>> We have been using NTP for long time, and it always converged to sub
>> millisecond accuracy very quickly.  Of course we used burst and iburst
>> options in conf file, but I had disabled those on MOXA board, out of
>> worries about CPU usage.  I would say our requirements are at least
>> 100usec accuracy for time, and that it synchronize within 5 minutes.  NTP
>> on our fast x86 machine

Unruh> Youwill not get that from ntp. Mills has explicitely stated that he
Unruh> is completely uninterested in any questin of speed of convergence of
Unruh> ntp. For him the slow convergence is a feature, not a bug.

Assuming you have accurately relayed Dave's POV, Bill, I'd be open to seeing
if we can take Dave's policy choice and making it the default choice for a
config file knob (mechanism) that would allow folks to get faster
convergence.

I suspect that the only way this would fly is if the simulator (and Reality)
can show that the alternative choice is "stable".  And the scope of this
effort might be larger than (simulating) the behavior on a single machine -
it might require analysis on a network of machines.

-- 
Harlan Stenn <stenn@ntp.org>
http://ntpforum.isc.org  - be a member!

cnm3332@gmail.com writes:

>On Feb 20, 10:27=A0pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
>> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>> >Unruh wrote:
>> >> Then do not use ntp. Its behaviour is converging to the correct time i=
>s
>> >> very very slow. It is a completely inappropriate tool for the requirem=
>ent
>> >> that you have. chrony is much better.
>> >chrony is excluded because it doesn't support locally attached reference
>> >clocks.
>>
>> Agreed. I was so concentrated on the rate question I negected the fact th=
>at
>> he is running a PPS clock.
>> So at present he is stuck. Make sure you have no /etc/ntp/drift file. Use
>> -g, and use the iburst, etc to try to reduce the startup transientx.
>>
>>

>So, I will need to let NTP run for long time, to build correct drift
>file, which might
>help with accuracy and sync time?   So should this be my ntp conf file

It might. If linux configures itself properly. Recent kernels have trouble
with the tsc time interpolation, and get the wrong rate. This causes ntp to
take many hours on each bootup. That may not be a problem for you depending
on your system. Of course your system may have no interpolation at all in
which case you will have very bad time keeping.


>for
>doing this

>ntp.conf
>server 127.127.28.0 minpoll 4 maxpoll 4
>fudge 127.127.28.0 burst iburst refid NMEA
>server 127.127.28.1 minpoll 4 maxpoll 4 prefer
>fudge 127.127.28.1 burst iburst refid PPS

>Not sure I understand need for -g option though.
>I'm was looking at other computers to try, something
>small and low power, and found this neat little thing:
>http://www.axiomtek.com/Download/Spec/ebox530-820-fl.pdf

Harlan Stenn wrote:

> Assuming you have accurately relayed Dave's POV, Bill, I'd be open to seeing
> if we can take Dave's policy choice and making it the default choice for a
> config file knob (mechanism) that would allow folks to get faster
> convergence.
> 
> I suspect that the only way this would fly is if the simulator (and Reality)
> can show that the alternative choice is "stable".  And the scope of this
> effort might be larger than (simulating) the behavior on a single machine -
> it might require analysis on a network of machines.
> 

Oh, please let's do this. I have many customers that are willing to 
put a good deal of money into their infrastructure to guarantee 
network connectivity, low latency, and anything else it takes to get 
highly accurate time sync. But after all of that, they have to fight 
the NTP implementation.

blu

Harlan Stenn writes:
> mlockall() and sched_setscheduler() should be discovered automatically by
> the 'configure' step.  I think mlockall() is the default on many OSes
> that provide it, and the -N option probably controls the priority
> setting.

mlockall() seems to be disabled under Linux in 4.2.4:

ChangeSet@1.1251, 2004-11-03 01:51:42-05:00, stenn@pogo.udel.edu +1 -0
  Disable mlockall() under linux for now - resolver problems.

-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

>>> In article <87bpsrtan7.fsf@thumper.dhh.gt.org>, John Hasler <john@dhh.gt.org> writes:

John> Harlan Stenn writes:
>> mlockall() and sched_setscheduler() should be discovered automatically by
>> the 'configure' step.  I think mlockall() is the default on many OSes
>> that provide it, and the -N option probably controls the priority
>> setting.

John> mlockall() seems to be disabled under Linux in 4.2.4:

John> ChangeSet@1.1251, 2004-11-03 01:51:42-05:00, stenn@pogo.udel.edu +1 -0
John> Disable mlockall() under linux for now - resolver problems.

I remember - libc (or whatever) under linux allocates a HUGE amount of space
and that means the forked resolver process cannot get enough memory to work.

Or something like that.

-- 
Harlan Stenn <stenn@ntp.org>
http://ntpforum.isc.org  - be a member!

Harlan Stenn writes:
> I remember - libc (or whatever) under linux allocates a HUGE amount of
> space and that means the forked resolver process cannot get enough memory
> to work.

That bug shouldn't bite the OP, though.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA