Interesting ... so at a future point we could certainly consider using a larger integer type.
I am probably leaning towards 1e9 * ((double)val.QuadPart / (double)freq.QuadPart) compared to val.QuadPart * (1e9 / (double)freq.QuadPart) but I don't think it make much difference in practice.
I also think it would we worth subtracting the ioc boot time "val.QuadPart" value from the counter, so the result becomes effectively nanoseconds since ioc startup, which makes the values smaller and hence time differences less likely to accumulate small errors.
--
https://code.launchpad.net/~freddie-akeroyd/epics-base/+git/epics-base/+merge/391018
Your team EPICS Core Developers is subscribed to branch epics-base:7.0.
- References:
- [Merge] ~freddie-akeroyd/epics-base:fix_win32_monotonic_time into epics-base:7.0 Freddie Akeroyd via Core-talk
- Navigate by Date:
- Prev:
Re: [Merge] ~freddie-akeroyd/epics-base:fix_win32_monotonic_time into epics-base:7.0 mdavidsaver via Core-talk
- Next:
Re: [Merge] ~freddie-akeroyd/epics-base:fix_win32_monotonic_time into epics-base:7.0 Freddie Akeroyd via Core-talk
- Index:
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: [Merge] ~freddie-akeroyd/epics-base:fix_win32_monotonic_time into epics-base:7.0 mdavidsaver via Core-talk
- Next:
Re: [Merge] ~freddie-akeroyd/epics-base:fix_win32_monotonic_time into epics-base:7.0 Freddie Akeroyd via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|