From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0DDD8459D7 for ; Fri, 20 Sep 2024 16:39:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C76114067E; Fri, 20 Sep 2024 16:39:19 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id B38DE40669 for ; Fri, 20 Sep 2024 16:39:18 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-7198a7a1c01so1799738b3a.1 for ; Fri, 20 Sep 2024 07:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1726843158; x=1727447958; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=0NpypeOiswhsbpkl2/Yaea4RXSy1rIfnDPsDwgfx5X8=; b=YCiuk41Q9XwcG01T3/CZNZkUeGs/pQGnQ4iawoL4bvRgehLFl6FLO7xREs6bcRZKly KAcgF92bI9UY5VPiUQ/NiUl2QNA83zRGnNg7hVAux+QOWR31qvPljdKF9EaV7d1PZ+Hi TCVY2BgNPj+UP+w93CKxDYMQjGQeLmcQ4OFys4RYvd66Ni97eeSpZm/KL7sAGbT6GUx6 9svclQfy2cRn3w4XJkzlLwpWI1/6TXgZ0H9QgVGyro8llaXUbY4AQBnydzmLpWjgYTHV X+HmzzCLfy3pmTghq2MtoDV1eKlslR5uI44hzXVpm0plj1BEewE3/GAfiyx8hm2XuxQg PQ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726843158; x=1727447958; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0NpypeOiswhsbpkl2/Yaea4RXSy1rIfnDPsDwgfx5X8=; b=em+KgEOjcT7U8htIMPGy5qBlbur1wPuq8FwyG1xHJNHE4kpZz1sa0sACe1Gt5G1s8B r5RwmaEQEx2xlxtu7aLu/q0kY8iMfrw8bYQk/NwbJ51ikgA2Lq/BScjO+afM7CSY3PDT meimP44iq7EgRccakCVmKzrYbC65pxtsdrS+oq4KRmXfi5UH80mYomXGUv9ja7iIckhy Q5Hqb5n7ApWtvOFxZDUuG1TRF5Wtqr6Dv45fVHVMT5hFIf1ktF+FpSXR+b79m51XFFeu xxXLCKCURPasdeJoBz3Bc1tmjxMqHRXdie1ujDXRt6eaXqxAd5qNMYop+l694/Ic9d6B hxPQ== X-Gm-Message-State: AOJu0YxV0YX3CvyrMO3QUf156b4BGs/qDHAwnXp/mv9e5A6ZYdsZTfQS t0c7bcnsQ/vmQmPVxj71xbjpNrp5+/ATSL3if/0R3y/B6lHG79MH/NRlbUDd9vs= X-Google-Smtp-Source: AGHT+IH1F02Dfa20sNKEi3RcXu+npIvUXO5XqgOBzxbdTZ0fmASTSjuu13HAglblobd/EiJuHwxFHQ== X-Received: by 2002:a05:6a00:2308:b0:718:ddd9:a8fa with SMTP id d2e1a72fcca58-7199c96d80dmr4161388b3a.16.1726843157675; Fri, 20 Sep 2024 07:39:17 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71944bcacd1sm9891509b3a.219.2024.09.20.07.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Sep 2024 07:39:17 -0700 (PDT) Date: Fri, 20 Sep 2024 07:39:16 -0700 From: Stephen Hemminger To: Isaac Boukris Cc: users@dpdk.org Subject: Re: Accuracy of rte_get_tsc_hz() compared to linux Message-ID: <20240920073916.2bc8f380@hermes.local> In-Reply-To: References: <20240919152148.45a19343@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Fri, 20 Sep 2024 06:19:35 +0300 Isaac Boukris wrote: > On Fri, Sep 20, 2024 at 1:21=E2=80=AFAM Stephen Hemminger > wrote: > > > > On Thu, 19 Sep 2024 01:04:40 +0300 > > Isaac Boukris wrote: > > =20 > > > Hi, > > > > > > On Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz (see lscpu output at the = end). > > > > > > The rte_get_tsc_hz() returns 2100000 KHz but using it causes our > > > timestamps to lag behind real time (roughly a sec per 10 min). I > > > noticed the kernel uses 2095082 KHz and in fact it gives much better > > > results. > > > > > > dmesg: > > > tsc: Detected 2095.082 MHz processor > > > > > > tsc_freq_khz (custom kmod to exposes kernel's tsc_khz): > > > cat /sys/devices/system/cpu/cpu0/tsc_freq_khz > > > 2095082 =20 > > > > > > Sigh. exposing tsc frequency through sysfs is a Redhat extension > > that never got merged upstream. =20 >=20 > Actually I think it is a google thing, I got it from github, someone > implemented it for all (hence custom). It is a shame it was never > merged as people know about it for a long time. I mean the whole rdtsc > API is incomplete without it. >=20 > As it is, I think the low hanging fruit for now would be to: > - lower the rounding in our linux estimate from 10 to 1 MHz. > - ignore the arch result if the cpu doesn't have the tsc_known_freq flag. The known freq flag doesn't appear to be a CPU flags property, but more of a property that kernel sets when it decides "this is good enough". Really getting better value would require some sort of repeated check (maybe an alarm callback), and using cpu value as a starting point.