Date: Fri, 09 Nov 2001 13:45:18 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: freebsd-hackers@FreeBSD.ORG Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Warner Losh <imp@harmony.village.org> Subject: Re: Measuring interrupt latency Message-ID: <200111091845.fA9IjIE19568@whizzo.transsys.com> In-Reply-To: Your message of "Fri, 09 Nov 2001 10:03:11 MST." <200111091703.fA9H3B753981@harmony.village.org> References: <574.1005324178@critter.freebsd.dk> <200111091703.fA9H3B753981@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
One a related, timekeeping note: is there any interest in updating or extending the SO_TIMESTAMP socket option to return higher resolution timestamps? Currently, it returns a struct timeval. I did a quick survey, and it appears that there are applications which use this facility (though, surprisingly, not NTP despite the patch I sent off years ago). I suspect these applications would be surprised to discover a struct timespec. Also, NetBSD and OpenBSD have picked up this code and apparently Linux has a form of it as well. Based on some email from a week or two ago, I wonder if there's value in returning a timestamp in the 64.64 format that phk proposed previously, along with some additional status information. Related to the packet timestamping work I mentioned in a previous message, I added a SO_TIMESTAMP2 socket option which returned a higher resolution timestamp, along with auxilary data to identify the source of the timestamp where there might be more than one clock available, as well as some quality information (synchronized, estimated freq and phase error, etc.) If this interface was going to be extended, then it would be good to only revisit this once. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111091845.fA9IjIE19568>