Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/time() drifting more than expected/List of Posts
Forum Topic - time() drifting more than expected: (23 Items)
   
Update
Robert D'Attilio(deleted)
06/08/2009 10:47 AM
post31090
time() drifting more than expected   
Hi:

I notice that the time reported by time() drifts by about 8 seconds on the hour. The hardware is a PPC405 processor 
running QNX 6.3.2 and there is no RTC.
 
Questions:
1) Is this a normal amount of drift? Seems kind of high to me.
2) What drives the 'ticking' of this OS clock? I'm assuming it's tied to some periodic interrupt from a hardware timer.
3) Anyone have some suggestions (algorithms) for reducing the amount of this drift locally? NOTE: I cannot use NTP to 
synchronize the clock. Instead we have another 'controller' card (with an RTC) that sets the time at bootup and then 
resyncs the time every hour. I could increase the frequency of these updates but was wondering if there was something I 
could do locally.

thanks
robert
Mario Charest
06/08/2009 10:55 AM
post31097
RE: time() drifting more than expected   
Could it be that the time between the timer interrupt ( I'm assuming that is what keeping the system time on PPC), is 
not exactly what the system think it is?  For example it's support to be trigger at every 1ms, but instead it's every .
998 ms.

> -----Original Message-----
> From: Robert D'Attilio [mailto:community-noreply@qnx.com]
> Sent: June-08-09 10:48 AM
> To: ostech-core_os
> Subject: time() drifting more than expected
> 
> Hi:
> 
> I notice that the time reported by time() drifts by about 8 seconds on
> the hour. The hardware is a PPC405 processor running QNX 6.3.2 and
> there is no RTC.
> 
> Questions:
> 1) Is this a normal amount of drift? Seems kind of high to me.
> 2) What drives the 'ticking' of this OS clock? I'm assuming it's tied
> to some periodic interrupt from a hardware timer.
> 3) Anyone have some suggestions (algorithms) for reducing the amount of
> this drift locally? NOTE: I cannot use NTP to synchronize the clock.
> Instead we have another 'controller' card (with an RTC) that sets the
> time at bootup and then resyncs the time every hour. I could increase
> the frequency of these updates but was wondering if there was something
> I could do locally.
> 
> thanks
> robert
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post31090
>
Will Miles
06/08/2009 11:18 AM
post31101
Re: time() drifting more than expected   
Hi Robert.

1) I'd say that's more drift than you should expect.

2) That's correct - the OS clock is maintained by adding a number of ns based each time a periodic tick interrupt 
arrives.  Most of the interesting parameters live on the system page in the qtime section - take a poke at http://www.
qnx.com/developers/docs/6.4.1/neutrino/building/startup.html#qtime for more details.  With regards to your drift problem
, chances are either (A) some ISR is taking more than a full tick to complete on a regular basis, causing hardware clock
 ticks to get lost; or (B) the kernel clock parameters are not set correctly for your board.

In the case of (A) a kernel event trace might be informative - since it uses the CPU cycle counter as its timebase 
instead of the clock tick, it's handy for diagnosing this kind of thing.

3) All other things being equal I'd suggest writing a "reference clock" driver for your board to plug in to NTP. ;)  It 
might be a little more complicated to get started - I found the documentation rather lacking - but it leverages all the 
experience that's gone in to the NTP clock disciplining algorithm.  Unfortunately, correcting for clock frequency error 
is not easy to do in QNX; you can either (a) have a thread that keeps periodically calling ClockAdjust() to maintain the
 drift correction, or (b) remap the system page RW and scribble new values directly into kernel memory.  As far clock 
discipline algorithms go, though, if you really want to code it yourself a simple PI controller is probably good enough 
- though some despiking to eliminate outliers can be helpful if your clock source can occasionally have variable 
latencies.

-Will
Lichun Zhu
06/08/2009 3:53 PM
post31159
Re: time() drifting more than expected   
8 seconds is defninitely too much. 
If it's case case B, it might be able to check the startup to see how to set this, what BSP is this?
Robert D'Attilio(deleted)
06/10/2009 10:51 AM
post31350
RE: time() drifting more than expected   
Will:

Thanks for the information. I dumped the qtime settings once the card
was running and saw the following:
cycles_per_sec: 200,000,000
nsec_inc: 1,000,000
timer_rate: 5
timer_scale: -9
adjust.tick_nsec_inc: 0
adjust.tick_count: 0

So it appears to be configured correctly with interrupts occurring every
1 ms and adding 1,000,000 nsec to the time counter every interrupt.

So I started up the profiler and grabbed a 3 second profile. I see that
the time between interrupts (time between successive "Entry" events)
varies anywhere between 1005 - 1019 microseconds. I would roughly
calculated an average of 1010 ms between the timer interrupts. Even with
the CPU idle i.e. no other competing threads/processes running between
successive timer interrupts, interrupts still are occurring every 1005
microseconds apart. Working backwards from an observed drift of 8
seconds/hour should give 2 microseconds/millisecond drift. So I'm a bit
puzzled by the larger values I'm measuring - on further thought I'm
wondering if the extra 3 to 13 microseconds are due to the overhead of
the instrumented kernel and the profiling?

I might try now to use ClockAdjust() to apply a 2 microsecond offset on
every interrupt (tick) to see if that will help.

A couple of points though:

1) I didn't see any events labeled the equivalent of "IntLock() or
IntUnlock()" in the trace log. What are the QNX equivalents and does
anyone know if they can be logged by the profiler?

thanks




-----Original Message-----
From: Will Miles [mailto:community-noreply@qnx.com] 
Sent: Monday, June 08, 2009 11:19 AM
To: ostech-core_os
Subject: Re: time() drifting more than expected

Hi Robert.

1) I'd say that's more drift than you should expect.

2) That's correct - the OS clock is maintained by adding a number of ns
based each time a periodic tick interrupt arrives.  Most of the
interesting parameters live on the system page in the qtime section -
take a poke at
http://www.qnx.com/developers/docs/6.4.1/neutrino/building/startup.html#
qtime for more details.  With regards to your drift problem, chances are
either (A) some ISR is taking more than a full tick to complete on a
regular basis, causing hardware clock ticks to get lost; or (B) the
kernel clock parameters are not set correctly for your board.

In the case of (A) a kernel event trace might be informative - since it
uses the CPU cycle counter as its timebase instead of the clock tick,
it's handy for diagnosing this kind of thing.

3) All other things being equal I'd suggest writing a "reference clock"
driver for your board to plug in to NTP. ;)  It might be a little more
complicated to get started - I found the documentation rather lacking -
but it leverages all the experience that's gone in to the NTP clock
disciplining algorithm.  Unfortunately, correcting for clock frequency
error is not easy to do in QNX; you can either (a) have a thread that
keeps periodically calling ClockAdjust() to maintain the drift
correction, or (b) remap the system page RW and scribble new values
directly into kernel memory.  As far clock discipline algorithms go,
though, if you really want to code it yourself a simple PI controller is
probably good enough - though some despiking to eliminate outliers can
be helpful if your clock source can occasionally have variable
latencies.

