Date: Wed, 13 Jan 1999 00:50:43 -0500 From: "Louis A. Mamakos" <louie@UU.NET> To: freebsd-current@FreeBSD.ORG Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, jkh@FreeBSD.ORG Subject: Re: "Louis A. Mamakos": kernel networking features contribution.. Message-ID: <8498.916206643@sayshell.corp.us.uu.net> In-Reply-To: <199812101740.SAA22071@labinfo.iet.unipi.it> References: <199812101740.SAA22071@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8498.916206643>