clock(3) in error

[Adhemerval Zanella]

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. 

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.