-Will

_______________________________________________
OSTech
http://community.qnx.com/sf/go/post31101
Neil Schellenberger(deleted)
06/10/2009 11:08 AM
post31354
RE: time() drifting more than expected   
I don't know if it helps any, but it used to be the case that there
could be a lot of variation in individual crystal oscillators (at one
time +/- 5 percent wasn't unusual).  Is the magnitude of the problem the
same on all boards of this type?  Or is this particular piece of
hardware an outlier?

On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> Will:
> 
> Thanks for the information. I dumped the qtime settings once the card
> was running and saw the following:
> cycles_per_sec: 200,000,000
> nsec_inc: 1,000,000
> timer_rate: 5
> timer_scale: -9
> adjust.tick_nsec_inc: 0
> adjust.tick_count: 0
> 
> So it appears to be configured correctly with interrupts occurring every
> 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
> 
> So I started up the profiler and grabbed a 3 second profile. I see that
> the time between interrupts (time between successive "Entry" events)
> varies anywhere between 1005 - 1019 microseconds. I would roughly
> calculated an average of 1010 ms between the timer interrupts. Even with
> the CPU idle i.e. no other competing threads/processes running between
> successive timer interrupts, interrupts still are occurring every 1005
> microseconds apart. Working backwards from an observed drift of 8
> seconds/hour should give 2 microseconds/millisecond drift. So I'm a bit
> puzzled by the larger values I'm measuring - on further thought I'm
> wondering if the extra 3 to 13 microseconds are due to the overhead of
> the instrumented kernel and the profiling?
> 
> I might try now to use ClockAdjust() to apply a 2 microsecond offset on
> every interrupt (tick) to see if that will help.
> 
> A couple of points though:
> 
> 1) I didn't see any events labeled the equivalent of "IntLock() or
> IntUnlock()" in the trace log. What are the QNX equivalents and does
> anyone know if they can be logged by the profiler?
> 
> thanks
> 
> 
> 
> 
> -----Original Message-----
> From: Will Miles [mailto:community-noreply@qnx.com] 
> Sent: Monday, June 08, 2009 11:19 AM
> To: ostech-core_os
> Subject: Re: time() drifting more than expected
> 
> Hi Robert.
> 
> 1) I'd say that's more drift than you should expect.
> 
> 2) That's correct - the OS clock is maintained by adding a number of ns
> based each time a periodic tick interrupt arrives.  Most of the
> interesting parameters live on the system page in the qtime section -
> take a poke at
> http://www.qnx.com/developers/docs/6.4.1/neutrino/building/startup.html#
> qtime for more details.  With regards to your drift problem, chances are
> either (A) some ISR is taking more than a full tick to complete on a
> regular basis, causing hardware clock ticks to get lost; or (B) the
> kernel clock parameters are not set correctly for your board.
> 
> In the case of (A) a kernel event trace might be informative - since it
> uses the CPU cycle counter as its timebase instead of the clock tick,
> it's handy for diagnosing this kind of thing.
> 
> 3) All other things being equal I'd suggest writing a "reference clock"
> driver for your board to plug in to NTP. ;)  It might be a little more
> complicated to get started - I found the documentation rather lacking -
> but it leverages all the experience that's gone in to the NTP clock
> disciplining algorithm.  Unfortunately, correcting for clock frequency
> error is not easy to do in QNX; you can either (a) have a thread that
> keeps periodically calling ClockAdjust() to maintain the drift
> correction, or (b) remap the system page RW and scribble new values
> directly into kernel memory.  As far clock discipline algorithms go,
> though, if you really want to code it yourself a simple PI controller is
> probably good...
View Full Message
Robert D'Attilio(deleted)
06/10/2009 11:21 AM
post31359
RE: time() drifting more than expected   
So far I've only been able to profile two boards and they both show the
same drift. The crystals we use are rated at 100 ppm which works out to
8 seconds a day. I'm seeing a drift about 24 X larger than that.

-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
Sent: Wednesday, June 10, 2009 11:08 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

I don't know if it helps any, but it used to be the case that there
could be a lot of variation in individual crystal oscillators (at one
time +/- 5 percent wasn't unusual).  Is the magnitude of the problem the
same on all boards of this type?  Or is this particular piece of
hardware an outlier?

On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> Will:
> 
> Thanks for the information. I dumped the qtime settings once the card
> was running and saw the following:
> cycles_per_sec: 200,000,000
> nsec_inc: 1,000,000
> timer_rate: 5
> timer_scale: -9
> adjust.tick_nsec_inc: 0
> adjust.tick_count: 0
> 
> So it appears to be configured correctly with interrupts occurring
every
> 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
> 
> So I started up the profiler and grabbed a 3 second profile. I see
that
> the time between interrupts (time between successive "Entry" events)
> varies anywhere between 1005 - 1019 microseconds. I would roughly
> calculated an average of 1010 ms between the timer interrupts. Even
with
> the CPU idle i.e. no other competing threads/processes running between
> successive timer interrupts, interrupts still are occurring every 1005
> microseconds apart. Working backwards from an observed drift of 8
> seconds/hour should give 2 microseconds/millisecond drift. So I'm a
bit
> puzzled by the larger values I'm measuring - on further thought I'm
> wondering if the extra 3 to 13 microseconds are due to the overhead of
> the instrumented kernel and the profiling?
> 
> I might try now to use ClockAdjust() to apply a 2 microsecond offset
on
> every interrupt (tick) to see if that will help.
> 
> A couple of points though:
> 
> 1) I didn't see any events labeled the equivalent of "IntLock() or
> IntUnlock()" in the trace log. What are the QNX equivalents and does
> anyone know if they can be logged by the profiler?
> 
> thanks
> 
> 
> 
> 
> -----Original Message-----
> From: Will Miles [mailto:community-noreply@qnx.com] 
> Sent: Monday, June 08, 2009 11:19 AM
> To: ostech-core_os
> Subject: Re: time() drifting more than expected
> 
> Hi Robert.
> 
> 1) I'd say that's more drift than you should expect.
> 
> 2) That's correct - the OS clock is maintained by adding a number of
ns
> based each time a periodic tick interrupt arrives.  Most of the
> interesting parameters live on the system page in the qtime section -
> take a poke at
>
http://www.qnx.com/developers/docs/6.4.1/neutrino/building/startup.html#
> qtime for more details.  With regards to your drift problem, chances
are
> either (A) some ISR is taking more than a full tick to complete on a
> regular basis, causing hardware clock ticks to get lost; or (B) the
> kernel clock parameters are not set correctly for your board.
> 
> In the case of (A) a kernel event trace might be informative - since
it
> uses the CPU cycle counter as its timebase instead of the clock tick,
> it's handy for diagnosing this kind of thing.
> 
> 3) All other things being equal I'd suggest writing a "reference
clock"
> driver for your board to plug in to NTP. ;)  It might be a little more
> complicated to get started - I found the documentation rather lacking
-
> but it leverages all the experience that's gone in to the NTP clock
> disciplining algorithm. ...
View Full Message
Neil Schellenberger(deleted)
06/10/2009 11:24 AM
post31362
RE: time() drifting more than expected   
Oh well, another long shot shot to heck.... ;-)

