OpenBSD Journal

Support Needed for GPS and Time Signal Station Receiver Development

Contributed by mbalmer on from the uncle-bsd-wants-you dept.

As you may know, I have added support for time signal station receivers earlier this year and during the calgary hackathon I added suport for NMEA talking GPS devices. these devices can now be used by our ntpd.

Unfortunately, most devices are slightly different in the data they return or the formats they use. so it is important for me to get as much such devices as ever possible to add support for them. for economic reasons, I can not buy every single device I come across, so I much depend on donations.

If you are able to help me with my efforts by donating such devices or paying for them, please get in contact with me by private email. What I am looking for most are the following items:

  • GPS devices, serially and USB attached (consumer grade)
  • SDIO attached GPS devices (sd card)
  • industrial GPS devices, providing hich accuracy
  • GPS devices that can provide a proper per-second pulse
  • PCI based GPS receivers
  • GPS modules
  • receiver for the British MSF time signal station (Rugby)
  • High-precision correlation receiver for the german DCF77 station
  • Loran-C receiver
  • PCI based time signal station receivers

(Comments are closed)


Comments
  1. By Anonymous Coward (83.93.94.78) on

    Maybe you could supply us with an email?

    Comments
    1. By Anonymous Coward (84.187.183.9) on

      > Maybe you could supply us with an email?

      mbalmer@

  2. By Anonymous Coward (131.130.1.143) on

    - i thought nmea 0138 was standardized?
    - would it be any help to you if i borrowed you one of these devices?

    Comments
    1. By Sam Chill (68.53.205.186) on

      > - i thought nmea 0138 was standardized?
      It is a standard, but that doesn't mean it is implemented correctly on every device.

    2. By Anonymous Coward (210.233.106.4) on

      > - i thought nmea 0138 was standardized?

      Supposedly, but I believe most manufacturers add their own extensions.

  3. By threejane (84.231.225.128) undeadly@bgran.net on http://bgran.net/

    What kind of GPS devices are supported and recommended by the OpenBSD -team? I'm looking for an affordable and good GPS receiver to plug into an OpenNTPd instance to synchronize the time of that server.

    Any pointers would be appreciated.

  4. By Anonymous Coward (69.70.207.240) on

    Requests like this (to improve support and quality of other products and systems, including itself) should also be posted on slashdot to attract a wider audience (than mostly just OpenBSD people). Afterall, OpenNTP, OpenSSH, etc are portable and the more even some Linux people can help donate/support, the better for them and everyone too!

    Comments
    1. By Matthias Kilian (84.134.58.162) on

      > Afterall, OpenNTP [...] are portable

      This doesn't apply for the timedelta stuff, since it's tailored to the OpenBSD sensors framework.

  5. By RC (71.105.35.151) on

    I'm going to somewhat hijack this thread...

    The very concepts NTPD and OpenNTPD are based upon are poor ones, IMHO.

    First off, it's a big waste to so frequently query the time servers in the beginning. But mainly, after verifying servers, and synchronizing, the NTP daemons only rarely update with the servers, and if the time has desynced severely, the NTP daemons will either refuse to update to the correct (server) time, or will adjust so slowly that it may take over an hour to get back to the correct time (assuming no additional desync, which does also happen) and leaving you with incorrect timestamps that entire period of time.

    Now, I'm sure I'll get lots of people saying that they have never had this problem, and I'm sure that's true... This typically only happens when you have long-running tasks using about 100% CPU-time (in my case, a DVR). On something like my firewall, however, NTPD works fine.

    I've played around with ntp.conf options before, and put together some settings that helped quite a bit, but it was still problematic. ntpd.conf doesn't really have any options to tweak. So, the best solution I've come up with is to run ntpd on a seperate machine with consistenly low loads, and run ntpdate every minute via cron.

    So, I would strongly suggest adding some kind of check to openntpd, which would make it capable of determining if the clock is skewing between updates, and updating more frequently in those cases. As well as an option in ntpd.conf which will allow it to more quickly bring the clock back to the correct time (compiling-be-dammed). Or perhaps just being able to tweak and seriously lower the maximum interval between updates.

    Comments
    1. By Anonymous Coward (71.234.149.47) on

      > First off, it's a big waste to so frequently query the time servers in the beginning.

      Every 64 seconds for ntpd.

      > But mainly, after verifying servers, and synchronizing, the NTP daemons only rarely update with the servers,

      Every 1024 seconds for ntpd


      > and if the time has desynced severely, the NTP daemons will either refuse to update to the correct (server) time, or will adjust so slowly that it may take over an hour to get back to the correct time

      If your system "desyncs" that severely, then most likely you have other problems to worry about.


      > Now, I'm sure I'll get lots of people saying that they have never had this problem, and I'm sure that's true... This typically only happens when you have long-running tasks using about 100% CPU-time (in my case, a DVR).

      My DVR has no such issues. Maybe you should look into the DVR software to find the problem. Solve the problem, not the symptom.

      Comments
      1. By RC (71.105.35.151) on

        > My DVR has no such issues. Maybe you should look into the DVR software to find the problem.

        *Ahem*. The DVR software is a set of shell scripts I put together, nothing more. The desyncs appear to be caused whenever mencoder is long-running (at 100%).

        I can assure you there is nothing in there to be causing a desync other than high CPU-load.

        Besides, even if this isn't a typical problem, it IS enough of a problem to potentially distrust the timestamps on any server running either NTP daemon.

        Comments
        1. By Anonymous Coward (203.58.120.11) on

          > *Ahem*. The DVR software is a set of shell scripts I put
          > together, nothing more. The desyncs appear to be caused
          > whenever mencoder is long-running (at 100%).

          Then this indicates a problem that has nothing to do with ntpd.

          Comments
          1. By Jedi/Sectgor One (82.224.188.215) on

            > > *Ahem*. The DVR software is a set of shell scripts I put
            > > together, nothing more. The desyncs appear to be caused
            > > whenever mencoder is long-running (at 100%).
            >
            > Then this indicates a problem that has nothing to do with ntpd.

            Maybe renicing ntpd to a high priority can help.

          2. By RC (71.105.35.151) on

            > Then this indicates a problem that has nothing to do with ntpd.

            Absolutely wrong. The clock is not synchronized. ntpd is supposed to keep the clock synchronized. The problem is, openntpd is unable to handle anything more than trivially small desync. ntp.org's ntp daemon has a set of options which can be tweaked to make it much more able to handle the problem.

            How can any rational person say this isn't a limitation of ntpd? It's not causing the desync of course, it just isn't robust enough to handle it when one does occur.

            Since I'm apparently just wasting my breath, I guess I'll leave it at that.

            Comments
            1. By Anonymous Coward (213.196.245.215) on

              OpenNTPD (or rather, the kernel - which is at fault
              here, according to what I think, which might be wrong
              of course) doesn't help with other machines losing or
              gaining way too much time either, e.g. macppc in 2.x
              releases, or i386 in qemu (at least on my box).

              The timecounters paper does however describe one of
              the benefits as being able to fix exactly that from
              e.g. an NTP dæmon by adjusting the tick rate...
              I just hope it gets implemented someday, as I hope
              that the current adjtime offset is taken into ac-
              count when calculating the offset to replies recei-
              ved from a server, to reduce the bouncing effect.

  6. By kokamomi (83.227.181.37) on

    and i suppose that in good fashion the ones that really benefit from this work, the makers and resellers of these devices, can't be bothered?

    anyone tried? any tips for people to lean on?

  7. By Anonymous Coward (89.51.62.25) on

    Hello
    I read the man page of udcf an this is an USB device.
    Is there a plan to support dcf77 serial clocks too?

    Thank you for the information.

    Comments
    1. By Marc Balmer (213.189.137.178) on

      > I read the man page of udcf an this is an USB device.
      > Is there a plan to support dcf77 serial clocks too?

      The devices from Gude ADS that attach to the serial port are not really serial devices, the yjust provide the raw signal on the RxD line.

      To support these devices, the wiring can be changed so that the data line is connected to an interrupt generating input and a special driver needs to be written. This also means that the standard com driver for that serial port has to be disabled. That said, I doubt that such a driver can be in the GENERIC kernel. You would at least have to roll your own kernel.

      As an alternative, Gude ADS sells an adapter that let's you connect the "serial" device to the USB port. This adapter is fully supported (and tested) with udcf(4).

  8. By Alex Hafey (199.67.203.141) on

    MSF clock on the way.

Latest Articles

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.]