From owner-freebsd-arch@freebsd.org Thu Dec 3 16:31:17 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1BF9C4A9F5E for ; Thu, 3 Dec 2020 16:31:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn1Yc4h8yz4RpG for ; Thu, 3 Dec 2020 16:31:16 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1607013075; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=LiyX1bMLEigZ5W7wg3QhmQL8f4bpPIf5TayNlbdiATG1SRRsbhLQYRc+kb5r9ROHGVPgtv+3akKI8 dBoJkUMHBTsRPqdy99aCfO8L/fhoXZeUjT+pvrP07ENXsvbblKtIWXjw9fCr6Cb0zN04vuqBCbN+0Q re3HfvZk1pETYNFVjVq4y9h4H6SpH+XUZAIF7CAoC0tfLOQsqP+Q25xiVf4yufv19ef2sF6rTURNT/ acXwJa5olsdbDCnktZ8tNIU/DjBBQ8qhPOcMd5HuUNnD4TtJg0/szh34CBQSkW80OghwMbRYmGbPTg GWTYBl5TMRZAkJTrGWiooWLYDz8kFlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=omhZxo2ciNFTTIUtSx0hw4woUf0dNKfVRg4FdyCSdLc=; b=N7LQtgzrhznIXAjB3olJTeBfGLVzuxmGNKn0fdlIbZNtqhnyTFaWhCb3mM7gs2d7nFJkKgd1YePWY 25TWJOdBgn0YfQ3gY6/LyGUT+zNS92zxD6bVX19AzWeh5f2X5ESDQs518+8YfTFdYibsp5dQo0AKVn xl0+VAWDlVjXvF3nlU45+M+1LyHc9V5Czo2TNsd2MV6LhthxX6Vxf6S2xEmfSP1TEiGiqr7+BjbYwI dK9xqp2UjaUbjbqnLtIGNWGE1KWJcPciIMGQKS/G/JCffXsCbsYlkmaWYhRCf4eZ1GtdrXAMvWKZ+D u9F0JNa8grr2wpfZWGqpU7lyz+WErlw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=omhZxo2ciNFTTIUtSx0hw4woUf0dNKfVRg4FdyCSdLc=; b=tiIIwaZmKw+U11uDCthRbxKjbM0La2pFjkcKdSNgpwc8cKfSGshnr7iNlT/0qk24TzPZLZgWirco7 y9itcx2kdYQZm7cL1B3j3jCaoPetxuO4HW/pW0Hdd8FVNqnXWPezJaDkYtQJHVBGGGY13ET33UXA3V i2M49ghmCp74wMumkYz4pXN3252GomUuYlDNIQZQT0u267Q1z8pZqgGKkSwx3tuRUdVVnM6CO5df2s SnoWBQaU0eHBOhpyRygnmlSgyJY+CSMxOva1KTmLotZaPnx60zhKRgr0Yof1JC/zQ3Cc7kK5UAdx2q s7KUjHIYuzoxfYcz6y1kyMfh+/Z2EeA== X-MHO-RoutePath: aGlwcGll X-MHO-User: f414f1e4-3584-11eb-9e14-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id f414f1e4-3584-11eb-9e14-df46ed8f892f; Thu, 03 Dec 2020 16:31:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0B3GVAUK003421; Thu, 3 Dec 2020 09:31:11 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> Subject: Re: struct timex and Linux adjtimex() From: Ian Lepore To: Poul-Henning Kamp , Cy Schubert Cc: freebsd-arch@freebsd.org Date: Thu, 03 Dec 2020 09:31:10 -0700 In-Reply-To: <4086.1606982335@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Cn1Yc4h8yz4RpG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 16:31:17 -0000 On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > -------- > Cy Schubert writes: > > > 1. A new syscall, similar to clock_settime() and clock_gettime() > > that > > adds/subtracts the delta, in a struct timespec, via a call to > > kern_clock_settime(). Then atomically returns the current time as > > if > > clock_gettime() was immediately called. > > Did they say why they need this and why simply setting the clock is > not > good enough ? > > What program uses this ? > I have been very much wanting this feature for years, so much so that I've come close to hacking it in myself and just carrying it as local patches to the kernel at $work. We run freebsd on hardware whose timecounter clock is fed from a gps- disciplined oscillator and the hardware in the SOC implementing that clock can capture the counter on an edge of an incoming PPS (which is generated from the same disciplined oscillator), so we can get fairly accurate phase measurements. But I can't set the time with anything like the same accuracy. After a clock_settime() call I'm still off by anything from hundreds of microseconds to milliseconds and have to wait for that error to be tediously steered out over the course of many minutes. Once kernel time is phase-aligned, it never needs to be steered again. It has always bugged me that any steering is needed at all, it should be possible to set the phase once and be perfectly on-time from that point forward. (Perfect meaning within the measurement capabilities of the hardware, typically within about 150ns, which is certainly good enough for ntp and most PTP applications.) I'm relatively agnostic about how the ability to offset the clock is implemented, a new syscall works fine for me. I notice a struct timeval was mentioned, but hopefully that's in a context where MOD_NANO/STA_NANO apply and tv_usec will actually convey nanos? -- Ian