clock(3) in error

clock(3) in error

[Michael J. Baars via Libc-alpha]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

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.

Best regards,
Mischa Baars.

[-- Attachment #2: benchmark_inet.t-mobile.7z --]
[-- Type: application/x-7z-compressed, Size: 75165 bytes --]

clock(3) in error

[Michael J. Baars via Libc-alpha]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

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.

Best regards,
Mischa Baars.

[-- Attachment #2: benchmark_inet.t-mobile.7z --]
[-- Type: application/x-7z-compressed, Size: 75165 bytes --]

Re: clock(3) in error

[Adhemerval Zanella via Libc-alpha]

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.

Re: clock(3) in error

[Michael J. Baars via Libc-alpha]

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"?

Mischa.

Re: clock(3) in error

[Michael J. Baars via Libc-alpha]

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. 

Apparently they pinched off the fiber optic cable using this faulty clock() function. Now it measures exactly 100mbit at half duplex - packet size  32768, but
using the corrected clock() function it would measure something significantly lower.

> 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.

Re: clock(3) in error

[Luis Javier Merino via Libc-alpha]

>
> > 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.
>

Note that clock() returns the CPU time used by the process, not the
wall-clock time.

Re: clock(3) in error

[Adhemerval Zanella via Libc-alpha]

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

Re: clock(3) in error

[Michael J. Baars via Libc-alpha]

[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]

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.

[-- Attachment #2: benchmark_coreutils.7z --]
[-- Type: application/x-7z-compressed, Size: 2700 bytes --]

Re: clock(3) in error

[Michael J. Baars via Libc-alpha]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Tue, 2021-07-20 at 18:22 +0200, Luis Javier Merino 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.
> 
> Note that clock() returns the CPU time used by the process, not the wall-clock time. 

I prefer this XS4ALL 100mbit fiber optic cable anyway :)

[-- Attachment #2: benchmark_inet.log.xs4all --]
[-- Type: text/plain, Size: 2781 bytes --]

# clock_0 (process)

inet socket             half duplex - packet size 131072 -    0.9027 gbit/s
inet socket             half duplex - packet size  65536 -    0.7757 gbit/s
inet socket             half duplex - packet size  32768 -    0.6915 gbit/s
inet socket             half duplex - packet size  16384 -    0.3642 gbit/s
inet socket             half duplex - packet size   8192 -    0.2197 gbit/s
inet socket             half duplex - packet size   4096 -    0.1178 gbit/s
inet socket             half duplex - packet size   2048 -    0.0778 gbit/s
inet socket             half duplex - packet size   1024 -    0.0390 gbit/s
inet socket             half duplex - packet size    512 -    0.0258 gbit/s

inet socket             full duplex - packet size 131072 -    1.7187 gbit/s
inet socket             full duplex - packet size  65536 -    1.4714 gbit/s
inet socket             full duplex - packet size  32768 -    1.3250 gbit/s
inet socket             full duplex - packet size  16384 -    0.7913 gbit/s
inet socket             full duplex - packet size   8192 -    0.3718 gbit/s
inet socket             full duplex - packet size   4096 -    0.1737 gbit/s
inet socket             full duplex - packet size   2048 -    0.1262 gbit/s
inet socket             full duplex - packet size   1024 -    0.0410 gbit/s
inet socket             full duplex - packet size    512 -    0.0264 gbit/s

# clock_1 (system)

inet socket             half duplex - packet size 131072 -  384.4419 mbit/s
inet socket             half duplex - packet size  65536 -  394.4794 mbit/s
inet socket             half duplex - packet size  32768 -  338.1600 mbit/s
inet socket             half duplex - packet size  16384 -  234.4915 mbit/s
inet socket             half duplex - packet size   8192 -  162.5055 mbit/s
inet socket             half duplex - packet size   4096 -  108.5021 mbit/s
inet socket             half duplex - packet size   2048 -   68.1359 mbit/s
inet socket             half duplex - packet size   1024 -   43.7110 mbit/s
inet socket             half duplex - packet size    512 -   27.5559 mbit/s

inet socket             full duplex - packet size 131072 -  573.5007 mbit/s
inet socket             full duplex - packet size  65536 -  480.9169 mbit/s
inet socket             full duplex - packet size  32768 -  480.8279 mbit/s
inet socket             full duplex - packet size  16384 -  365.5978 mbit/s
inet socket             full duplex - packet size   8192 -  255.9557 mbit/s
inet socket             full duplex - packet size   4096 -  142.3687 mbit/s
inet socket             full duplex - packet size   2048 -  103.3635 mbit/s
inet socket             full duplex - packet size   1024 -   44.5703 mbit/s
inet socket             full duplex - packet size    512 -   28.4246 mbit/s

Re: clock(3) in error

[Adhemerval Zanella via Libc-alpha]

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