On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> So far I've only been able to profile two boards and they both show the
> same drift. The crystals we use are rated at 100 ppm which works out to
> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:08 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> I don't know if it helps any, but it used to be the case that there
> could be a lot of variation in individual crystal oscillators (at one
> time +/- 5 percent wasn't unusual).  Is the magnitude of the problem the
> same on all boards of this type?  Or is this particular piece of
> hardware an outlier?
> 
> On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > Will:
> > 
> > Thanks for the information. I dumped the qtime settings once the card
> > was running and saw the following:
> > cycles_per_sec: 200,000,000
> > nsec_inc: 1,000,000
> > timer_rate: 5
> > timer_scale: -9
> > adjust.tick_nsec_inc: 0
> > adjust.tick_count: 0
> > 
> > So it appears to be configured correctly with interrupts occurring
> every
> > 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
> > 
> > So I started up the profiler and grabbed a 3 second profile. I see
> that
> > the time between interrupts (time between successive "Entry" events)
> > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > calculated an average of 1010 ms between the timer interrupts. Even
> with
> > the CPU idle i.e. no other competing threads/processes running between
> > successive timer interrupts, interrupts still are occurring every 1005
> > microseconds apart. Working backwards from an observed drift of 8
> > seconds/hour should give 2 microseconds/millisecond drift. So I'm a
> bit
> > puzzled by the larger values I'm measuring - on further thought I'm
> > wondering if the extra 3 to 13 microseconds are due to the overhead of
> > the instrumented kernel and the profiling?
> > 
> > I might try now to use ClockAdjust() to apply a 2 microsecond offset
> on
> > every interrupt (tick) to see if that will help.
> > 
> > A couple of points though:
> > 
> > 1) I didn't see any events labeled the equivalent of "IntLock() or
> > IntUnlock()" in the trace log. What are the QNX equivalents and does
> > anyone know if they can be logged by the profiler?
> > 
> > thanks
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Will Miles [mailto:community-noreply@qnx.com] 
> > Sent: Monday, June 08, 2009 11:19 AM
> > To: ostech-core_os
> > Subject: Re: time() drifting more than expected
> > 
> > Hi Robert.
> > 
> > 1) I'd say that's more drift than you should expect.
> > 
> > 2) That's correct - the OS clock is maintained by adding a number of
> ns
> > based each time a periodic tick interrupt arrives.  Most of the
> > interesting parameters live on the system page in the qtime section -
> > take a poke at
> >
> http://www.qnx.com/developers/docs/6.4.1/neutrino/building/startup.html#
> > qtime for more details.  With regards to your drift problem, chances
> are
> > either (A) some ISR is taking more than a full tick to complete on a
> > regular basis, causing hardware clock ticks to get lost; or (B) the
> > kernel clock parameters are not set correctly for your board.
> > 
> > In the case of...
View Full Message
Robert D'Attilio(deleted)
06/10/2009 11:34 AM
post31368
RE: time() drifting more than expected   
Neil, any idea what the published latency is on servicing interrupts in
QNX? Does 2 microseconds sound about right?

-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
Sent: Wednesday, June 10, 2009 11:24 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Oh well, another long shot shot to heck.... ;-)

On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> So far I've only been able to profile two boards and they both show
the
> same drift. The crystals we use are rated at 100 ppm which works out
to
> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:08 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> I don't know if it helps any, but it used to be the case that there
> could be a lot of variation in individual crystal oscillators (at one
> time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
the
> same on all boards of this type?  Or is this particular piece of
> hardware an outlier?
> 
> On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > Will:
> > 
> > Thanks for the information. I dumped the qtime settings once the
card
> > was running and saw the following:
> > cycles_per_sec: 200,000,000
> > nsec_inc: 1,000,000
> > timer_rate: 5
> > timer_scale: -9
> > adjust.tick_nsec_inc: 0
> > adjust.tick_count: 0
> > 
> > So it appears to be configured correctly with interrupts occurring
> every
> > 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
> > 
> > So I started up the profiler and grabbed a 3 second profile. I see
> that
> > the time between interrupts (time between successive "Entry" events)
> > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > calculated an average of 1010 ms between the timer interrupts. Even
> with
> > the CPU idle i.e. no other competing threads/processes running
between
> > successive timer interrupts, interrupts still are occurring every
1005
> > microseconds apart. Working backwards from an observed drift of 8
> > seconds/hour should give 2 microseconds/millisecond drift. So I'm a
> bit
> > puzzled by the larger values I'm measuring - on further thought I'm
> > wondering if the extra 3 to 13 microseconds are due to the overhead
of
> > the instrumented kernel and the profiling?
> > 
> > I might try now to use ClockAdjust() to apply a 2 microsecond offset
> on
> > every interrupt (tick) to see if that will help.
> > 
> > A couple of points though:
> > 
> > 1) I didn't see any events labeled the equivalent of "IntLock() or
> > IntUnlock()" in the trace log. What are the QNX equivalents and does
> > anyone know if they can be logged by the profiler?
> > 
> > thanks
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Will Miles [mailto:community-noreply@qnx.com] 
> > Sent: Monday, June 08, 2009 11:19 AM
> > To: ostech-core_os
> > Subject: Re: time() drifting more than expected
> > 
> > Hi Robert.
> > 
> > 1) I'd say that's more drift than you should expect.
> > 
> > 2) That's correct - the OS clock is maintained by adding a number of
> ns
> > based each time a periodic tick interrupt arrives.  Most of the
> > interesting parameters live on the system page in the qtime section
-
> > take a poke at
> >
>
http://www.qnx.com/developers/docs/6.4.1/neutrino/building/startup.html#
> > qtime for more...
View Full Message
Neil Schellenberger(deleted)
06/11/2009 10:28 AM
post31492
RE: time() drifting more than expected   
Hi Robert,

Sorry for the delay on this: I've been trying to find a definitive
answer for you.  So far the best I've come up with is that we don't have
any "official" published latency numbers.  The variation between
different boards makes that a bit tricky.

When you ask specifically about 2us, do you mean the interval between
interrupt service start and EOI?  Or do you have in mind time between
interrupt raise and service start?  Or something else?

