On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani <mani...@lineratesystems.com> wrote: >Under 7.3 (haven't checked 8 or 9) this issue crops up because the >time system call calls gettimeofday under the hood (see >lib/libc/gen/time.c). As a result, the kernel tries to get an >accurate subsecond resolution time that simply gets chopped to the >nearest second.
Under 8.x and later, time(3) uses clock_gettime(CLOCK_SECOND,...) rather than gettimeofday(). This is intended to be much cheaper than gettimeofday(). On 2011-Sep-06 21:15:55 -0400, Rayson Ho <raysonlo...@gmail.com> wrote: >IMO, the time returned by gettimeofday does not need to be high >precision. There are higher resolution time APIs on Linux and I >believe the application programmers know when to use the slower but >more accurate clock API. There are 3 standard APIs for returning time of day: time(3) provides second precision gettimeofday(2) provides microsecond precision clock_gettime(2) provides nanosecond precision By default, FreeBSD attempts to provide resolution as close as possible to the precision - which makes the 2 system calls fairly expensive. In order to reduce the cost where the resolution isn't important, FreeBSD provides several non-standard clock types for clock_gettime(2). This approach differs from Linux - and it seems that there is a non-trivial body of code that assumes that calling gettimeofday() is very cheap. There is probably a good case for an API that provides a resolution of the order of a tick but there is no standard for this. -- Peter Jeremy
pgpvoAwjmooj4.pgp
Description: PGP signature
