Re: clock(3) in error

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 21/07/2021 05:38, Michael J. Baars wrote:
> On Tue, 2021-07-20 at 16:45 -0300, Adhemerval Zanella wrote:
>>
>> 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
> 
> So what you are saying that it is the correct way to measure the speed of the internet connection? If you want to prevent that other processes can send data
> during you time measurement, you use clock() (CLOCK_PROCESS_CPUTIME_ID).
> 
> That's strange, that makes the speed of my emmc internal flash memory end up at 17.5Gb/s, while dd is running at 25mb/s. The guys at the coreutils mailing list
> simply did not believe me.

I would use CLOCK_REALTIME or even CLOCK_MONOTONIC, since it might have
a strictly correlation between time used by the process and the I/O cpu
usage.  Even then, dependent of system load and kernel scheduling pressure
and tunning you might even not get quite correct results. I would check 
fio tool to check how it does [1].

[1] https://linux.die.net/man/1/fio