From owner-freebsd-current Tue Jan 12 21:51:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA13472 for freebsd-current-outgoing; Tue, 12 Jan 1999 21:51:32 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA13449; Tue, 12 Jan 1999 21:51:29 -0800 (PST) (envelope-from louie@UU.NET) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfxyd02014; Wed, 13 Jan 1999 00:50:47 -0500 (EST) Received: from sayshell.corp.us.uu.net by neserve0.uu.net with ESMTP (peer crosschecked as: sayshell.corp.us.uu.net [153.39.251.30]) id QQfxyd24530; Wed, 13 Jan 1999 00:50:43 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: freebsd-current@FreeBSD.ORG cc: Luigi Rizzo , jkh@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: "Louis A. Mamakos": kernel networking features contribution.. In-reply-to: <199812101740.SAA22071@labinfo.iet.unipi.it> References: <199812101740.SAA22071@labinfo.iet.unipi.it> Comments: In-reply-to Luigi Rizzo message dated "Thu, 10 Dec 1998 18:40:47 +0100." Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 13 Jan 1999 00:50:43 -0500 Message-ID: <8498.916206643@sayshell.corp.us.uu.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First, I'd like to repeat my request for a character major device number for the 'dtfp' device (Datum Time and Frequency Processor). I posted a request to the freebsd-current mailing list earlier, but it got lost in the flood of email over the sysctl business. I've been making some considerable progress here at UUNET on the timestamping application I described in an earlier message. To recap, the goal is to be able to measure unidirection network latency between a set of selected measurement points. Each of these measurement points has a GPS synchronized timebase and dedicated measurement hardware which is/will be a FreeBSD-based CompactPCI system with an IRIG-B timecode processor. The goal is to get end-to-end latency measurement with sub-50 to -100 microsecond accuracy. Then the interesting data reduction begins :-) The good news is that I've got approval from my management at UUNET to contribute this software to the FreeBSD project. There's an early version of the code and changes I've made available for review and comment by interested parties. When going through this to clean up some stuff, I got a idea or two to pursue that might modularize stuff a bit better than it is now. I'll likely make another major pass through the kernel code to expunge some debug code and clean up some uglies here an there and then merge with what will be the then-current FreeBSD-4.0 software. I've also got to cook up a couple of man pages. What you'll find is essentially a number of new capabilities and subsystems: - an abstraction of a 'clock source' for timestamping events. Minimally, you get one which is exactly the system clock. You can, however, have other timestamp sources with timebases that are not necessarily synchronized to the system time. - a driver for a Datum bc635PCI Time and Frequency Processor. Essentially a disciplined oscillator who's frequency is controlled by an external 1-PPS signal, IRIG-B timecode, free run, or by an optional GPS receiver. It's notion of time is enumerated in 100ns units, and can be latched with 1 register access over the PCI bus. You can also mmap() this device into user code and with read-only access get these same timestamps without making system calls. Additional work will follow in this module to allow it to be an alternative system clock (by using the timecounter abstraction I'm trying to make sure I understand), as well as reimplementing a quasi-standard API to this board similar to what the vendor supports on other bus-level products (e.g., SBUS, VME, etc.) This is as time permits. - an if_tstamp module which can be associated with one or more network interfaces. This contains a simple interface that small stubs of code in network interface drivers optionally invoke to capture a timestamp for incoming packets. The timestamp (and other status and control info) is stored in 3 32bit integers in a modified struct pkthdr inside an mbuf. In a related change, the default mbuf size was increased from 128 to 256 bytes to avoid any unfortunate side effects for protocols (e.g., PPP) that assume they have so-much space available in the first mbuf which would have been 12 bytes smaller. This module also contains a simple interface for constructing timestamps to be jammed into specially selected outgoing packets. - changes to if_ether.c in two areas: First, if timestamping has been enabled on an interface (using a modified ifconfig to specify which clock source to be used), and the device driver for the interface hasn't been modified to collect the timestamp, then it's grabbed in if_ether.c. This presumably has somewhat worse accuracy, but is better than nothing. Second, code to selectively drop a timestamp in outgoing packets. In this version of code, there's too much in if_ether.c; most of this will be moved out, back into the if_tstamp module to make it more generic and reduce duplicated code when I get around to supporting other network media. This code is probably the ugliest of all and where I've got some ideas of how to clean it up a bit. - a few modified network interface drivers to collect timestamps. There are diffs available for the kernel code at http://www-ext.eng.uu.net/TrUUeTick/tstamp-kernel-patches.txt (TrUUeTick is the internal project name that's using this stuff.) There are some trivial changes to ifconfig which allow root to enable timestamping on an interface and specify which clock source is to be used. I haven't sucked any of the non-kernel FreeBSD code into my private repository, so the diffs didn't automatically come out. This will be picked up the next time around, once I get the nerve up to try more CVS feats of acrobatics. There is one incompatible change that was made. It has to do with the operation of the SO_TIMESTAMP option. Currently, when SO_TIMESTAMP is enabled on a SOCK_DGRAM socket, you can receive an SCM_TIMESTAMP control message using recvmsg() that contains a struct timeval. The change that was made is to return a datastructure with additional information beyond just the time, and to return the time as a struct timespec. I didn't want to introduce a new socket option as to my knowledge, I'm probably the only person that's every written code that uses this socket option and I'm the original author of the kernel code that actually implements it. If there are strong feeling that this existing API not be disturbed, then it's a simple matter to add another socket option. So: my plan is to submit this work in a few weeks to be intergrated into FreeBSD, probably post-3.1 split. I'll merge in the changes to -current between now and then and push out diffs. They'll hopefully be something in the way of man pages. There will also be some changes to ifconfig, and perhaps a sample program or two. It's unlikely that the applications that I'll develop to use this stuff, or the data reduction stuff will be able to be contributed, but I think there will be some useful capability in here. -- Louis A. Mamakos louie@UU.NET Director, Global Strategic Technology UUNET, an MCI WorldCom Company Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 206 5601 Fairfax, VA 22031-4648 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message