Contributed by mbalmer on from the uncle-bsd-wants-you dept.
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)
By Anonymous Coward (83.93.94.78) on
Comments
By Anonymous Coward (84.187.183.9) on
mbalmer@
By Anonymous Coward (131.130.1.143) on
- would it be any help to you if i borrowed you one of these devices?
Comments
By Sam Chill (68.53.205.186) on
It is a standard, but that doesn't mean it is implemented correctly on every device.
By Anonymous Coward (210.233.106.4) on
Supposedly, but I believe most manufacturers add their own extensions.
By threejane (84.231.225.128) undeadly@bgran.net on http://bgran.net/
Any pointers would be appreciated.
By Anonymous Coward (69.70.207.240) on
Comments
By Matthias Kilian (84.134.58.162) on
This doesn't apply for the timedelta stuff, since it's tailored to the OpenBSD sensors framework.
By RC (71.105.35.151) on
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
By Anonymous Coward (71.234.149.47) on
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
By RC (71.105.35.151) 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%).
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
By Anonymous Coward (203.58.120.11) on
> 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
By Jedi/Sectgor One (82.224.188.215) on
> > 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.
By RC (71.105.35.151) on
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
By Anonymous Coward (213.196.245.215) on
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.
By kokamomi (83.227.181.37) on
anyone tried? any tips for people to lean on?
By Anonymous Coward (89.51.62.25) on
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
By Marc Balmer (213.189.137.178) on
> 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).
By Alex Hafey (199.67.203.141) on