Regards,
Neil

On Wed, 2009-06-10 at 11:34 -0400, Robert D'Attilio wrote:
> Neil, any idea what the published latency is on servicing interrupts in
> QNX? Does 2 microseconds sound about right?
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:24 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> Oh well, another long shot shot to heck.... ;-)
> 
> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> > So far I've only been able to profile two boards and they both show
> the
> > same drift. The crystals we use are rated at 100 ppm which works out
> to
> > 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> > 
> > -----Original Message-----
> > From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> > Sent: Wednesday, June 10, 2009 11:08 AM
> > To: ostech-core_os
> > Subject: RE: time() drifting more than expected
> > 
> > I don't know if it helps any, but it used to be the case that there
> > could be a lot of variation in individual crystal oscillators (at one
> > time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
> the
> > same on all boards of this type?  Or is this particular piece of
> > hardware an outlier?
> > 
> > On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > > Will:
> > > 
> > > Thanks for the information. I dumped the qtime settings once the
> card
> > > was running and saw the following:
> > > cycles_per_sec: 200,000,000
> > > nsec_inc: 1,000,000
> > > timer_rate: 5
> > > timer_scale: -9
> > > adjust.tick_nsec_inc: 0
> > > adjust.tick_count: 0
> > > 
> > > So it appears to be configured correctly with interrupts occurring
> > every
> > > 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
> > > 
> > > So I started up the profiler and grabbed a 3 second profile. I see
> > that
> > > the time between interrupts (time between successive "Entry" events)
> > > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > > calculated an average of 1010 ms between the timer interrupts. Even
> > with
> > > the CPU idle i.e. no other competing threads/processes running
> between
> > > successive timer interrupts, interrupts still are occurring every
> 1005
> > > microseconds apart. Working backwards from an observed drift of 8
> > > seconds/hour should give 2 microseconds/millisecond drift. So I'm a
> > bit
> > > puzzled by the larger values I'm measuring - on further thought I'm
> > > wondering if the extra 3 to 13 microseconds are due to the overhead
> of
> > > the instrumented kernel and the profiling?
> > > 
> > > I might try now to use ClockAdjust() to apply a 2 microsecond offset
> > on
> > > every interrupt (tick) to see if that will help.
> > > 
> > > A couple of points though:
> > > 
> > > 1) I didn't see any events labeled the equivalent of "IntLock() or
> > > IntUnlock()" in the trace log. What are the QNX...
View Full Message
Robert D'Attilio(deleted)
06/11/2009 11:40 AM
post31498
RE: time() drifting more than expected   
Neil no worries.

I'm looking at the time between interrupt raised by the device and the
time OS recoginizes and starts to service it. 

Don't kill yourself trying to find it or worse measure it :)

robert

-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
Sent: Thursday, June 11, 2009 10:28 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Hi Robert,

Sorry for the delay on this: I've been trying to find a definitive
answer for you.  So far the best I've come up with is that we don't have
any "official" published latency numbers.  The variation between
different boards makes that a bit tricky.

When you ask specifically about 2us, do you mean the interval between
interrupt service start and EOI?  Or do you have in mind time between
interrupt raise and service start?  Or something else?

Regards,
Neil

