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 7533641DD9 for ; Mon, 6 Mar 2023 18:33:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EB44D40EDB; Mon, 6 Mar 2023 18:33:19 +0100 (CET) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by mails.dpdk.org (Postfix) with ESMTP id 5D99B40A8A for ; Mon, 6 Mar 2023 18:33:18 +0100 (CET) Received: by mail-yb1-f178.google.com with SMTP id k23so8939430ybk.13 for ; Mon, 06 Mar 2023 09:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678123997; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=CO6qVttYe5Ah3GrE14CKVRdZcCdWqRFmrJiGTpT0pr8=; b=ic2pMK/8aAqhLQdAwufyaO1FfZmG6vbmgbHDQylfGbvBCmEYK5QW3Y+torW4cQoyvg leQRyg7nBZ7ad6/A8qtgc3y2d2BPwtQSQsi2fdd8WBg3ODgnCeOEksHvHj8b8nsGOxZY eTRrnizUJfJMmNP0O9tJD0uJOXJCpFIHngYs4Fs/BWVkSzRwla3XL1qWyz55UY86RZJj /ch2WERiWZIVMoRyXBfTHD8N1WUUwUp5ZoUbA+1rjrQDPAmRnt5fCUyB7LkIXF3M5vvz vJbSikN2fADE3R4pZ1maHYus0eukFVIq8zncIc43CXu5Nmu8/YCt+rZEp8/OvHmWJHj0 +zHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678123997; h=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=CO6qVttYe5Ah3GrE14CKVRdZcCdWqRFmrJiGTpT0pr8=; b=W7CATXk9JdLpEUKGoe+BIwgFizTIlgpKjoqUrAKFrIGcqZkS9AYAHV1r3uAiHpux/I Jeq+TO7eKhGkNMtzNUkPEen0A/s8xXUnmN+xg+X/1XjCWjsdsQESmKb2r+fe9MuqLgFF /62sZtmkZIuSAvJ/G+C2GBF2oPaz3hBBWm8WxNzy+sIwEdS1YHUJj297EL8UgWOPLYKS JObEOqsgpnhI0yV9ZHU0tzSSnZ7jjmDbJu5l0U5T2gwPvZ6b60ol6Ejja5I3ZnFTj3Ok UIglJ2LLqcfuSL3NV6qDCNQ4epkFo5AEwBDrDfrfbrvlRQDruDJ1qyWBaxL9aZ4REe+N jQIQ== X-Gm-Message-State: AO0yUKWSdmbU26Y/yKIivR+dR/Xq0asqeVXBowDixjanR+4lqDVcDSuO TBxUK0afYrjiGRWqLYjXmDpxz2i/VEbCInQQcYkPGVKFYpSUoQ== X-Google-Smtp-Source: AK7set/OSG3CvRulqMKaEfQVku1Pbu5PdGVLLjqcCG9YQUkhpbC6/u1NSn33b5D5WFrY55GdQ8q0KEPNWw3bzHg4eHo= X-Received: by 2002:a25:9888:0:b0:a88:ba7:59b with SMTP id l8-20020a259888000000b00a880ba7059bmr6931068ybo.9.1678123997148; Mon, 06 Mar 2023 09:33:17 -0800 (PST) MIME-Version: 1.0 References: <20230306085614.72951a6f@hermes.local> In-Reply-To: <20230306085614.72951a6f@hermes.local> From: fwefew 4t4tg <7532yahoo@gmail.com> Date: Mon, 6 Mar 2023 12:33:06 -0500 Message-ID: Subject: Re: Using rdtsc to timestamp RTT of packets To: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000bd383c05f63eb0c4" 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 --000000000000bd383c05f63eb0c4 Content-Type: text/plain; charset="UTF-8" Using rdtsc to timestamp RTT of packets Stephen/Gabor/Harry: Gents thanks for the guidance; this mailing list is great. The message is rdtsc is just fine. Got it. The command line (from Harry): >lscpu | egrep "constant_tsc|nonstop_tsc" is operationally ideal: specific, easy, and answers the issue of invariance/constancy clearly. On Mon, Mar 6, 2023 at 11:56 AM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Sun, 5 Mar 2023 20:01:15 -0500 > fwefew 4t4tg <7532yahoo@gmail.com> wrote: > > > I think rdtsc does all this. But then I read [1]: > > > > - The TSC is not always invariant > > - And of course context switches (if a thread is not pinned to a core) > > will invalidate any time difference > > - The TSC is not incremented when the processor enters a deep sleep. I > > don't care about this because I'll turn off the power saving modes > anyway > > Stack Overflow is only one step better than ChatGPT in giving > partially correct answers. > > TSC is almost always works well on modern processors. > The Linux kernel aligns all the TSC values for each core at boot up. > It is invariant (derived from a single clock source) unless you have some > poorly designed NUMA system. In the past, there were some CPU's that > did bad things during suspend, but that is fixed in current generations. > > Bottom line: that advice is no longer true. > --000000000000bd383c05f63eb0c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Using rdtsc to timestamp RTT of packets

Stephen/Gab= or/Harry: Gents thanks for the=C2=A0guidance; this mailing list is great. T= he message is rdtsc is just fine. Got it.

The command line (from Har= ry):
>lscpu | egrep "constant_tsc|nonstop_tsc"
is operat= ionally ideal: specific, easy, and answers the issue of invariance/constanc= y clearly.

On Mon, Mar 6, 2023 at 11:56 AM Stephen Hemminger <stephen@networkplumber.org> wrote= :
On Sun, 5 Mar = 2023 20:01:15 -0500
fwefew 4t4tg <7= 532yahoo@gmail.com> wrote:

> I think rdtsc does all this. But then I read [1]:
>
>=C2=A0 =C2=A0 - The TSC is not always invariant
>=C2=A0 =C2=A0 - And of course context switches (if a thread is not pinn= ed to a core)
>=C2=A0 =C2=A0 will invalidate any time difference
>=C2=A0 =C2=A0 - The TSC is not incremented when the processor enters a = deep sleep. I
>=C2=A0 =C2=A0 don't care about this because I'll turn off the p= ower saving modes anyway

Stack Overflow is only one step better than ChatGPT in giving
partially correct answers.

TSC is almost always works well on modern processors.
The Linux kernel aligns all the TSC values for each core at boot up.
It is invariant (derived from a single clock source) unless you have some poorly designed NUMA system.=C2=A0 In the past, there were some CPU's t= hat
did bad things during suspend, but that is fixed in current generations.
Bottom line: that advice is no longer true.
--000000000000bd383c05f63eb0c4--