From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id E90173857426 for ; Wed, 21 Jul 2021 08:38:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E90173857426 Received: by mail-ej1-x62f.google.com with SMTP id dp20so2025202ejc.7 for ; Wed, 21 Jul 2021 01:38:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=iCx4wskWF+aKUFhRpidV+D7EMYR2xYs1G7WXTO2B+RU=; b=cSs8SrCwjfjo8aIoobzPL99cUvDQcdaEfzekNUyBhKunBwpZaeOCjE+jO5obYBDJRo gVntAJx+OuOVVj75DyZrTvZf1jG2ylpNo8jCxC6uLNiEDMYro0XOc0U7drGljH9aW9cv PD77HJ6tFyeB7o19eVF6CxObe6hA1LMbY8hbxj48iQvjRb64zzZeFWJoyH5bpMpofMJj p+MAF8Roiybvk2AopAfMEC9bWQbuCPeosY9dwQJ5uw4GlCmF1PtwKVAn+5NAoHwxvWQl QqGgQkgzPS23w58NkbLeKVAi7P+nhydQEgqqBEJXZXSHDOUMa51spwv2IZWIQRXsuRxp hRow== X-Gm-Message-State: AOAM5308IThFHAxsLNzUhkuApwnLYFA2g3LD47FgEAZLVtqx7te561is ZAK6PAZ0B3gx3EzN+zg6GLdQDxpzEEgNW048 X-Google-Smtp-Source: ABdhPJwgqapECAPKis+WTuV+14Q1IK+wCDQqQllGm7tU6/DdQmi+m9nBAKicl1sJ0WuI1P7EGUacbA== X-Received: by 2002:a17:907:20b7:: with SMTP id pw23mr36382422ejb.198.1626856733814; Wed, 21 Jul 2021 01:38:53 -0700 (PDT) Received: from tp06.long4more.com (82-94-23-232.ip.xs4all.nl. [82.94.23.232]) by smtp.gmail.com with ESMTPSA id h17sm7974528ejl.37.2021.07.21.01.38.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jul 2021 01:38:52 -0700 (PDT) Message-ID: <9fbdacdc1e9951912e31d3785b701591f146475e.camel@gmail.com> Subject: Re: clock(3) in error From: "Michael J. Baars" To: Adhemerval Zanella , Libc-alpha Date: Wed, 21 Jul 2021 10:38:52 +0200 In-Reply-To: References: <66756e9f66b79aba6c34bd880b7a73cc4f6b38e6.camel@gmail.com> <75af16ae-3d56-5dcd-3202-5d838fa90bf5@linaro.org> <1dd0353026a7eb0c1e2117eac4de0185e169850d.camel@gmail.com> Content-Type: multipart/mixed; boundary="=-0m3/ig1a8cefZUTrFZti" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 08:38:57 -0000 --=-0m3/ig1a8cefZUTrFZti Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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. --=-0m3/ig1a8cefZUTrFZti Content-Type: application/x-7z-compressed; name="benchmark_coreutils.7z" Content-Disposition: attachment; filename="benchmark_coreutils.7z" Content-Transfer-Encoding: base64 N3q8ryccAAPmm7T+SQoAAAAAAAAjAAAAAAAAAGAX2gEAEZpJxkcPE6IARSRn0TvMYuztYyk9MSbj sobEKyLs9uyMK5pG0A0sU2x2LCRcqUKs9moqgOW9REyFRU4p6+gz1NMQ3fZbAzUdEAWRXVyP2LRG slOAOwUmPo90WECRNrOShmSVzyuNnKf3MPmoybYFcThEWvkb7qeXBTNs8xumZLjsuneBKQZ4oYw+ jeCm+xvnnQbFtVb9zHrUUhGp8EvXeFOkgd85DAEsnGNGD1URgqFDFDrzWVQgK9bNDyB3aZcqUBfE X2LfqeBh7YpRV4Be9Zn5OEwvxIrfhy8Clhv2ChWzlFFs6SiZNn9kydHJbtjakv/Mdj5jen0yW44+ h7Nm1Gqmo6bKx1tzis2K91KLGAlIXvbRN7fCgeyTAbm2V5mLu9mIt32GukLoZtgRor+NwlTMt3gf wmCdLEu6mrIelJMEeYQoilS8iTKCwTwusfKwsKWhdz12wn+mcSiPNBHLIFZNAPCdwnbRBDQenPFp YaWZFZujJTH59vf4Ie4H5XdHpsJ58cXZDnvIjATU4cMaB9QHSWO8dJHP91M4yIPHxSxQ9njE4j+G QEJJ37wAx+6WIerYAJcgzoyhWScvsp7F1lQSYlHz7EKoohBLchFDnvjSoF12GvkEScKL2ngaJ0zz 6U0hTdk3A+KA9ZcfAm4OkLQmB/ERLpAsxmviJHGov1zARFT+TIdlOY6ZP8xRLsw+dwnM85fQtN5e nhSnOf0J25OMHR5ef8Gw5trUOisbBkkK1Yg+VtFN6MWlEGaeEOgnAXVLrizgr1OhfxspiVKZ+zbA DwrcsEn0p+Bs3GZBtcVmI88N4NJSJXrp05+cAtT59o5mlBpmZNvxCrXzb6Rj9UvksqXZjIw8uJBl 2nwe/pvBGGmYZddzLi/rqOud9RqGCPEQUH3sOFYmlTA4mG90hxZWOc3CxL+lSJc2oFNPLTQ/x22v zh4fH4aa94OohzeZBcbNt5VZQAvXjCcBXtYL3ff7LG4eTvtC9iPOCPHfB2pRq78v5HAwrY+DeCkz arX2fPuxmBhINs3u6sdOUz2NrFl2PToqG+qW3OyJNKJ4mdoZoNH48bo0dmsa7Y88tx6TnNXmDhLb m0/mSOSx7ridFKXNN95+v6DLnBQxTd/X83qzHXIrijYMJee4gFCZCGAkl89K8rduZ/CTJx/RpLSc XY7M1Ck8fUU6sruAnjFW0tIIhyqSMrFsUMLdnEI33YmUoP1c5FrpphyxFmaJkKYe34KqVgJsPN5v k57SkSJWL+l4ic61I6EegduIZTFD6eemI3mE8sNRLoCFfzY5bSFSYL5fHWlDj3GgU3Dmw8zJ63ii AmdMAhzJKh6SELAV4sazHcRMEL6dkOQuyKzvUwJokQexYkEplN5r2Tz20qkTZX5JoAYe63PalMgb 5Mfyoh1mB8bJ4BXLAfbLkMe0fTarfEUOTIpQOXPFtfC1+evauRxIBs32hfFQCVlPd/+t55QsZifU r5zoeFf381hxZfhOUCNhckGGlr2oeHps8VGCP1JJK4HDCFEeSIk/2SfofBwFlcnKSHAf3nWdSX+v IEd5Dzx/M363xeYF0W5XF4JamYDHy5qCgHCuRglWBurKjxJ+UUgY62o/COJZfiqPt3uu1Dm+R4Cn 4puYy3c+rjA7pXyxvrevYe6ZKFGyZgCD0f4JAQlzmARXnMul2WybUAHb6BAR3UdVZswlwysgVKDE HmaBNOQ9F8c62wr34xjrBjbWaYFMBiYBN/oFzt+FNmPFvwxu/LaPm1ZcCvsE25VFDuh+Jn8BRr84 gMbCd21BSGvGVl78bjkP3bg315qeBP1T0paO2sCkTdrubD3Mzln1+5FEcX1W57W9DkmhZHGQ0qxk VC08Fxr+8SmZh8p5jC+2TSrZRpf3ZsXFpmsW3eahFBe0bAfrSIRoAsNF1jjWkCpizetdu8aPgG1c jgCf8XhLrGXJL/6PC8wrzFdvwi2x9uenjEP4ILglb98kLsHW/+PoufVhSTCFNcWZ+ov+rtMLTveK LGjtGwtvQK69r7b2tyk4bAup9v4i+OaDWzhkfg5BGxXRQU08c2C/PwyiM5EbuzLA1+alIakOPIxV YsXsKeFDdFm6M6ZDiVC/TzEW4Zs51U78qILl8Yplr988oGhjoWgMuWAKfT0pvhgrBhrh2S+585Bt ogmVak2AfjrrPAv1BdeCkbWh+aJYwJhlGL9RN/F1PE+e6ziqHGK/5Mse9AFLKpzFyGZePvSASCkc j6jxHoAxKNESvSaqD1TkKjNLBJaJ8kPZlJZyL2SvTlr3zMMoIcVrCN9HBQNTG6aEtH/pQDSR7n6U 1+umU9x5MKgWdO4yiTGjVjOzpUbL2RGXlviNpOA0i38cVqIrxCXkw7/iAX/JQbJka1bRVwDKVQOC O04lrEDmE9gd1Fi0KEI1xmZBktemmX7fLJ1xdSwN9fthi6Oq1XwqOtdljI6DhLx4OcNRtJsptRoz QkXwNMpXflkAX4wUpVw7myvfECKdoFJyGdo0W1Ti9ZGEDrHWM+5HNiPe6QUDbQZniVT822ozKHGm 2Q8Nu5lueHxGAXyMgj2XyBMOX0krUkVC1rShEveIR6hBOGRW4AN2KnCYBg8VB0GWu3yVqle5lm76 xDavbEN++AtNnUSYzUocxps4sSHRTqHVcVGNLW3oA93V8p1NDZ47BXA8EwaHKENQ86WAi2ztxQQs sgLxyTjUbzT8upFZ2wP4Uh1hubb2MLGeWS8MlTZjpx8IHMoDoFKuNdRe9YTyQDq6gF/FW+IyKEGR zaTQSnEq2j1MfmuZl4vd3K1Zt4jhq9CI2DiyWVRiQSIh7z4FCqSojrkw8JjMppcthrBbcAkJWPda XZMfkGuUASVM5Z7hytn9f+Sekh7ZcN5RCA3qPqbudWhF5t2xIqfVRLDe1Ea7CwfoZtiG4nME0Whr jV7SJo41vf9/3P6z+qkHVb7b6XC3sIWP7sVvCk2RDrWI64inVIg/FnLhvpQt700kwO+pxyNZaG2p GChYUxz++E49yx9Yua/C/ZJ8jQMHKX75vEBsvPO3+BH/S6monjPEtxI3igur83L3nT4qXXfqm7D/ ylj2qwAAgTMHrg/Vj/IuecZm2o4cYVMb/XInUrVttlpxsg7f4YvKnT6MdgJyiADNFStWe4e43BrC bsumsWWowUwHj+lqpb/gEe9KnfuKneXl7jxqeS9OafKt9LMYHLmENnGTqkIcg3e8msZhjGWeJM1J fY6ZEJwzu9Ovr0x2/d0wXcTvszd9pom84dFCYAMjFPbWwGQNSthVZKPTxD9wpXMgfhINfBq1oAtT X73jgfUWi9I3x9UF/NhtEIwE/+CYT0ELcp7J6Bky0KGRzRiZhFjSa+xf/0naPx22D0tRFxw697qr GUJ/MTudX1pOaDFBYJd8NeSz3LwLLJ/stQVGf2+l/9ZqSHP/uzolWQTCE7ObM+uJyCZIFVj9KA2l xErqX37+iVR+5ZXgUEji9YAUJKj4j6luS7n+5skq3hQU6oGS4DL/7flTBxcGiQUBCYFEAAcLAQAB IwMBAQVdAACAAAyCnwoBO7hFbwAA --=-0m3/ig1a8cefZUTrFZti--