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 45C3F459D7 for ; Fri, 20 Sep 2024 17:06:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B58AD4067E; Fri, 20 Sep 2024 17:06:20 +0200 (CEST) Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by mails.dpdk.org (Postfix) with ESMTP id 1954C40669 for ; Fri, 20 Sep 2024 17:06:19 +0200 (CEST) Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2d88edf1340so1602534a91.1 for ; Fri, 20 Sep 2024 08:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726844778; x=1727449578; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JDwE8pASGk8SpqOuMnYbwhHIeZpEBGdjA0XAhqLsmMg=; b=dw9nToaTIayZNA77GvMtmi/UmoNqpXIZCJv2xDBlHDv+CYa026II1w9a7sJMnXzBL1 HAcPRDcVpbet6J4Sr2ycxnPLAF6IvonwDK+0wFqcIkolMUnlGN2EqciBzMNQuuQ+mCNv 1OgOjTJwNpFt5aKNG7akbK6+jeDfSUC+gb6DKLbFcbwCmt3gY9HeXT7GLtHWT3/GW69r 6sM1B2XYLZdr/svEf431cWAjq6vlcpc3Qd5YAAx3BXkTq6UHobI4Vl4RWnjqmqbzNald 7J7GxvL1GzFNKU939qJLzKTOHIh9D13ZBTzenPaplJKfR95Iw+YORZu6yELB37dRwRLr kRHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726844778; x=1727449578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JDwE8pASGk8SpqOuMnYbwhHIeZpEBGdjA0XAhqLsmMg=; b=apspfJb0AuPyXg1s6m9nY/3zJf6upxEttv7jj7kj8+Sebmfo3T0pBbhxEhY0X8QPnQ lhALffG3nwRkoptRttmckUMM1+yqwu96NG7B7lPY944DLN7Gzu3dYMWVTBXKGOv1JqdS kY+WFLyMdhiwF7kGJ033hk7C6n8IZF08fXVF1W8iUbjCEjjjaAozeNYPADi0cK5Pjiiq X4VyA72kIL9NSgfjt3EBk+CiTyjmRgftQImcTvvmauhcqh3PMkG41Jv+17fryrZh7Lu5 N/V9QESQE1iC5hLuXi3hxOVCf5qaM37A22L0z2Z2Yj9Ka8/UBDB70RaPGuKlSqoJGgjQ MX5g== X-Gm-Message-State: AOJu0YwsznsOQLCkEiVX53UMtaOgbDeyslFMJW1OHXFaaracJdYh2+tc B+xHV1dWpf9VBTN4Mvhy5WI8YvAb7TGdvt2a6zmxA0BU70ktDIYIXUfjKI2ZyWtSMZSxZkOOOFz gb8JuuxJBKnkxXe9eolUquTCo7c48ejBs X-Google-Smtp-Source: AGHT+IGNjF+pcnlc5nRXK8NeSS9tYNUsu5jGku2gLP9CkPaYYwzQ+2PsWV3i9UhSI8qQ4Z/E5xpVw7RNoNoxJf18QGg= X-Received: by 2002:a17:90a:4e45:b0:2d8:3fe8:a195 with SMTP id 98e67ed59e1d1-2dd7f3b9b48mr4071698a91.4.1726844777809; Fri, 20 Sep 2024 08:06:17 -0700 (PDT) MIME-Version: 1.0 References: <20240919152148.45a19343@hermes.local> <20240920073916.2bc8f380@hermes.local> In-Reply-To: <20240920073916.2bc8f380@hermes.local> From: Isaac Boukris Date: Fri, 20 Sep 2024 18:06:06 +0300 Message-ID: Subject: Re: Accuracy of rte_get_tsc_hz() compared to linux To: Stephen Hemminger Cc: users@dpdk.org 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, Sep 20, 2024 at 5:39=E2=80=AFPM Stephen Hemminger wrote: > > 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: > > > > > > > Hi, > > > > > > > > On Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz (see lscpu output at th= e 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 bette= r > > > > 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 > > > > > > > > > Sigh. exposing tsc frequency through sysfs is a Redhat extension > > > that never got merged upstream. > > > > 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. > > > > 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 fla= g. > > 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". On linux we could just read /proc/cpuinfo and see what the kernel thinks. > Really getting better value would require some sort of repeated check > (maybe an alarm callback), and using cpu value as a starting point. In practically all my tests, on machines without tsc_known_freq, the value determined by our linux estimation code with rounding lowered to 1KHz, was much better (closer to kernel value, actually exact the kernel value except one case where they differed in a couple of KHz). What would repeated tests give us? I don't think the kernel value changes, does it? In fact I think we should lower the rounding in our linux estimation code to 1KHz (and its time from 100ms to 200ms, just to be on the safe side, the kernel does a full second), as well as lower the rounding of our common code to 1MHz. This will simply be more accurate.