On Wed, 2009-06-10 at 11:34 -0400, Robert D'Attilio wrote:
> Neil, any idea what the published latency is on servicing interrupts
in
> QNX? Does 2 microseconds sound about right?
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:24 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> Oh well, another long shot shot to heck.... ;-)
> 
> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> > So far I've only been able to profile two boards and they both show
> the
> > same drift. The crystals we use are rated at 100 ppm which works out
> to
> > 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> > 
> > -----Original Message-----
> > From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> > Sent: Wednesday, June 10, 2009 11:08 AM
> > To: ostech-core_os
> > Subject: RE: time() drifting more than expected
> > 
> > I don't know if it helps any, but it used to be the case that there
> > could be a lot of variation in individual crystal oscillators (at
one
> > time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
> the
> > same on all boards of this type?  Or is this particular piece of
> > hardware an outlier?
> > 
> > On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > > Will:
> > > 
> > > Thanks for the information. I dumped the qtime settings once the
> card
> > > was running and saw the following:
> > > cycles_per_sec: 200,000,000
> > > nsec_inc: 1,000,000
> > > timer_rate: 5
> > > timer_scale: -9
> > > adjust.tick_nsec_inc: 0
> > > adjust.tick_count: 0
> > > 
> > > So it appears to be configured correctly with interrupts occurring
> > every
> > > 1 ms and adding 1,000,000 nsec to the time counter every
interrupt.
> > > 
> > > So I started up the profiler and grabbed a 3 second profile. I see
> > that
> > > the time between interrupts (time between successive "Entry"
events)
> > > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > > calculated an average of 1010 ms between the timer interrupts.
Even
> > with
> > > the CPU idle i.e. no other competing threads/processes running
> between
> > > successive timer interrupts, interrupts still are occurring every
> 1005
> > > microseconds apart. Working backwards from an observed drift of 8
> > > seconds/hour should give 2 microseconds/millisecond drift. So I'm
a
> > bit
> > > puzzled by the larger values I'm measuring - on further thought
I'm
> > > wondering if the extra 3 to 13 microseconds are due to the
overhead
> of
> > > the instrumented...
View Full Message
Mario Charest
06/11/2009 11:42 AM
post31500
RE: time() drifting more than expected   
If the latency is stable time wise it shouldn`t be an issue. I mean the latency could be half a ms and it should not 
affect the precision of time.
 
-----Original Message-----
From: Robert D'Attilio [mailto:community-noreply@qnx.com] 
Sent: June 11, 2009 11:41 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Neil no worries.

I'm looking at the time between interrupt raised by the device and the
time OS recoginizes and starts to service it. 

Don't kill yourself trying to find it or worse measure it :)

robert

-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
Sent: Thursday, June 11, 2009 10:28 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Hi Robert,

Sorry for the delay on this: I've been trying to find a definitive
answer for you.  So far the best I've come up with is that we don't have
any "official" published latency numbers.  The variation between
different boards makes that a bit tricky.

When you ask specifically about 2us, do you mean the interval between
interrupt service start and EOI?  Or do you have in mind time between
interrupt raise and service start?  Or something else?

Regards,
Neil

On Wed, 2009-06-10 at 11:34 -0400, Robert D'Attilio wrote:
> Neil, any idea what the published latency is on servicing interrupts
in
> QNX? Does 2 microseconds sound about right?
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:24 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> Oh well, another long shot shot to heck.... ;-)
> 
> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> > So far I've only been able to profile two boards and they both show
> the
> > same drift. The crystals we use are rated at 100 ppm which works out
> to
> > 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> > 
> > -----Original Message-----
> > From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> > Sent: Wednesday, June 10, 2009 11:08 AM
> > To: ostech-core_os
> > Subject: RE: time() drifting more than expected
> > 
> > I don't know if it helps any, but it used to be the case that there
> > could be a lot of variation in individual crystal oscillators (at
one
> > time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
> the
> > same on all boards of this type?  Or is this particular piece of
> > hardware an outlier?
> > 
> > On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > > Will:
> > > 
> > > Thanks for the information. I dumped the qtime settings once the
> card
> > > was running and saw the following:
> > > cycles_per_sec: 200,000,000
> > > nsec_inc: 1,000,000
> > > timer_rate: 5
> > > timer_scale: -9
> > > adjust.tick_nsec_inc: 0
> > > adjust.tick_count: 0
> > > 
> > > So it appears to be configured correctly with interrupts occurring
> > every
> > > 1 ms and adding 1,000,000 nsec to the time counter every
interrupt.
> > > 
> > > So I started up the profiler and grabbed a 3 second profile. I see
> > that
> > > the time between interrupts (time between successive "Entry"
events)
> > > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > > calculated an average of 1010 ms between the timer interrupts.
Even
> > with
> > > the CPU idle i.e. no other competing threads/processes running
> between
> > > successive timer interrupts, interrupts still are occurring every
> 1005
> > > microseconds apart. Working backwards from...
View Full Message
Robert D'Attilio(deleted)
06/11/2009 1:03 PM
post31518
RE: time() drifting more than expected   
You're right now that I think about it...thanks

-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com] 
Sent: Thursday, June 11, 2009 11:43 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

If the latency is stable time wise it shouldn`t be an issue. I mean the
latency could be half a ms and it should not affect the precision of
time.
 
-----Original Message-----
From: Robert D'Attilio [mailto:community-noreply@qnx.com] 
Sent: June 11, 2009 11:41 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Neil no worries.

I'm looking at the time between interrupt raised by the device and the
time OS recoginizes and starts to service it. 

Don't kill yourself trying to find it or worse measure it :)

robert

-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
Sent: Thursday, June 11, 2009 10:28 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Hi Robert,

Sorry for the delay on this: I've been trying to find a definitive
answer for you.  So far the best I've come up with is that we don't have
any "official" published latency numbers.  The variation between
different boards makes that a bit tricky.

When you ask specifically about 2us, do you mean the interval between
interrupt service start and EOI?  Or do you have in mind time between
interrupt raise and service start?  Or something else?

Regards,
Neil

On Wed, 2009-06-10 at 11:34 -0400, Robert D'Attilio wrote:
> Neil, any idea what the published latency is on servicing interrupts
in
> QNX? Does 2 microseconds sound about right?
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:24 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> Oh well, another long shot shot to heck.... ;-)
> 
> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> > So far I've only been able to profile two boards and they both show
> the
> > same drift. The crystals we use are rated at 100 ppm which works out
> to
> > 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> > 
> > -----Original Message-----
> > From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> > Sent: Wednesday, June 10, 2009 11:08 AM
> > To: ostech-core_os
> > Subject: RE: time() drifting more than expected
> > 
> > I don't know if it helps any, but it used to be the case that there
> > could be a lot of variation in individual crystal oscillators (at
one
> > time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
> the
> > same on all boards of this type?  Or is this particular piece of
> > hardware an outlier?
> > 
> > On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > > Will:
> > > 
> > > Thanks for the information. I dumped the qtime settings once the
> card
> > > was running and saw the following:
> > > cycles_per_sec: 200,000,000
> > > nsec_inc: 1,000,000
> > > timer_rate: 5
> > > timer_scale: -9
> > > adjust.tick_nsec_inc: 0
> > > adjust.tick_count: 0
> > > 
> > > So it appears to be configured correctly with interrupts occurring
> > every
> > > 1 ms and adding 1,000,000 nsec to the time counter every
interrupt.
> > > 
> > > So I started up the profiler and grabbed a 3 second profile. I see
> > that
> > > the time between interrupts (time between successive "Entry"
events)
> > > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > > calculated an average of 1010 ms between the timer interrupts.
Even
> >...
View Full Message
Robert D'Attilio(deleted)
06/10/2009 4:41 PM
post31431
RE: time() drifting more than expected   
Can't seem to get ClockAdjust() to adjust the time!
Here is how I am calling it:
    
    struct _clockadjust adjustment;
    adjustment.tick_nsec_inc = 2000;
    adjustment.tick_count = 0;

    ClockAdjust( CLOCK_REALTIME, &adjustment, NULL);

My understanding is that setting tick_count=0 will apply the
(tick_nsec_inc) offset on every tick. Is my interpretation correct? 

I would also like to try the alternative of modifying the nsec_inc qtime
entry directly. There is some mention of getting the physical address of
the qtime sys entry and then using mmap to remap it r/w. Would someone
have a code snippet of this as I'm not 100% sure how to do it.

Thanks again
Robert

-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
Sent: Wednesday, June 10, 2009 11:24 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

Oh well, another long shot shot to heck.... ;-)

On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
> So far I've only been able to profile two boards and they both show
the
> same drift. The crystals we use are rated at 100 ppm which works out
to
> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:08 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> I don't know if it helps any, but it used to be the case that there
> could be a lot of variation in individual crystal oscillators (at one
> time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
the
> same on all boards of this type?  Or is this particular piece of
> hardware an outlier?
> 
> On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
> > Will:
> > 
> > Thanks for the information. I dumped the qtime settings once the
card
> > was running and saw the following:
> > cycles_per_sec: 200,000,000
> > nsec_inc: 1,000,000
> > timer_rate: 5
> > timer_scale: -9
> > adjust.tick_nsec_inc: 0
> > adjust.tick_count: 0
> > 
> > So it appears to be configured correctly with interrupts occurring
> every
> > 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
> > 
> > So I started up the profiler and grabbed a 3 second profile. I see
> that
> > the time between interrupts (time between successive "Entry" events)
> > varies anywhere between 1005 - 1019 microseconds. I would roughly
> > calculated an average of 1010 ms between the timer interrupts. Even
> with
> > the CPU idle i.e. no other competing threads/processes running
between
> > successive timer interrupts, interrupts still are occurring every
1005
> > microseconds apart. Working backwards from an observed drift of 8
> > seconds/hour should give 2 microseconds/millisecond drift. So I'm a
> bit
> > puzzled by the larger values I'm measuring - on further thought I'm
> > wondering if the extra 3 to 13 microseconds are due to the overhead
of
> > the instrumented kernel and the profiling?
> > 
> > I might try now to use ClockAdjust() to apply a 2 microsecond offset
> on
> > every interrupt (tick) to see if that will help.
> > 
> > A couple of points though:
> > 
> > 1) I didn't see any events labeled the equivalent of "IntLock() or
> > IntUnlock()" in the trace log. What are the QNX equivalents and does
> > anyone know if they can be logged by the profiler?
> > 
> > thanks
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Will Miles [mailto:community-noreply@qnx.com] 
> > Sent: Monday, June 08, 2009 11:19 AM
> > To:...
View Full Message
Colin Burgess(deleted)
06/10/2009 4:44 PM
post31432
Re: time() drifting more than expected   
Setting tick_count to zero will mean no changes are done...

