From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 32778399C008 for ; Tue, 20 Jul 2021 19:45:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 32778399C008 Received: by mail-pj1-x102b.google.com with SMTP id cu14so334171pjb.0 for ; Tue, 20 Jul 2021 12:45:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PqeSjqiXKPdyLVWEmfahhHUVX/hpUBKsLRnyvU3wujE=; b=Ia44hcOYvJMt+TCK9PQpyWKvcz2x7m3keVU4OTpa4Lsfs5doeuPBGTHWDX6ZnyatSq gwEJ+mhIUrvqcRGVaT6RZyBz6B2rJbc8hGW6iEyasqrzKcr90VW+yhuHw60GU1MaTt+J wK+7gVdF9qrfRAxXZR2cOFzQUSDe+1Gfv2jNtYaCrQhguBawbN7mB9ScQLxtliFitY+f UmjvRb7jXh2NhNbL4pa1qdmc/ZzK4sGB5VR5OVNh1HEv55kXPwrYFfNu8J/Y4thorKy0 DnN1CoCCg3Gsw77ilulJSwVPfDvzPF/Tn/nZdJ1u0cblomclLLJd4WG1B6ArkGV1xciJ H0nw== X-Gm-Message-State: AOAM531mYn3ZwPEODfoGu8n3Xx4gI7KkpyBltN7RTOHVt17Aq0xYfuHj 21MSAus4+36xQLeVq3CfDYVoyGK/oBJ+Ww== X-Google-Smtp-Source: ABdhPJyM8h2akwL3pSQxWVwaH5qtsVeT2o/xBKr+Xcx02yOrP3oF7StjSJEePy2rhX85HwNjs/sm/Q== X-Received: by 2002:a17:903:1243:b029:ed:8298:7628 with SMTP id u3-20020a1709031243b02900ed82987628mr24724570plh.11.1626810306946; Tue, 20 Jul 2021 12:45:06 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:1133:f2b4:82f6:95e1:c3d2? ([2804:431:c7ca:1133:f2b4:82f6:95e1:c3d2]) by smtp.gmail.com with ESMTPSA id m1sm8659170pfc.36.2021.07.20.12.45.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 12:45:06 -0700 (PDT) Subject: Re: clock(3) in error To: "Michael J. Baars" , Libc-alpha References: <66756e9f66b79aba6c34bd880b7a73cc4f6b38e6.camel@gmail.com> <75af16ae-3d56-5dcd-3202-5d838fa90bf5@linaro.org> <1dd0353026a7eb0c1e2117eac4de0185e169850d.camel@gmail.com> From: Adhemerval Zanella Message-ID: Date: Tue, 20 Jul 2021 16:45:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1dd0353026a7eb0c1e2117eac4de0185e169850d.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Tue, 20 Jul 2021 19:45:09 -0000 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