QNX and NTP

bridged with qdn.public.qnxrtp.applications
Post Reply
David Kuechenmeister

QNX and NTP

Post by David Kuechenmeister » Thu Nov 07, 2002 8:02 pm

I'm trying to get NTP running on a QNX 6 platform. The sticking point is how
to adjust the clock incrementally after an initial slew. It seems that most
platforms have an adjtime function that takes a struct timeval for the
number of usec to adjust. QNX has the ClockAdjust function that would appear
to do the same thing, except it's different. Instead of a struct timeval,
QSSL has invented a struct _clockadjust that contains the amount of time per
tick and the number of ticks to adjust the clock.

It looks like the upper limit on adjustments is 500 usec. Does anyone have
an estimate for the number of ticks over which that correction should be
applied? It would be nice to base it on the unix adjtime function, but I
don't know that much about how the adjtime function works on that platform.

Thanks,
David Kuechenmeister

David Gibbs

Re: QNX and NTP

Post by David Gibbs » Fri Nov 08, 2002 8:37 pm

David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
I'm trying to get NTP running on a QNX 6 platform. The sticking point is how
to adjust the clock incrementally after an initial slew. It seems that most
platforms have an adjtime function that takes a struct timeval for the
number of usec to adjust. QNX has the ClockAdjust function that would appear
to do the same thing, except it's different. Instead of a struct timeval,
QSSL has invented a struct _clockadjust that contains the amount of time per
tick and the number of ticks to adjust the clock.

It looks like the upper limit on adjustments is 500 usec. Does anyone have
an estimate for the number of ticks over which that correction should be
applied? It would be nice to base it on the unix adjtime function, but I
don't know that much about how the adjtime function works on that platform.
Get the current ticksize...don't apply a correction of more than 10% of
ticksize per tick...in fact...1% of ticksize per tick is probably better.

per_tick_mod = ticksize/100;
Number of ticks to apply = total correcton / per_tick_mod;

num_ticks = 100*total_correct/ticksize;

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Kuechenmeister

Re: QNX and NTP

Post by David Kuechenmeister » Tue Nov 12, 2002 2:41 pm

Thanks!
drk

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:aqh79n$f54$1@nntp.qnx.com...
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
I'm trying to get NTP running on a QNX 6 platform. The sticking point is
how
to adjust the clock incrementally after an initial slew. It seems that
most
platforms have an adjtime function that takes a struct timeval for the
number of usec to adjust. QNX has the ClockAdjust function that would
appear
to do the same thing, except it's different. Instead of a struct
timeval,
QSSL has invented a struct _clockadjust that contains the amount of time
per
tick and the number of ticks to adjust the clock.

It looks like the upper limit on adjustments is 500 usec. Does anyone
have
an estimate for the number of ticks over which that correction should be
applied? It would be nice to base it on the unix adjtime function, but I
don't know that much about how the adjtime function works on that
platform.

Get the current ticksize...don't apply a correction of more than 10% of
ticksize per tick...in fact...1% of ticksize per tick is probably better.

per_tick_mod = ticksize/100;
Number of ticks to apply = total correcton / per_tick_mod;

num_ticks = 100*total_correct/ticksize;

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Post Reply

Return to “qdn.public.qnxrtp.applications”