Robert D'Attilio wrote:
> Can't seem to get ClockAdjust() to adjust the time!
> Here is how I am calling it:
>     
>     struct _clockadjust adjustment;
>     adjustment.tick_nsec_inc = 2000;
>     adjustment.tick_count = 0;
> 
>     ClockAdjust( CLOCK_REALTIME, &adjustment, NULL);
> 
> My understanding is that setting tick_count=0 will apply the
> (tick_nsec_inc) offset on every tick. Is my interpretation correct? 
> 
> I would also like to try the alternative of modifying the nsec_inc qtime
> entry directly. There is some mention of getting the physical address of
> the qtime sys entry and then using mmap to remap it r/w. Would someone
> have a code snippet of this as I'm not 100% sure how to do it.
> 
> Thanks again
> Robert
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:24 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> Oh well, another long shot shot to heck.... ;-)
> 
> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
>> So far I've only been able to profile two boards and they both show
> the
>> same drift. The crystals we use are rated at 100 ppm which works out
> to
>> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
>>
>> -----Original Message-----
>> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
>> Sent: Wednesday, June 10, 2009 11:08 AM
>> To: ostech-core_os
>> Subject: RE: time() drifting more than expected
>>
>> I don't know if it helps any, but it used to be the case that there
>> could be a lot of variation in individual crystal oscillators (at one
>> time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
> the
>> same on all boards of this type?  Or is this particular piece of
>> hardware an outlier?
>>
>> On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
>>> Will:
>>>
>>> Thanks for the information. I dumped the qtime settings once the
> card
>>> was running and saw the following:
>>> cycles_per_sec: 200,000,000
>>> nsec_inc: 1,000,000
>>> timer_rate: 5
>>> timer_scale: -9
>>> adjust.tick_nsec_inc: 0
>>> adjust.tick_count: 0
>>>
>>> So it appears to be configured correctly with interrupts occurring
>> every
>>> 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
>>>
>>> So I started up the profiler and grabbed a 3 second profile. I see
>> that
>>> the time between interrupts (time between successive "Entry" events)
>>> varies anywhere between 1005 - 1019 microseconds. I would roughly
>>> calculated an average of 1010 ms between the timer interrupts. Even
>> with
>>> the CPU idle i.e. no other competing threads/processes running
> between
>>> successive timer interrupts, interrupts still are occurring every
> 1005
>>> microseconds apart. Working backwards from an observed drift of 8
>>> seconds/hour should give 2 microseconds/millisecond drift. So I'm a
>> bit
>>> puzzled by the larger values I'm measuring - on further thought I'm
>>> wondering if the extra 3 to 13 microseconds are due to the overhead
> of
>>> the instrumented kernel and the profiling?
>>>
>>> I might try now to use ClockAdjust() to apply a 2 microsecond offset
>> on
>>> every interrupt (tick) to see if that will help.
>>>
>>> A couple of points though:
>>>
>>> 1) I didn't see any...
View Full Message
Robert D'Attilio(deleted)
06/10/2009 4:59 PM
post31436
RE: time() drifting more than expected   
Colin:

Quoting from the documentation
(http://www.qnx.co.il/developers/docs/6.3.0SP3/neutrino/building/startup
.html?printable=1) in the syspage_entry qtime section: 

...You could give ClockAdjust() a value of 0 for the number of ticks, to
indicate that you want to make this adjustment "permanent". If you don't
want to do that, you can give the ClockAdjust() function the maximum
possible value for tick_count...

I would interpret the first sentence to mean that adjustment will always
be applied. If that isn't correct then maybe the docs should get fixed
or at least some clarification added.





-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com] 
Sent: Wednesday, June 10, 2009 4:45 PM
To: ostech-core_os
Subject: Re: time() drifting more than expected

Setting tick_count to zero will mean no changes are done...

