Am 22.05.2014 00:14, schrieb Richard Hansen:
> On 2014-05-20 15:11, Karsten Blees wrote:
>> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
>> unsigned 64-bit integer (i.e. overflows in july 2554).
>
> Must it be relative to epoch? If it was relative to system boot (like
On 2014-05-21 18:14, Richard Hansen wrote:
> On 2014-05-20 15:11, Karsten Blees wrote:
>> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
>> unsigned 64-bit integer (i.e. overflows in july 2554).
>
> Must it be relative to epoch? If it was relative to system boot (like
>
On 2014-05-20 15:11, Karsten Blees wrote:
> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
> unsigned 64-bit integer (i.e. overflows in july 2554).
Must it be relative to epoch? If it was relative to system boot (like
the NetBSD kernel's nanouptime() function), then you
Am 21.05.2014 09:31, schrieb Noel Grandin:
> On 2014-05-20 21:11, Karsten Blees wrote:
>> * implement Mac OSX version using mach_absolute_time
>>
>>
>
>
> Note that unlike the Windows and Linux APIs, mach_absolute_time does not do
> correction for frequency-scaling
I don't have a MAC so I can
On 2014-05-20 21:11, Karsten Blees wrote:
* implement Mac OSX version using mach_absolute_time
Note that unlike the Windows and Linux APIs, mach_absolute_time does not do correction for frequency-scaling and
cross-CPU synchronization with the TSC.
I'm not aware of anything else that you
Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
unsigned 64-bit integer (i.e. overflows in july 2554). This is easier to
work with than e.g. struct timeval or struct timespec.
The implementation uses gettimeofday() by default; supports high precision
time sources on the f
6 matches
Mail list logo
