Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
Is there anything I can do to decrease the convergence time?
Little or nothing! NTPD can, and sometimes does, take ten hours to
reach "stea
Danny Mayer wrote:
> On 11/29/2011 4:57 PM, Rich wrote:
>>
>>> Isn't that a bit wide a range to block for only 4 IPs?
>>> What makes you think any further attacks will come from the same range?
>>>
>> Only my 17 years experience at the stratum 1 level. I see little
>> value in providing NTP to A
On 11/30/2011 4:35 AM, Rob wrote:
> Danny Mayer wrote:
>> On 11/29/2011 4:57 PM, Rich wrote:
>>>
Isn't that a bit wide a range to block for only 4 IPs?
What makes you think any further attacks will come from the same range?
>>> Only my 17 years experience at the stratum 1 level. I
Danny Mayer wrote:
On 11/30/2011 4:35 AM, Rob wrote:
Danny Mayer wrote:
On 11/29/2011 4:57 PM, Rich wrote:
Isn't that a bit wide a range to block for only 4 IPs?
What makes you think any further attacks will come from the same range?
Only my 17 years experience at the stratum 1 level.
At 07:40 AM 11/30/2011, Danny Mayer wrote...
On 11/30/2011 4:35 AM, Rob wrote:
> Yes, sure. But blocking an entire region because of 4 abusers?
Yes. In this case they are not following the rules of engagement.
Sending packets from another Continent doesn't make a lot of sense in
any case.
"T
On 11/29/2011 9:21 PM, unruh wrote:
On 2011-11-29, Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
Running with an Oncore GPS& a TAPR TAC. If I "ntpdate -b" a nearby
synchronized server before I start ntpd, the offsets initially look pretty
good:
remote
Danny Mayer wrote:
> On 11/30/2011 4:35 AM, Rob wrote:
>> Danny Mayer wrote:
>>> On 11/29/2011 4:57 PM, Rich wrote:
> Isn't that a bit wide a range to block for only 4 IPs?
> What makes you think any further attacks will come from the same range?
>
Only my 17 years experienc
"David J Taylor" writes:
>> Running with an Oncore GPS & a TAPR TAC. If I "ntpdate -b" a nearby
>> synchronized server before I start ntpd, the offsets initially look
>> pretty
>> good:
>[]
>> Is there anything I can do to decrease the convergence time?
>Peter,
>Are you using a drift file, an
I am running 4.2.7p98-o and I am uncertain whether or not PPS is working.
Under windows device manager I can see drivers for the port:
Serenum.sys
Serial.sys
Serialpps.sys
Serenum.sys & Serial.sys have a green tick next to them.
In event viewer, when starting ntpd I can't see any reference to PP
Hi,
Iam facing issues with ntp broadcast in case of IPv6.
Iam using the latest ntp 4.26p3 package.
Can I have a use case scenario for ntp broadcast in IPv6?
As I see in the documentation, we can have only multicast addresses in IPv6.
Here are my configurations:
Client side:
*# Created by IMI. /e
On Tue, Nov 29, 2011 at 14:54, Mark C. Stephens wrote:
> I am running 4.2.7p98-o and I am uncertain whether or not PPS is working.
That's a relatively antique snapshot of ntp-dev. At least with more
recent ntp-dev, if PPSAPI is enabled for NMEA using flag1 1 as you
have, the NMEA refclock driver
On Nov 30, 8:42 am, mi...@flatsurface.com (Mike S) wrote:
> At 07:40 AM 11/30/2011, Danny Mayer wrote...
>
> >On 11/30/2011 4:35 AM, Rob wrote:
> > > Yes, sure. But blocking an entire region because of 4 abusers?
>
> >Yes. In this case they are not following the rules of engagement.
> >Sending pa
On Nov 30, 9:49 am, Rich wrote:
> On Nov 30, 8:42 am, mi...@flatsurface.com (Mike S) wrote:
>
>
>
>
>
>
>
>
>
> > At 07:40 AM 11/30/2011, Danny Mayer wrote...
>
> > >On 11/30/2011 4:35 AM, Rob wrote:
> > > > Yes, sure. But blocking an entire region because of 4 abusers?
>
> > >Yes. In this case
David Woolley writes:
>Richard B. Gilbert wrote:
>> On 11/29/2011 1:42 PM, Pete Ashdown wrote:
>>> +time-C.timefreq .ACTS. 1 u 19 64 377 37.887
>>> -16011. 0.122
>>> Is there anything I can do to decrease the convergence time?
>>
>> Little or nothing! NTPD can, and someti
On 30/11/2011, at 15:41, Pete Ashdown wrote:
> David Woolley writes:
>
>> Richard B. Gilbert wrote:
>>> On 11/29/2011 1:42 PM, Pete Ashdown wrote:
>
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
>
Is there anything I can do to decrease the con
On 2011-11-30, Pete Ashdown wrote:
> David Woolley writes:
>
>>Richard B. Gilbert wrote:
>>> On 11/29/2011 1:42 PM, Pete Ashdown wrote:
>
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
>
Is there anything I can do to decrease the convergence time?
>
=?utf-8?Q?Miguel_Gon=C3=A7alves?= writes:
>On 30/11/2011, at 15:41, Pete Ashdown wrote:
>> David Woolley writes:
>>
>>> Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
>>
> +time-C.timefreq .ACTS. 1 u 19 64 377 37.887
> -16011. 0.122
>>
On 2011-11-30, Rob wrote:
> Danny Mayer wrote:
>> On 11/29/2011 4:57 PM, Rich wrote:
>>>
Isn't that a bit wide a range to block for only 4 IPs?
What makes you think any further attacks will come from the same range?
>>> Only my 17 years experience at the stratum 1 level. I see li
On 2011-11-30, Pete Ashdown wrote:
> David Woolley writes:
>
>>Richard B. Gilbert wrote:
>>> On 11/29/2011 1:42 PM, Pete Ashdown wrote:
>
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
>
Is there anything I can do to decrease the convergence time?
>
unruh wrote:
> On 2011-11-30, Rob wrote:
>> Danny Mayer wrote:
>>> On 11/29/2011 4:57 PM, Rich wrote:
> Isn't that a bit wide a range to block for only 4 IPs?
> What makes you think any further attacks will come from the same range?
>
Only my 17 years experience at the str
Doug Calvert wrote:
> Pictures make every story better...
> http://tycho.usno.navy.mil/ntpplot.html
Perhaps it is my browser, but when I look a the two charts there, the
pps rates for some of the points are below 0 - they go below the
x-axis. They also go above the top of the boxes, but that mi
unruh writes:
>Uh, that is NOT the local hardware clock. That is local system clock.
>Ie, the clock you are trying to discipline with ntpd.
>Ie, you are setting the clock with itself, and so it will always have
>zero offset-- super convergence, but unfortunately not to anything even
>approximati
Richard wrote:
> I think the effect of getting rid of the drift file depends on the
> value stored in the file! If the value is reasonably close to
> correct, I think it's helpful. If you are restarting because you have
> been without power for the last three hours, the drift file is almost
> cer
Pete wrote:
> "David J Taylor" writes:
>
> >> Running with an Oncore GPS & a TAPR TAC. If I "ntpdate -b" a nearby
> >> synchronized server before I start ntpd, the offsets initially look
> >> pretty
> >> good:
> >[]
> >> Is there anything I can do to decrease the convergence time?
>
> >Peter,
Pete wrote:
> Thanks for the pointer David. I added the local hardware clock
> (127.127.1.0) to the ntp.conf and that nailed it down. Now my
> convergence is under a minute!
In general this is a bad idea. But if you have done the research and
know what you are doing, it may be OK.
H
__
Pete Ashdown wrote:
Ubuntu Linux 10.04, Kernel 3.1.0, ntp-4.2.6p5-RC1
That looks like an unstable kernel and a release candidate ntpd. I'm
not surprised that it has problems. I'm assuming that odd numbers still
indicate unstable development kernels.
_
Pete Ashdown wrote:
Thanks for the pointer David. I added the local hardware clock (127.127.1.0)
to the ntp.conf and that nailed it down. Now my convergence is under a
minute!
That's not logical and certainly not something that I would advise.
___
David Woolley writes:
>Pete Ashdown wrote:
>>
>> Ubuntu Linux 10.04, Kernel 3.1.0, ntp-4.2.6p5-RC1
>That looks like an unstable kernel and a release candidate ntpd. I'm
>not surprised that it has problems. I'm assuming that odd numbers still
>indicate unstable development kernels.
I think
David wrote:
> > Ubuntu Linux 10.04, Kernel 3.1.0, ntp-4.2.6p5-RC1
>
> That looks like an unstable kernel and a release candidate ntpd. I'm
> not surprised that it has problems. I'm assuming that odd numbers still
> indicate unstable development kernels.
4.2.6p5-RC1 is not the problem. The o
On 2011-11-30, Harlan Stenn wrote:
> Pete wrote:
>> "David J Taylor" writes:
>>
>> >> Running with an Oncore GPS & a TAPR TAC. If I "ntpdate -b" a nearby
>> >> synchronized server before I start ntpd, the offsets initially look
>> >> pretty
>> >> good:
>> >[]
>> >> Is there anything I can do t
On 11/30/2011 12:26 PM, Rob wrote:
> unruh wrote:
>> On 2011-11-30, Rob wrote:
>>> Danny Mayer wrote:
On 11/29/2011 4:57 PM, Rich wrote:
>
>> Isn't that a bit wide a range to block for only 4 IPs?
>> What makes you think any further attacks will come from the same range?
>>
On Wed, Nov 30, 2011 at 10:24:45PM +, unruh wrote:
> If he has peerstats log file, he can look at it and see what teh offset
> is of the oncore and the other ntp sources to see if it is really
> misbehaving that badly. Also, if it is out by 16 sec, why in the world
> has ntp not stepped the tim
On 2011-11-30, Miroslav Lichvar wrote:
> On Wed, Nov 30, 2011 at 10:24:45PM +, unruh wrote:
>> If he has peerstats log file, he can look at it and see what teh offset
>> is of the oncore and the other ntp sources to see if it is really
>> misbehaving that badly. Also, if it is out by 16 sec, w
On Wed, Nov 30, 2011 at 11:28:22PM +, unruh wrote:
> On 2011-11-30, Miroslav Lichvar wrote:
> > On Wed, Nov 30, 2011 at 10:24:45PM +, unruh wrote:
> >> If he has peerstats log file, he can look at it and see what teh offset
> >> is of the oncore and the other ntp sources to see if it is re
On 11/30/2011 4:28 PM, Harlan Stenn wrote:
Richard wrote:
I think the effect of getting rid of the drift file depends on the
value stored in the file! If the value is reasonably close to
correct, I think it's helpful. If you are restarting because you have
been without power for the last three
On Nov 30, 5:34 pm, Danny Mayer wrote:
> On 11/30/2011 12:26 PM, Rob wrote:
>
>
>
>
>
>
>
>
>
> > unruh wrote:
> >> On 2011-11-30, Rob wrote:
> >>> Danny Mayer wrote:
> On 11/29/2011 4:57 PM, Rich wrote:
>
> >> Isn't that a bit wide a range to block for only 4 IPs?
> >> What makes
Upgraded to
Version:Tuesday, May 11, 2010 10:22 AM 836048
ntp-4.2.7p31-win-x86-bin.zip
Result: Is the GPS_NMEA broken?
Event log: GPS_NMEA(1) 801b 8b clock_event clk_bad_format
GPS_NMEA(1) 801b 8b clock_event clk_no_reply
GPS_NMEA(1) se
Miroslav Lichvar writes:
>Would be interesting to know if this happens on every ntpd restart or
>only shortly after the GPS unit was powered up.
Every restart (that doesn't have 127.127.0.1 in the config).
___
questions mailing list
questions@lists.nt
unruh writes:
>But how could he get a 16 second offset, after starting out with a .1 s
>and 1 s offset. At 500PPM, 16 sec takes 32000 sec (10 hr) to accumulate
> which is poll interval 15. Ie, I cannot see how ntpd could have
> allowed that huge an offset to occur.
>In the posts I saw that all
On Thu, Dec 1, 2011 at 00:27, Mark C. Stephens wrote:
> Upgraded to
> Version: Tuesday, May 11, 2010 10:22 AM 836048
> ntp-4.2.7p31-win-x86-bin.zip
> Result: Is the GPS_NMEA broken?
> Event log: GPS_NMEA(1) 801b 8b clock_event clk_bad_format
> GPS_NMEA(1)
unruh writes:
>If he has peerstats log file, he can look at it and see what teh offset
>is of the oncore and the other ntp sources to see if it is really
>misbehaving that badly. Also, if it is out by 16 sec, why in the world
>has ntp not stepped the time? The threshold is 128ms.
Here is anothe
On 2011-12-01, Pete Ashdown wrote:
> Miroslav Lichvar writes:
>
>>Would be interesting to know if this happens on every ntpd restart or
>>only shortly after the GPS unit was powered up.
>
> Every restart (that doesn't have 127.127.0.1 in the config).
Does the GPS have that 1 second offset from n
42 matches
Mail list logo