Robert D'Attilio wrote:
> Can't seem to get ClockAdjust() to adjust the time!
> Here is how I am calling it:
>     
>     struct _clockadjust adjustment;
>     adjustment.tick_nsec_inc = 2000;
>     adjustment.tick_count = 0;
> 
>     ClockAdjust( CLOCK_REALTIME, &adjustment, NULL);
> 
> My understanding is that setting tick_count=0 will apply the
> (tick_nsec_inc) offset on every tick. Is my interpretation correct? 
> 
> I would also like to try the alternative of modifying the nsec_inc
qtime
> entry directly. There is some mention of getting the physical address
of
> the qtime sys entry and then using mmap to remap it r/w. Would someone
> have a code snippet of this as I'm not 100% sure how to do it.
> 
> Thanks again
> Robert
> 
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 11:24 AM
> To: ostech-core_os
> Subject: RE: time() drifting more than expected
> 
> Oh well, another long shot shot to heck.... ;-)
> 
> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
>> So far I've only been able to profile two boards and they both show
> the
>> same drift. The crystals we use are rated at 100 ppm which works out
> to
>> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
>>
>> -----Original Message-----
>> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
>> Sent: Wednesday, June 10, 2009 11:08 AM
>> To: ostech-core_os
>> Subject: RE: time() drifting more than expected
>>
>> I don't know if it helps any, but it used to be the case that there
>> could be a lot of variation in individual crystal oscillators (at one
>> time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
> the
>> same on all boards of this type?  Or is this particular piece of
>> hardware an outlier?
>>
>> On Wed, 2009-06-10 at 10:51 -0400, Robert D'Attilio wrote:
>>> Will:
>>>
>>> Thanks for the information. I dumped the qtime settings once the
> card
>>> was running and saw the following:
>>> cycles_per_sec: 200,000,000
>>> nsec_inc: 1,000,000
>>> timer_rate: 5
>>> timer_scale: -9
>>> adjust.tick_nsec_inc: 0
>>> adjust.tick_count: 0
>>>
>>> So it appears to be configured correctly with interrupts occurring
>> every
>>> 1 ms and adding 1,000,000 nsec to the time counter every interrupt.
>>>
>>> So I started up the profiler and grabbed a 3 second profile. I see
>> that
>>> the time between interrupts (time between successive "Entry" events)
>>> varies anywhere between 1005 - 1019 microseconds. I would roughly
>>> calculated an average of 1010 ms between the timer interrupts. Even
>> with
>>> the CPU idle i.e. no other...
View Full Message
Colin Burgess(deleted)
06/11/2009 9:27 AM
post31476
Re: time() drifting more than expected   
I think those docs are wrong - as per the ClockAdjust() manual page...

http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/c/clockadjust.html

"You can cancel any adjustment in progress by setting tick_count and tick_nsec_inc to 0."

and from the code (services/system/ker/nano_clock.c)

     if(qtp->adjust.tick_count) {
         // Adjust the clock
         qtp->nsec_tod_adjust += qtp->adjust.tick_nsec_inc;
         // If an adjustment to the clock is over we restore orig nsec_inc.
         if(--qtp->adjust.tick_count == 0) {
             qtp->adjust.tick_nsec_inc = 0;
         }
         MEM_BARRIER_WR();
     }


Robert D'Attilio wrote:
> Colin:
> 
> Quoting from the documentation
> (http://www.qnx.co.il/developers/docs/6.3.0SP3/neutrino/building/startup
> .html?printable=1) in the syspage_entry qtime section: 
> 
> ...You could give ClockAdjust() a value of 0 for the number of ticks, to
> indicate that you want to make this adjustment "permanent". If you don't
> want to do that, you can give the ClockAdjust() function the maximum
> possible value for tick_count...
> 
> I would interpret the first sentence to mean that adjustment will always
> be applied. If that isn't correct then maybe the docs should get fixed
> or at least some clarification added.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 4:45 PM
> To: ostech-core_os
> Subject: Re: time() drifting more than expected
> 
> Setting tick_count to zero will mean no changes are done...
> 
> Robert D'Attilio wrote:
>> Can't seem to get ClockAdjust() to adjust the time!
>> Here is how I am calling it:
>>     
>>     struct _clockadjust adjustment;
>>     adjustment.tick_nsec_inc = 2000;
>>     adjustment.tick_count = 0;
>>
>>     ClockAdjust( CLOCK_REALTIME, &adjustment, NULL);
>>
>> My understanding is that setting tick_count=0 will apply the
>> (tick_nsec_inc) offset on every tick. Is my interpretation correct? 
>>
>> I would also like to try the alternative of modifying the nsec_inc
> qtime
>> entry directly. There is some mention of getting the physical address
> of
>> the qtime sys entry and then using mmap to remap it r/w. Would someone
>> have a code snippet of this as I'm not 100% sure how to do it.
>>
>> Thanks again
>> Robert
>>
>> -----Original Message-----
>> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
>> Sent: Wednesday, June 10, 2009 11:24 AM
>> To: ostech-core_os
>> Subject: RE: time() drifting more than expected
>>
>> Oh well, another long shot shot to heck.... ;-)
>>
>> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
>>> So far I've only been able to profile two boards and they both show
>> the
>>> same drift. The crystals we use are rated at 100 ppm which works out
>> to
>>> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
>>>
>>> -----Original Message-----
>>> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
>>> Sent: Wednesday, June 10, 2009 11:08 AM
>>> To: ostech-core_os
>>> Subject: RE: time() drifting more than expected
>>>
>>> I don't know if it helps any, but it used to be the case that there
>>> could be a lot of variation in individual crystal oscillators (at one
>>> time +/- 5 percent wasn't unusual).  Is the magnitude of the problem
>> the
>>> same on all boards of this type?  Or is this particular piece of
>>> hardware an outlier?
>>>
>>> On Wed,...
View Full Message
Robert D'Attilio(deleted)
06/11/2009 9:50 AM
post31485
RE: time() drifting more than expected   
Colin:

Thanks for the clarification.

robert

-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com] 
Sent: Thursday, June 11, 2009 9:27 AM
To: ostech-core_os
Subject: Re: time() drifting more than expected

I think those docs are wrong - as per the ClockAdjust() manual page...

http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/c/clockadjust.
html

"You can cancel any adjustment in progress by setting tick_count and
tick_nsec_inc to 0."

and from the code (services/system/ker/nano_clock.c)

     if(qtp->adjust.tick_count) {
         // Adjust the clock
         qtp->nsec_tod_adjust += qtp->adjust.tick_nsec_inc;
         // If an adjustment to the clock is over we restore orig
nsec_inc.
         if(--qtp->adjust.tick_count == 0) {
             qtp->adjust.tick_nsec_inc = 0;
         }
         MEM_BARRIER_WR();
     }


Robert D'Attilio wrote:
> Colin:
> 
> Quoting from the documentation
>
(http://www.qnx.co.il/developers/docs/6.3.0SP3/neutrino/building/startup
> .html?printable=1) in the syspage_entry qtime section: 
> 
> ...You could give ClockAdjust() a value of 0 for the number of ticks,
to
> indicate that you want to make this adjustment "permanent". If you
don't
> want to do that, you can give the ClockAdjust() function the maximum
> possible value for tick_count...
> 
> I would interpret the first sentence to mean that adjustment will
always
> be applied. If that isn't correct then maybe the docs should get fixed
> or at least some clarification added.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, June 10, 2009 4:45 PM
> To: ostech-core_os
> Subject: Re: time() drifting more than expected
> 
> Setting tick_count to zero will mean no changes are done...
> 
> Robert D'Attilio wrote:
>> Can't seem to get ClockAdjust() to adjust the time!
>> Here is how I am calling it:
>>     
>>     struct _clockadjust adjustment;
>>     adjustment.tick_nsec_inc = 2000;
>>     adjustment.tick_count = 0;
>>
>>     ClockAdjust( CLOCK_REALTIME, &adjustment, NULL);
>>
>> My understanding is that setting tick_count=0 will apply the
>> (tick_nsec_inc) offset on every tick. Is my interpretation correct? 
>>
>> I would also like to try the alternative of modifying the nsec_inc
> qtime
>> entry directly. There is some mention of getting the physical address
> of
>> the qtime sys entry and then using mmap to remap it r/w. Would
someone
>> have a code snippet of this as I'm not 100% sure how to do it.
>>
>> Thanks again
>> Robert
>>
>> -----Original Message-----
>> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
>> Sent: Wednesday, June 10, 2009 11:24 AM
>> To: ostech-core_os
>> Subject: RE: time() drifting more than expected
>>
>> Oh well, another long shot shot to heck.... ;-)
>>
>> On Wed, 2009-06-10 at 11:21 -0400, Robert D'Attilio wrote:
>>> So far I've only been able to profile two boards and they both show
>> the
>>> same drift. The crystals we use are rated at 100 ppm which works out
>> to
>>> 8 seconds a day. I'm seeing a drift about 24 X larger than that.
>>>
>>> -----Original Message-----
>>> From: Neil Schellenberger [mailto:community-noreply@qnx.com] 
>>> Sent: Wednesday, June 10, 2009 11:08 AM
>>> To: ostech-core_os
>>> Subject: RE: time() drifting more than expected
>>>
>>> I don't know if it helps any, but it used to be the case that there
>>> could be a lot of variation in individual crystal oscillators...
View Full Message
Steve Reid
06/11/2009 9:53 AM
post31486
RE: time() drifting more than expected   
That whole section in Building Embedded Systems on adjusting the clock
looks a bit dubious to me. I'll create a doc PR and try to track down
the original information (from one of the defunct newsgroups). Thanks
for pointing this out.

Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems
Robert D'Attilio(deleted)
06/11/2009 10:20 AM
post31489
RE: time() drifting more than expected   
Thanks Steve. This paragraph, in the same section, could also stand a
bit of clarification and beefing up with a code example:

