David Lord writes:
> Do logs indicate a config problem?
>
> system server1: MSFa, PPSa peer=server2 and remote servers
> system server2: peer=server1 and remote servers
> system server3: GPSb, PPSb, server2 and server1
>
>
> This is total logged over period Feb 7 to Feb 12:
> ntp.log.server
Lei Wang writes:
> Hi,
>
> I did some measurement using NTP with Linux RTAI. The measurement is
> conducted using a GPS hooked up through serial port to the PC and using the
> 1PPS of the GPS to trigger an ISR to read both the TSC counter and TSC
> counter scaled to nanoseconds. The TSC counte
"Russell, David" writes:
> I have seen several comments saying that the NIC card in an NTP client can
> make a difference in how well NTP will perform.
>
> My servers are Dells running RedHat.
>
> Does anyone have any recommendations for a particularly good NIC card for
> Gigabit speeds? I am
>I think you mean that you have a 1PPS source that is synchronized to
>DCF-77 but does not send the actual received DCF-77 signal.
>In that case it should be OK to use it to increment a clock.
No, it really is a DCF-77 signal.
>However, when you have expectations that you can control what source
Ulrich Windl wrote:
David Lord writes:
Do logs indicate a config problem?
system server1: MSFa, PPSa peer=server2 and remote servers
system server2: peer=server1 and remote servers
system server3: GPSb, PPSb, server2 and server1
This is total logged over period Feb 7 to Feb 12:
ntp.lo
>> Sorry, i forgot to mention an important thing:
>> The DCF-77 Signal is generated by a precise clock that is connected via
>> fiber optics to the device the ntpd runs at.
>> The distance isn't very long, so i can expect that the signal is very
>> precisely and there is no jitter nor any (relevan
Matuschka, Sebastian wrote:
>
>>I think you mean that you have a 1PPS source that is synchronized to
>>DCF-77 but does not send the actual received DCF-77 signal.
>>In that case it should be OK to use it to increment a clock.
>
> No, it really is a DCF-77 signal.
>
>>However, when you have expecta
Matuschka, Sebastian writes:
> No, it really is a DCF-77 signal.
But earlier you wrote:
> The DCF-77 Signal is generated by a precise clock that is connected
> via fiber optics to the device the ntpd runs at. The distance isn't
> very long, so i can expect that the signal is very precisely and th
Matuschka, Sebastian wrote:
>>You are also still hiding stuff and expecting us to guess.
> That's absolutely not my intention. I just want to write only the things that
> are relevant, so people don't have to read so much they decide to not read it
> at all.
> What could be of intereset for you?
Sebastian writes:
> The reason i want to switch very soon to another source when DCF77
> signal is lost, is that I have to tell a FPGA when it should use the
> DCF77 signal and when to use an alternative source. The FPGA doesn't
> decodes the time but it uses the DCF77 signal to increment its
> int
On Jul 16, 1:56 am, "David J Taylor" wrote:
> > Is there a maximum fudge value above which the NMEA refclock throws
> > away input? Both my 18xLVC GPS receivers output serial data about 550
> > ms after the PPS signal. That works fine with gpsd, but I've been
> > trying to set up the NMEA driver w
"jimmyterrence" wrote in message
news:1c01938f-d43e-4dea-a143-45e096d31...@j8g2000yqd.googlegroups.com...
[]
If it was triggering on the wrong edge of the pps signal, wouldn't it
be off of the rest of the servers by the length of the pulse? I think
that it's triggering properly.
Agreed.
M
Ulrich,
From context I suspect Linux has incorporated the PPS kernel discipline
code I wrote in the 1990s. That code has several provisions to groom
noisy PPS signals, including a median filter, popcorn spike suppressor
and range gate. Apparently, the PPS signal in this case is very noisy
and
On 2010-07-16, Matuschka, Sebastian
wrote:
>
>>> Sorry, i forgot to mention an important thing:
>>> The DCF-77 Signal is generated by a precise clock that is connected via
>>> fiber optics to the device the ntpd runs at.
>>> The distance isn't very long, so i can expect that the signal is very
>>
On 2010-07-16, Matuschka, Sebastian
wrote:
>
>>I think you mean that you have a 1PPS source that is synchronized to
>>DCF-77 but does not send the actual received DCF-77 signal.
>>In that case it should be OK to use it to increment a clock.
>
> No, it really is a DCF-77 signal.
Uh, why don't you
On Jul 16, 9:45 am, "David J Taylor" wrote:
> "jimmyterrence" wrote in message
>
> news:1c01938f-d43e-4dea-a143-45e096d31...@j8g2000yqd.googlegroups.com...
> []
>
> > If it was triggering on the wrong edge of the pps signal, wouldn't it
> > be off of the rest of the servers by the length of the p
This thread has been dormant for more than 7 months!
Ulrich Windl wrote:
kjans writes:
There seems to be several possibilities:
- delay or offset or jitter (from ntpq -clpeers)
Does not include systematic error.
- sync distance (from ntptrace)
Extremely pessimistic.
- ma
David Lord wrote:
16 July
09:56:27 ntpd exiting
09:56:39 clock PPS(2) event clk_noreply
10:01:01 synch to GPS_NMEA(2), stratum 0
10:01:01 kernel time sync status change 0x2101
10:02:02 kernel time sync status change 0x2107
10:02:17 synchronized to PPS(2), stratum 0
and "ntpq -p" gives PPS(2) of
>I created a symlink called gps0 to my serial port ttyS0, because it
>told me that in the logs when I tried to start up ntpd without it.
>
>Can somebody who uses the NMEA driver in linux tell me if there is
>something else that I should have compiled in? gpsd works fine, but
>every time I switch t
19 matches
Mail list logo
