Hi Inari,
On 2013-01-08 inari badillo wrote:
> The magnitude of the error is about 700 microsecond (average), no matter
> the SCAN value is. So, it takes about 24min to have a 1s error.
> Answering Michael Davidsaver´s question, I mean precessing relative to the
> start time. The different does not increase every cycle. Sorry if it wasn´t
> clear.
> And finally yes, it seems reasonable to be caused by processing time. But
> in this case, wouldn´t it lead to malfunction?
The scan code does compensate for the time it takes to process the records in
its chain, but it doesn't try to correct for the time difference between when
the thread asked to be woken up and when the OS actually woke it up, and I
think that is the source of your 700us delay.
After adding some code to measure that delay on my workstation (RHEL 6.3 on a
Dual-Core 1GHz AMD Opteron) I have seen varying delays between -60us and
+230us, but nothing quite as big as 700us; my average is around 30-50us.
I will look at merging Eric's patch, or something like it (thanks Eric!).
- Andrew
--
There is no such thing as a free lunch. When invited for lunch,
it is best to check if you are there to eat, or to be eaten.
-- Clive Robinson
- References:
- time drift in camonitor timestamps ibadillo
- Re: time drift in camonitor timestamps inari badillo
- Navigate by Date:
- Prev:
Re: time drift in camonitor timestamps Eric Norum
- Next:
UDT Instruments model 531(Optical Position Monitor) support ? Ivashkevych, Oksana
- 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: time drift in camonitor timestamps Andrew Johnson
- Next:
Re: streamDevice: how to read a value as fast as possible? Dirk Zimoch
- 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
|