Dennis Hilberg, Jr. wrote:
[]
> The GPS time is not very accurate anyway, and can vary wildly,
> probably depending on the device, so don't expect perfect offsets. On my
> Garmin GPS 18 LVC, I use 0.190 which gets it in the ballpark,
> but can randomly jump +16ms to -10ms at any time.
With a good
David L. Mills wrote:
> 5. This flap about the speed of convergence has become silly. Most of us
> are less concerned about squeezing to the low microseconds in four
Have you done the market surveys to confirm this? I don't have the
resources or time to do that, but my impression from the sor
David J Taylor schreef:
> The fact that you have a 0.2s offset suggests you are synching to the
> trailing edge of the PPS signal and not the leading edge.
The NMEA output would be my prime suspect. It is not surprising to have
an offset there. The time in an NMEA sentence doesn't tell you what t
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Unruh,
>This answers my earlier question. I can't believe this is so crude and
>dangerous. you really need to provide an analysis on the errors this
>creates when reading the clock during the slew. The problem is not the
>residual time offset but t
OK, having looked at the code, I see what it is doing. It essentially
takes the measurement with the shortest delay in the past 8 measurements.
If that measurement happens to be the current one, it is actually used
in the clock loop. (Yes, I know this characterisation of the clock filter is
cr
"Dennis Hilberg, Jr." <[EMAIL PROTECTED]> writes:
>Jason wrote:
>> All,
>I could be wrong here, but it seems to me that your ntpd is having a hard
>time finding out the actual time, as your only source of time is nearly 2
>seconds off and varies wildly (GPS time does that, although not usually
Hal Murray <[EMAIL PROTECTED]> wrote:
>
>>On recent Linux kernels, I think the drift file is always bad after reboot.
>>HZ=100, no dynamic ticks aka tickless system (CONFIG_NO_HZ not set). I think
>>I even tried with a kernel command line option lpj= but it didn't help.
>>If the system is rebooted,
Serge Bets wrote:
: On Tuesday, January 22, 2008 at 23:13:22 +, Dean S. Messing wrote:
:
: > do "adjtimex -p" and look at the "status:" value. If it's odd,
: > (LSB==1) then your kernel is in "11 minute mode".
:
: Not exactly: bit #0 set means your kernel is in PLL mode. That's bit #6
: uns
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>> Reading your claims literally, chrony would have to slew the clock
>> considerably greater than the 500 PPM provided by the standard Unix
>> adjtime() system call. Please explain how it does that.
>
> Using the Linux adjtimex system
Richard B. Gilbert wrote:
[]
> Computer Network Time Synchronization: The Network Time Protocol by
> David L. Mills (Hardcover - Mar 24, 2006)
>
> Available from Amazon.com. You may be able to find a copy at a
> University Book store. Be prepared for "Sticker Shock". It ain't
> cheap! Publishi
Unruh wrote:
>
> The real world situation that the test is run on (not simulating) is having
I was asking about the 50ms phase hit.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>
>>David,
>
>
>>1. I have explained in very gory detail in many places how the time
>>constant is chosen for the best accuracy using typical computer
>>oscillators and network paths. See the briefings on the NTP project page
>>an
Unruh wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>> You might not have noticed a couple of crucial issues in the clock
>> filter code.
>
> I did notice them all. Thus my caveate. However throwing away 80% of the
> precious data you have seems excessive.
But it isn't really. It would
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Daivd,
>Well, I have done a market survey of sorts, if you can count my
>consulting clients. There seems general agreement that 1 ms is a good
>target, but there is a wide range of expecttions on how quickly that
>must be achieved. Actually, if the
"David L. Mills" <[EMAIL PROTECTED]> writes:
>Root,
>You could have saved a lot of time sweating the code if you looked at
>the briefings. See especially the before and after time series and note
>the 10 dB improvement in S/N.
I am sorry, but looking at the code is far simpler than trying to f
Root,
Right; 5 microseconds per timer interrupt at 100 Hz is 0.5 ms/s. That
was the original Unix kernel value.
Dave
root wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
> snip
___
questions mailing list
questions@lists.ntp.org
https://lists.nt
On Tuesday, January 22, 2008 at 23:13:22 +, Dean S. Messing wrote:
> do "adjtimex -p" and look at the "status:" value. If it's odd,
> (LSB==1) then your kernel is in "11 minute mode".
Not exactly: bit #0 set means your kernel is in PLL mode. That's bit #6
unset that means eleven-minutes mode
Hello Dean,
On Tuesday, January 22, 2008 at 19:02:23 +, Dean S. Messing wrote:
> Is it possible to disable "11 minute mode" from "ntp.conf"?
No. You have to tweak the kernel. If you have the PPSkit:
| $ echo 0 > /proc/sys/kernel/time/rtc_update
Otherwise you have to patch time.c in the ke
Petri Kaukasoina wrote:
> Basically, it stepped time with ntpdate, slept 100 seconds and stepped time
> again with ntpdate. From the time adjustment, the script calculated the
> drift value and put that to the drift file. Again, the time offset always
> stays below 1 ms.
That has quite a lot of si
Serge Bets wrote:
> On Tuesday, January 22, 2008 at 19:02:23 +, Dean S. Messing wrote:
>
> > Is it possible to disable "11 minute mode" from "ntp.conf"?
>
> No. You have to tweak the kernel. If you have the PPSkit:
>
> | $ echo 0 > /proc/sys/kernel/time/rtc_update
>
> Otherwise you have t
Brian Utterback <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>> You might not have noticed a couple of crucial issues in the clock
>>> filter code.
>>
>> I did notice them all. Thus my caveate. However throwing away 80% of the
>> precious data you h
David Woolley wrote:
> David L. Mills wrote:
>
>> 5. This flap about the speed of convergence has become silly. Most of
>> us are less concerned about squeezing to the low microseconds in four
>
>
> Have you done the market surveys to confirm this? I don't have the
> resources or time to do
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
...
>>
>> I certainly have trouble with the time constant. It is long. I means that
>> ntp responds very slowly to changes. I understand why it was chosen. But it
>> is also true that bu
David J Taylor wrote:
> Dennis Hilberg, Jr. wrote:
> []
>> The GPS time is not very accurate anyway, and can vary wildly,
>> probably depending on the device, so don't expect perfect offsets. On my
>> Garmin GPS 18 LVC, I use 0.190 which gets it in the ballpark,
>> but can randomly jump +16ms to -
Root,
You could have saved a lot of time sweating the code if you looked at
the briefings. See especially the before and after time series and note
the 10 dB improvement in S/N.
You might not have noticed a couple of crucial issues in the clock
filter code.
1. The basic principle is to select
How do you have your wiring done up? I found that when I just twisted the wire
together and wrapped them in electrical tape for testing, I had very bad serial
port behaviour. Doing a "cat /dev/gps1" I saw a lot of garbarge in stream and
I was sometimes only seeing every third or fourth NMEA se
Daivd,
Well, I have done a market survey of sorts, if you can count my
consulting clients. There seems general agreement that 1 ms is a good
target, but there is a wide range of expecttions on how quickly that
must be achieved. Actually, if the TOY chip is within 1 PPM and the
downtime is less
Danny, I agree with everything you said except:
Danny Mayer wrote:
>>
>
> I agree. I don't see how it can be a specification violation. The
> biggest factor is how well it keeps time. A caesium clock keeps good
> time but you wouldn't say that it violates the specification.
>
When we first st
Dennis Hilberg, Jr. wrote:
[]
> I was actually referring to the time emitted in the NMEA data (GPS
> time), not the PPS signal. Sorry, I should have specified that. The
> PPS is accurate to a microsecond, but not the GPS time. I happen to
> use a fudge factor of 0.190 to get the GPS time close t
David Woolley <[EMAIL PROTECTED]> writes:
>David L. Mills wrote:
>>
>> The NTP discipline is basically a type-II feedback control system. Your
>> training should recall exactly how such a loop works and how it responds
>> to a 50-ms step. Eleven seconds after NTP comes up the mitigation
>You
"David L. Mills" <[EMAIL PROTECTED]> writes:
>David,
>1. I have explained in very gory detail in many places how the time
>constant is chosen for the best accuracy using typical computer
>oscillators and network paths. See the briefings on the NTP project page
>and especially the discussion ab
Nero Imhard <[EMAIL PROTECTED]> writes:
>David J Taylor schreef:
>> The fact that you have a 0.2s offset suggests you are synching to the
>> trailing edge of the PPS signal and not the leading edge.
>The NMEA output would be my prime suspect. It is not surprising to have
>an offset there. The ti
Brian,
The 500 PPM limit in the reference implementation was originally set to
match the adjtime() slew of that value, but so many kernels have been
hacked adjtime that this might not even be appropriate now. The bottom
line is that an update given to adjtime() should be completed before the
n
33 matches
Mail list logo
