clock(3) in error

[Adhemerval Zanella]

On 20/07/2021 08:37, Michael J. Baars wrote:
> On Mon, 2021-07-19 at 09:04 -0300, Adhemerval Zanella wrote:
>>
>> On 19/07/2021 08:34, Michael J. Baars via Libc-alpha wrote:
>>> Hi,
>>>
>>> I've been using the clock() function for years now. Until recently I thought the timing mechanism worked perfectly, then I tried to let the actual time run
>>> next
>>> to it. As it appears, the clock() function isn't working as perfectly as I thought.
>>>
>>> As a consequence, my internet connection from T-Mobile, which I don't have anymore, so I can't show you the actual speed with the clock() corrected, wasn't
>>> running at 100mbit/s but a lot slower. The same holds for all other T-Mobile customers in Holland. I hope that someone is willing to have a look at the
>>> glibc
>>> clock() function and repair it. A lot of people would benefit from that.
>>>
>>> Attached: the benchmark of the 100mbit internet connection, the corrected clock() function and an application that shows the malfunction.
>>
>> I didn't fully understand how the clock_gettime() implementation would be 
>> related to your internet speed, neither from which architecture, kernel
>> version, and glibc version you obtained your numbers. 
> 
> architecture:	x86_64
> kernel:		kernel-5.10.8-100.fc32.x86_64
> glibc:		glibc-2.31-5
> 
>> In any case the clock_gettime() implementation has been changed recently 
>> to support 64-bit time_t on legacy architectures.  Another issue on previous
>> release was to move the vDSO pointer setup to loader, so there is no need
>> to demangle it before running (they are set on a read-only page and it
>> might increases the latency a bit).
>>
>> Currently for ABI with default 64-bit time_t there is no change (x86_64 for
>> instance).  On legacy ABI with 32-bit time_t support, it would first try
>> to use the vDSO (first the 64-bit one, then the 32-bit) and then the 64-bit
>> syscall, and if it is not available the 32-bit time_t one.
>>
>> So the potential issues you might find are either if you are running on
>> an architecture without any vDSO support on a pre v5.1 kernel (without
>> 64-bit support) or if you are running on a pre v5.1 kernel with vDSO
>> support on y2038 or later. For former, glibc will issue an additional
>> 64-bit syscall that will return ENOSYS; for later it would first run
>> the vDSO to fallback to the 64-bit syscall and later on the 32-bit time_t
>> syscall.
> 
> Are you telling me the clock from the example application runs normal on your machine with "#undef	CLOCK_CORRECTED"?

No, because clock() uses CLOCK_PROCESS_CPUTIME_ID, while your code for
CLOCK_CORRECTED uses CLOCK_REALTIME.  That's why I puzzled why this is
in any slight related to your internet connection, nor why one would
use clock_gettime(CLOCK_REALTIME) as a replacement for clock() (each
interface uses completely different clocks).

The clock() implementation has been changed on 2.18 (released on 2013)
to use CLOCK_PROCESS_CPUTIME_ID instead of times() plus _SC_CLK_TCK
to fix BZ#12515 [1].  It allows to get much better precision since
it uses kernel to handle the timer precision instead of trying to
emulate it on userspace (which has inherent issues).

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=12515