Measuring Time on Serial Port Events

M. Warner Losh imp at bsdimp.com
Tue Jan 13 21:33:13 PST 2004


In message: <20040113211641.GA99925 at blossom.cjclark.org>
            "Crist J. Clark" <cristjc at comcast.net> writes:
: I'm doing some work involving measuring latencies of communications
: over serial ports. To avoid clock synchronizations issues if we were
: running on separate machines, a configuration is a modem hooked into
: /dev/cuaa0 and another in /dev/cuaa1. We talk to the modem on cuaa0
: which calls the modem on cuaa1, we tell it to answer, and then we
: throw data back and forth and take timestamps.
: 
: Right now, all of the code is running in userland.
: 
: I am trying to figure out what tuning we could do to get things as
: accurate as possible. That is, the information we want is the time
: that a bunch of bits to leave the COM port versus when they arrive on
: the other one. Since things look more like,
: 
:    Userland    |    OS      | Comms Hardware |
:                |            |                |
:  [measuring]<->|<-[ sio  ]->|<---- UART ---->|<------->
:  [ program ]   |  [driver]  |                |
: 
: And this doesn't account for delays between when we get the data in
: userland and then have to make gettimeofday() calls for timestamps and
: other potential delays.

The sio driver batches characters up.  You get new characters only
once every HZ.  You can reduce the amount of latency by using a higher
HZ.  You also have a few character times of latency on top of that due
to the FIFOs.  sio is optimized for data movement and few interrupts,
not for low latency between character arrival and userland.

: I'm concerned how far off our measurements in userland will be from
: when bits actually arrive and leave on the wire. The data we are
: concerned with has latencies of a few 100 ms, but calibrations on the
: PSTN are a typically 50-ms-ish. We need to have a few significant
: digits below that.
: 
: Any pointers?

Make HZ 5000 or something like that.  If it is critical that you get
things down to a few microseconds, chances are you may need to hack
your own driver together...

Warner


More information about the freebsd-hackers mailing list