[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Debian Hurd clock precision


Sorry, I didn't notice you replied until now - I'm not subscribed to the

On 28/07/17 13:56, Samuel Thibault wrote:
> James Cowgill, on ven. 28 juil. 2017 09:58:54 +0100, wrote:
>> On 28/07/17 09:05, Richard Braun wrote:
>>> On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote:
>>>> While debugging a timing problem with FFmpeg on Hurd, I noticed that the
>>>> "clock" function has a far lower precision on Hurd than it does on
>>>> Linux, even though CLOCKS_PER_SEC is 1000000 on both. Why is this?
>>>> I also found this patch to libc which may be responsible:
>>>> hurd-i386/unsubmitted-clock_t_centiseconds.diff
>>>> I'm not entirely sure why patching libc is appropriate to fix the
>>>> claimed issues.
>>> The patch has nothing to do with precision. The kernel simply doesn't
>>> have any high resolution timing system, whereas Linux does.
>> In that case, clock should be returning multiples of whatever precision
>> is supported by the kernel so that CLOCKS_PER_SEC is still correct.
> The problem is that applications use it to determine in what units are
> the values in /proc/ , and others assume 100 there. So we're stuck with
> 100 in all of this.

All process times in /proc are in units of sysconf(_SC_CLK_TCK), not
CLOCKS_PER_SEC. Any application using CLOCKS_PER_SEC for reading /proc
is broken and should be fixed.

Do you know what applications are broken? Using CLOCKS_PER_SEC for /proc
would also give the wrong values on Linux so I would have thought they
wouldn't be Hurd specific.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: