Re: [pfSense Support] OpenNTP
On Thu, Feb 24, 2011 at 3:22 PM, Fabian Abplanalp wrote: > Sawadeekap > > Is it possible to connect a serial DCF or GPS clock to a pfSense box, or are > the drivers missing in the OpenNTP package? Is it possible to set the > parameters "manually" in a config File? > Haven't tried it, though we do have the PPSSYNC kernel bits so it should work. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] OpenNTP
Sawadeekap Is it possible to connect a serial DCF or GPS clock to a pfSense box, or are the drivers missing in the OpenNTP package? Is it possible to set the parameters "manually" in a config File? Thanks for this great project and looking forward to RC1 :) Fabian - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] OpenNTP offset & sync
- Original Message - From: "Chris Buechler" To: Sent: Tuesday, September 07, 2010 8:05 PM Subject: Re: [pfSense Support] OpenNTP offset & sync On Thu, Sep 2, 2010 at 2:52 PM, Karl Fife wrote: We're running Embedded 1.2.3 on Soekris 5501. We ran into a funny situation last week where ntpd was failing to sync even though the stratum 1 ntp server was reachable, and the OpenNPT service was running. pfSense offset grew by about 2 seconds per day, and our ntp clients were in dutiful lockstep with this drift. Restarting the OpenNTP service didn't seem to trigger a resync, but forcing a sync from the command line did seem eliminate the (eventual) 38 second offset. However, even after the explicit resync, windows clients wouldn't sync, complaining that the time server (pfSense) had not resync'd recently enough. This message persisted even after subsequent "forced resyncs" (resyncs that resulted in <.01 sec offset correction). Later that evening (after the elves had gone home) I simply rebooted pfSense, and today it all seems to be syncing, and all of our network clocks (appliances) and windows clients seem to be syncing nicely with no complaints. Naturally I went to check the logs, but I was somewhat surprised to see that /var/log/ntpd.log was empty. Is there a different log file I should be checking? Has anyone else has seen OpenNTPD fail similarly? I've never seen my other pfSense instances drift by more than a few hundred milliseconds. We have some market traders that rely on a very reliable real time clock for market close. I'd appreciate any tips. While it generally works, openntpd tends to do stupid things at times and has a number of limitations. We've been discussing alternatives recently, looks like we'll switch back to the stock ntpd for 2.0. One time guru FreeBSD developer who is a pfSense user switched his out to the stock ntpd at his day job, a HFT company, where timing is extremely crucial. You may want to consider the same, though you'd have to manually hack it in it's not a whole lot of effort if you know FreeBSD. Thanks to all for the tips! I for one would support the move in pfSense v 2.0 to stock ntpd. For the record, a our OpenNTPD service became similarly wedged just a few months later. We rebooted pfSense a few weeks ago for some hardware maintenance despite its recency, OpenNTPD is wedged at this moment. Out of curiosity, what was the original rationale for choosing OpenNTPD? In this particular office we can probably just "revert" to running ntpd on our Asterisk server (a similarly "high availability" resource), but if it can run reliably, I would strongly prefer that pfSense function as the local time server. -K - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] OpenNTP offset & sync
On Tue, Sep 7, 2010 at 20:05, Chris Buechler wrote: > While it generally works, openntpd tends to do stupid things at times > and has a number of limitations. We've been discussing alternatives > recently, looks like we'll switch back to the stock ntpd for 2.0. One > time guru FreeBSD developer who is a pfSense user switched his out to > the stock ntpd at his day job, a HFT company, where timing is > extremely crucial. You may want to consider the same, though you'd > have to manually hack it in it's not a whole lot of effort if you know > FreeBSD. Being one of those that espoused the move, I'd love to know what things those are, for my own edification. Foolishness is only terminal if not cured. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] OpenNTP offset & sync
On Thu, Sep 2, 2010 at 2:52 PM, Karl Fife wrote: > We're running Embedded 1.2.3 on Soekris 5501. > > We ran into a funny situation last week where ntpd was failing to sync even > though the stratum 1 ntp server was reachable, and the OpenNPT service was > running. pfSense offset grew by about 2 seconds per day, and our ntp > clients were in dutiful lockstep with this drift. Restarting the OpenNTP > service didn't seem to trigger a resync, but forcing a sync from the command > line did seem eliminate the (eventual) 38 second offset. However, even > after the explicit resync, windows clients wouldn't sync, complaining that > the time server (pfSense) had not resync'd recently enough. This message > persisted even after subsequent "forced resyncs" (resyncs that resulted in > <.01 sec offset correction). > > Later that evening (after the elves had gone home) I simply rebooted > pfSense, and today it all seems to be syncing, and all of our network clocks > (appliances) and windows clients seem to be syncing nicely with no > complaints. Naturally I went to check the logs, but I was somewhat > surprised to see that /var/log/ntpd.log was empty. Is there a different log > file I should be checking? > > Has anyone else has seen OpenNTPD fail similarly? I've never seen my other > pfSense instances drift by more than a few hundred milliseconds. We have > some market traders that rely on a very reliable real time clock for market > close. I'd appreciate any tips. While it generally works, openntpd tends to do stupid things at times and has a number of limitations. We've been discussing alternatives recently, looks like we'll switch back to the stock ntpd for 2.0. One time guru FreeBSD developer who is a pfSense user switched his out to the stock ntpd at his day job, a HFT company, where timing is extremely crucial. You may want to consider the same, though you'd have to manually hack it in it's not a whole lot of effort if you know FreeBSD. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] OpenNTP offset & sync
On 02/09/10 19:52, Karl Fife wrote: did you login to try tcpdump, and use "ntpq -c lpeers" and similar? > Has anyone else has seen OpenNTPD fail similarly? I've never seen my > other pfSense instances drift by more than a few hundred milliseconds. > We have some market traders that rely on a very reliable real time clock > for market close. I'd appreciate any tips. if it matters that much, a stratum-2 clock isn't too expensive, less than US$500? http://www.google.co.uk/search?q=ntp+server+hardware - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] OpenNTP offset & sync
We're running Embedded 1.2.3 on Soekris 5501. We ran into a funny situation last week where ntpd was failing to sync even though the stratum 1 ntp server was reachable, and the OpenNPT service was running. pfSense offset grew by about 2 seconds per day, and our ntp clients were in dutiful lockstep with this drift. Restarting the OpenNTP service didn't seem to trigger a resync, but forcing a sync from the command line did seem eliminate the (eventual) 38 second offset. However, even after the explicit resync, windows clients wouldn't sync, complaining that the time server (pfSense) had not resync'd recently enough. This message persisted even after subsequent "forced resyncs" (resyncs that resulted in <.01 sec offset correction). Later that evening (after the elves had gone home) I simply rebooted pfSense, and today it all seems to be syncing, and all of our network clocks (appliances) and windows clients seem to be syncing nicely with no complaints. Naturally I went to check the logs, but I was somewhat surprised to see that /var/log/ntpd.log was empty. Is there a different log file I should be checking? Has anyone else has seen OpenNTPD fail similarly? I've never seen my other pfSense instances drift by more than a few hundred milliseconds. We have some market traders that rely on a very reliable real time clock for market close. I'd appreciate any tips. Thanks! -Karl - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
