From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 8721 invoked from network); 21 Oct 2022 17:14:01 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 21 Oct 2022 17:14:01 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Fri Oct 21 13:10:17 -0400 2022
Received: from abbatoir (pool-108-27-53-161.nycmny.fios.verizon.net [108.27.53.161])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id a4f89c74 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Fri, 21 Oct 2022 10:10:16 -0700 (PDT)
Message-ID: <7B69CEA13EBA5D1BE9498BF992802D01@eigenstate.org>
To: 9front@9front.org
Date: Fri, 21 Oct 2022 13:10:15 -0400
From: ori@eigenstate.org
In-Reply-To: <9a2a70ea-388f-4b2f-bb9a-f401e2dc1934@app.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: ISO-certified component-oriented information controller 
Subject: Re: [9front] Speeding up snoopy(8)
Reply-To: 9front@9front.org
Precedence: bulk

Quoth David Arroyo <droyo@aqwari.net>:
> On Fri, Oct 21, 2022, at 12:04, ori@eigenstate.org wrote:
> > Quoth David Arroyo <droyo@aqwari.net>:
> >> On Thu, Oct 20, 2022, at 12:03, Sigrid Solveig Haflínudóttir wrote:
> >> > It would be nice to have a way to get monotonic timestamps in userspace
> >> > without having to go into the kernel. For now, you can try nanosec and
> >> > see if anything changes.
> >> 
> >> I tried using nanosec, and that was sufficient for snoopy to keep up
> >> with a bit rate of 1.6 Gbps, with no overflows. Thank you for the tip!
> >
> > ...should we replace the nsec() function with it?
> >
> > we may be able to stash nsec (and monotonic nsec?) at last
> > context switch into tos, and interpolate using cycles.
> 
> I don't fully understand the tradeoffs in using nanosec() over nsec().
> For packet captures, I specifically *don't* want time adjustments during
> a capture, so nanosec() being monotonic is a plus.
> 
> It doesn't matter for snoopy currently, but is nanosec() thread-safe?
> It's keeping xstart in a static variable; would different threads have
> different xstarts, or could they step on each other if they call
> nanosec() at the same time?
> 
> David

it is not; as it stands, it's not a drop-in replacement for nsec();
doing it properly would mean extending the Tos struct, I think.