> Because you mention this, I wonder what is the finest clock
> resolution of epicsTimerStartDelay() that I can get. Can I
> employ this technique to get 1 ms delay out of
> epicsTimerStartDelay() ? If so, could you
> please explain further about the how-to ?
There are two types of timer queues - active and passive.
The active queues are general purpose. They are scheduled by an
independent asynchronous thread with instantaneous accuracy
related to epicsThreadSleepQuantum() and average accuracy closer
to, but not, zero. The code epicsTimerTest can be used to
determine how well we are doing on a particular system. On
vxWorks epicsThreadSleepQuantum() typically returns 1/60th of a
second (as you no doubt expect).
The passive queues are application specific. They can be
scheduled any way that you choose. If you have specialized
hardware with time delay based interrupts then that, and the
interrupt latency in the OS, might determine the accuracy of your
implementation of a timer queue.
> when will R3.14.2 be available ?
>
RSN (real soon now)
There are only a few remaining issues, but as soon as I knock one
off another one seems to get added to the list.
Jeff
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Kate Feng
> Sent: Tuesday, April 22, 2003 10:06 AM
> To: Jeff Hill; [email protected]
> Cc: [email protected]
> Subject: Re: epicsTicksPerSecond for OSI ?
>
> Hi Jeff,
>
> Jeff Hill wrote:
>
> > Hi Kate,
> >
> > There are certainly easy ways to compute the difference
> between
> > two EPICS time stamps in seconds and you can also convert an
> > EPICS time stamp to an enhanced struct tm (ANSI C) which
> includes
> > the nanoseconds within a second in addition to the
> conventional
> > date, hour, and second fields. For example, the following
> code
> > measures the delay required to do some computationally
> intensive
> > task and also computes the current date and time.
> >
> > epicsTime begin = epicsTime::getCurrent();
> > .
> > . something computationally intensive
> > .
> > // compute the delay
> > double delayInSeconds = epicsTime::getCurrent() - begin;
> >
> > // compute the date
> > local_tm_nano_sec localDAteAndTime = epicsTime::getCurrent();
> >
>
> Because you mention this, I wonder what is the finest clock
> resolution
> of epicsTimerStartDelay() that I can get. Can I employ this
> technique
> to
> get 1 ms delay out of epicsTimerStartDelay() ? If so,
> could you
> please
> explain further about the how-to ?
>
> >
> > However, perhaps what you are after is thread sleep
> scheduling
> > accuracy? If so, then you may be pleased with the addition of
> > "double epicsThreadSleepQuantum(void)" to the epicsThread API
> in
> > the next release of R3.14. This function returns the minimum
> > sleep interval obtainable from the local OS and has been very
> > useful for improving the accuracy of timers on average.
> >
>
> Yes, epicsThreadSleepQuantum seems to be exactly what I
> wanted.
> I guess I can get around without it for a while.
> However, when will R3.14.2 be available ?
>
>
> Many thanks,
> Kate
>
>
>
- References:
- Re: epicsTicksPerSecond for OSI ? Kate Feng
- Navigate by Date:
- Prev:
Re: epicsTicksPerSecond for OSI ? Kate Feng
- Next:
multithread client l7a
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: epicsTicksPerSecond for OSI ? Kate Feng
- Next:
multithread client l7a
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|