Hi, Sorry, I didn't notice you replied until now - I'm not subscribed to the list.
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. James
signature.asc
Description: OpenPGP digital signature
