OpenBSD Journal

[c2k8]: Hackathon Summary Part 9

Contributed by mtu on from the olympic-mania-is-over-now-back-to-c2k8 dept.

c2k8 General Hackathon (Part 9) - June 7-15, 2008, Edmonton, Alberta, Canada

Thanks to Henning Brauer (henning@) and others, we have reliable and a good enough for jazz means of keeping time in OpenBSD. When you are querying 8 public stratum 2 servers from a random pool from pool.ntp.org, you might have one lie to you but not all eight. It is another example of OpenBSD's systems approach to doing things. Eliminate any single point of failure whenever possible. Yet, there are two individuals who took time keeping to the next level of go anywhere and get time and position.

henning

Read on to learn more about OpenBSD's approach to time and position:

marc and theo

When I think of precision time and a long history of time keeping devices, I think of Switzerland. So does it surprise you that a Swiss OpenBSD developer, Marc Balmer (mbalmer@), spends a lot of his energy in this area? In fact, he has spent a considerable amount of time working on OpenBSD time in novel ways, especially for a non-Real-time Operating System. He highlights this work on support for Radio Clocks in OpenBSD here.

Marc also runs a very successful company, micro systems that supports OpenBSD systems in Switzerland. He is also very busy helping to organise and run several conferences every year.

Here is what Marc had to say about his time at the c2k8 hackathon:

For the first time I came to a hackathon with a whole list of items to work on. The list, however, was so long that the hackathon would have to last for three months and not only one week... Nevertheless I was able to shorten my list a bit. I extended ldattach(8) to make it usable with other applications that need GPS data, removed nmeaattach(8), and added accelerated X support for the AMD Geode LX graphics processor.

I will only talk about the first item here, since I think it is a good example of how software evolves when people using it for different purposes work together.

When I first wrote the nmea(4) line discipline to decode GPS data and use it as a precise time reference, I needed a way to attach the line discipline to a tty. Line disciplines are quite different from device drivers and the tty subsystem has quite some subtleties that you have to think of. Not only do you have the tty/cua difference, which is very important to understand, but also the fact, that a file descriptor must be open on a tty device for data to flow and the line discipline to be active. The program that attaches the line discipline thus must open a file descriptor on the device the GPS unit is plugged in AND keep that filedescriptor open. Unfortunately that also means that no other process can look at the GPS data; a tty can only be opened by one process. While we get precise time information, the data from the GPS is otherwise lost, quite frustrating if you want time and position data.

gpsd is such an application (it is in our ports tree) and I am actually using it myself, since I wrote some graphical GPS applications. Fortunately the main gpsd developer is also an OpenBSD developer, Chris Kuethe, and he modified gpsd to attach the line discipline from within gpsd. This is, of course, completely OS dependent and no other OS has the nmea(4) line discipline, afaik. Chris asked me long before the hackathon to find a better solution to the problem, so that the OpenBSD specific code could be ripped out of gpsd again.

Inspired by a nice hack I saw in a bluetooth utility, I suggested to Chris that ldattach, the small program that attaches the line discipline and then just keeps the filedescriptor open, should be extended to actually read the data from the GPS unit and pass it on a pty(4) device. ptys always come in pairs, so while ldattach feeds the data to its end of the pair, any application can open the other end and use the GPS data for whatever task.

Chris, being a perfectionist and a GPS expert, was not yet satisfied with that approach although he liked the concept of data being passed over a pty. But he wanted it bi-directional: "after all I have to talk to my GPSes to configure them". And that is how it got implemented in the end.

If you pass the -p option to ldattach, it will open a pty pair and relay data between the GPS unit and the pty in both directions. gpsd can use the GPS unit as if it was directly connected and the kernel still picks up the precise time information and feeds that to ntpd. ldattach will output the name of the pty so that gpsd can be started with a command line like 'gpsd `ldattach -p cuaU0`'.

- Marc Balmer

ckuethe

Besides working on GPS support for OpenBSD, Chris Kuethe (ckuethe@) seems to enjoy speed. Last year I was able to watch him drive his not-so-stock BMW 3 series through some remote Canadian mountain highways as if he was on the famous Nürburgring race track :-). No, I wasn't with him but I was able to watch it on his Sony PSP at Pacsec 2007. He recorded the ride via a camcorder that he fixed to the side of his car. It would have been more exciting for me if I was in the driver's seat but maybe not in his car.

About a week just before the c2k8 hackathon, returning from some company event, he was dropping off a co-worker and was backing out of the driveway when one of his wheels came right off the axle. Essentially, it broke from years of wear and tear and perhaps a little fatigue from being run so hard ;-). Thank goodness this didn't happen on the highway.

At c2k8, Chris showed me some really cool stuff that he is doing with OpenBSD and GPS. If I recall correctly, he is tracking the position of any and all GPS satellites within direct view of his home. He also graphs them real-time (or almost) showing approximate strength and distance relative to his home. It was quite fascinating.

Here is what Chris had to say about his work and time at the c2k8 hackathon:

I helped out a bit with testing things:

  • setting up a test harness for henning and mcbride's pf changes
  • applying actual load to cryptoraid by running it on my production laptop
  • mbalmer's ldattach-with-pty-relay code
  • The main thing I wanted to work on was a better control loop in ntpd.

    Readers of ports@ and source-changes@ might have also noticed that I've become interested in usb lcd display panels - so I wrote up an ugly little monitor program to watch the status of my gps (and ldattach), ntpd and my clock control loops and display this all on the little lcd. A port of the control library is in the works.

    CK

    I would like to thank both Marc and Chris for giving us a unique way of keeping time without Internet ;-).

    (c2k8 hackathon summary to be continued)

    (Comments are closed)


    Comments
    1. By Anonymous Coward (60.241.195.155) on


      Whoohoo 1st Post ! :) , yet another excellent report from Mark, well done !!

    2. By Anonymous Coward (219.90.185.9) on

      Would someone be kind enough to explain what exactly is meant by the term "line discipline"?

      Comments
      1. By Anonymous Coward (87.198.171.83) on

        > Would someone be kind enough to explain what exactly is meant by the term "line discipline"?
        Line Discipline Explained

    3. By Anonymous Coward (167.247.219.10) on

      thank you for another great article, mark. i'm sure that there are a lot
      of lurkers out there like me.

      come on guys! show the love.

    Credits

    Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]