"...If you need to change the number of nsecs that the OS adds to the
time when a tick fires, you can manually adjust the nsec_inc value in
SYSPAGE_ENTRY (qtime).

...

What you'll need to do is find out the physical address of the syspage.
If it's already in nsec_inc you won't need to modify startup. If not,
modify startup to put it there. Then use the mmap_device_memory()
function to make the physical address of the syspage writable. That is,
get the offset to the read-only page, and map a new block of memory to
the address...."

Would it be possible to get some kind of notification when it gets
updated?

robert

-----Original Message-----
From: Steve Reid [mailto:community-noreply@qnx.com] 
Sent: Thursday, June 11, 2009 9:54 AM
To: ostech-core_os
Subject: RE: time() drifting more than expected

That whole section in Building Embedded Systems on adjusting the clock
looks a bit dubious to me. I'll create a doc PR and try to track down
the original information (from one of the defunct newsgroups). Thanks
for pointing this out.

Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems 

_______________________________________________
OSTech
http://community.qnx.com/sf/go/post31486
Steve Reid
07/08/2009 5:38 PM
post33440
Re: RE: time() drifting more than expected   
Hi, Robert.

I discussed this section with Colin and Brian, and they thought it would be best to remove the dubious part of it 
completely, and instead recommend using the startup code to adjust the timing. The change will be in the next release.

> Thanks Steve. This paragraph, in the same section, could also stand a
> bit of clarification and beefing up with a code example:
> 
> "...If you need to change the number of nsecs that the OS adds to the
> time when a tick fires, you can manually adjust the nsec_inc value in
> SYSPAGE_ENTRY (qtime).
> 
> ...
> 
> What you'll need to do is find out the physical address of the syspage.
> If it's already in nsec_inc you won't need to modify startup. If not,
> modify startup to put it there. Then use the mmap_device_memory()
> function to make the physical address of the syspage writable. That is,
> get the offset to the read-only page, and map a new block of memory to
> the address...."
> 
> Would it be possible to get some kind of notification when it gets
> updated?
> 
> robert
Robert D'Attilio(deleted)
07/10/2009 10:40 AM
post33535
RE: RE: time() drifting more than expected   
Thanks for the update Steve.

robert

-----Original Message-----
From: Steve Reid [mailto:community-noreply@qnx.com] 
Sent: Wednesday, July 08, 2009 5:39 PM
To: ostech-core_os
Subject: Re: RE: time() drifting more than expected

Hi, Robert.

I discussed this section with Colin and Brian, and they thought it would
be best to remove the dubious part of it completely, and instead
recommend using the startup code to adjust the timing. The change will
be in the next release.

> Thanks Steve. This paragraph, in the same section, could also stand a
> bit of clarification and beefing up with a code example:
> 
> "...If you need to change the number of nsecs that the OS adds to the
> time when a tick fires, you can manually adjust the nsec_inc value in
> SYSPAGE_ENTRY (qtime).
> 
> ...
> 
> What you'll need to do is find out the physical address of the
syspage.
> If it's already in nsec_inc you won't need to modify startup. If not,
> modify startup to put it there. Then use the mmap_device_memory()
> function to make the physical address of the syspage writable. That
is,
> get the offset to the read-only page, and map a new block of memory to
> the address...."
> 
> Would it be possible to get some kind of notification when it gets
> updated?
> 
> robert



_______________________________________________
OSTech
http://community.qnx.com/sf/go/post33440
Robert D'Attilio(deleted)
09/11/2009 10:39 AM
post37803
Re: time() drifting more than expected (New Info)   
Hi:

I'm back again with some new info on this problem were experiencing. But to recap: we're running QNX632 on a PPC405EP 
clocked at 200 MHz. We're noticing a time drift (loss) of 71 seconds over a 12 hour period. The card does not have an 
RTC. All time deltas  I'm reporting are relative to an NTP synchronized clock. 

I've conducted a few more tests in the hope of isolating the root cause and he is a summary of my results (please bear 
with the length :

1) The oscillator driving the CPU is a 25 MHz part rated at 100 ppm. We measured the oscillator with the spectrum 
analyzer and found it to be 25.0001 MHz. So it's within spec. The 200 MHz output from the internal PLL is not accessible
 but we were able to measure it indirectly and confirm it was centered on 199.985 MHz.

2) Time drift varies with the load on the CPU. With just the bare OS running (with serial driver for comms) I've 
measured a loss of -49 seconds over 12 hours. As processes are added back, this loss increases to the -71 seconds where 
the full application load is running. The first thing that comes to mind in explaining this is that some application(s) 
are locking out interrupts but see point 3) below which proves this isn't the case.

3) I configured my own version of a time-of day clock by routing an external periodic signal (running at 100 ms period, 
or 1 ms period) to an external interrupt and counting the number of ticks in my interrupt handler. The ticks were 
initially synchronized with the same value in the OS-based clock (i.e. what's returned by a call to time()). Over a 12 
hour period my clock showed a 0 sec loss/gain versus 50 seconds for the OS clock. Note this measurement was made with 
just the bare OS, no application code other than my interrupt handler. This indicates, to me, that the time loss in the 
OS clock is not because of locked out interrrupts, otherwise my interrupt-based clock would show similar losses.

4) Changing the tick rate on the OS from 1 ms to 10 ms improves the loss by a factor of 10x i.e. loss goes from -49 
seconds to -5 over 12 hours.

I think the above strongly suggests that there is something not quite right in the maintenance of the OS-based clock. I 
do expect some losses due to the accumulation of errors due to interrupt latency in processing the decrementer interrupt
 but the anomalies I'm seeing are much larger than I (and others) expect. I do have a temporary workaround by "playing" 
with the value intput into the decrementer in the BSP startup code. However, I would have to tune this value with every 
release of our software as the drift varies with the CPU load.

Can someone (at QNX) take another look at the code for maintaining the OS clock? Can you confirm if the decrementer auto
-reloads or is manually reloaded? Why would CPU load affect the update of the OS clock. I would assume that you would 
use a similar mechanism as the time-of-day clock I implemented in 3) above and increment some counter while within the 
decrementer interrupt handler, no? My understanding is that there are very few places in the kernel where you lock out 
interrupts and even then it is very, very short.

Thanks
robert

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems