John Ackermann N8UR wrote:
>> Further to the news today that the solar flare on Dec. 5/6, 2006
>> caused GPS disruption, it just so happens I was logging the signal
>> strength (average of all satellites tracked) of an M12+T timing
>> receiver at that time. For what it's worth, the attached plot s
>>> In article <[EMAIL PROTECTED]>, Spoon <[EMAIL PROTECTED]> writes:
Spoon> Harlan Stenn wrote:
>> Are you using iburst?
Spoon> Yes.
>> Do you have good values in your ntp.drift files?
Spoon> No!
Spoon> cf. thread titled "Clock skew changes drastically between reboots"
Spoon> On the systems
>Why did you remove the drift file? It is there to provide some
>state when restarting ntpd.
The glitch he is chasing involves bogus info in the drift file.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing
>I've noticed something I find very strange on the systems I have to work
>with. Every time I reboot the computer, the clock skew of the local
>clock changes, sometimes by what seems to be a huge amount.
>
>For example, I boot the computer, let ntpd run for 12 hours, and the
>value recorded in the
Further to the news today that the solar flare on Dec. 5/6, 2006 caused
GPS disruption, it just so happens I was logging the signal strength
(average of all satellites tracked) of an M12+T timing receiver at that
time. For what it's worth, the attached plot shows what I saw. This
was the only sig
>I'll try to explain my situation in detail.
>
>Consider two systems, A and B.
>
>A sends ~1000 UDP packets per second to B.
>
>A timestamps each packet.
>
>These packets travel over an IP network, and suffer delay and jitter.
>
>B is supposed to re-send the packets it receives at the rate they
>we
>Do you really need to reboot? Microsoft is the only vendor of Operating
>Systems that seem to require regular reboots. Most, if not all, of the
>others seem to be able to run for weeks, months or years between reboots.
Laptops reboot fairly often. There are probably other cases
where saving
Ryan Malayter wrote:
> On Apr 5, 9:35 am, [EMAIL PROTECTED] wrote:
>
>>Computer clocks drifting is going to be the least of the worries
>>if there is ever an extended and wide spread GPS outage.
>
>
> I would imagine there are some truly critical applications out there
> that rely on accurate ti
Ryan Malayter <[EMAIL PROTECTED]> wrote:
> On Apr 5, 9:35 am, [EMAIL PROTECTED] wrote:
> > Computer clocks drifting is going to be the least of the worries
> > if there is ever an extended and wide spread GPS outage.
> Airplanes/ships have intertial and radio navigation aids to backup
> GPS. Car
I recently added my Soekris (with the CHU ref-clock), named "ntp0" to
my orphan pool. At first ntp0 was synced to CHU and the other orphans
dropped off ntp0's peer billboard. Then, this morning, the CHU refclock
was deselected (due to reception problems) and the other orphan pool
members were once
[find the drift]
>The problem with that solution is that the frequency offset of the
>system clock changes by a huge amount every time the system reboots.
That's a bug/glitch in the kernel.
I'm chasing that one in a Linux 2.6 kernel on Intel CPUs.
More info in other threads if/when I get some.
Marc Brett <[EMAIL PROTECTED]> wrote:
> Second, the December 6 event dramatically shows the effect of solar
> radio bursts is global and instantaneous.
Instantaneous? I thought it took at least 8 minutes for something
happening at the Sun to become "visible" near Earth?
rick jones
--
portable a
"Spoon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Maarten Wiltink wrote:
>> [...] could you monitor the buffer length and adjust frequency
>> on system B from that? If it's slowly draining, slow down B a little;
>> if it's growing, speed it up ever so slightly. Just like NTP do
On Apr 5, 9:35 am, [EMAIL PROTECTED] wrote:
> Computer clocks drifting is going to be the least of the worries
> if there is ever an extended and wide spread GPS outage.
I would imagine there are some truly critical applications out there
that rely on accurate time from NTP. And any critical appli
Spoon wrote:
> Hans Jørgen Jakobsen wrote:
>
>> Spoon wrote:
>>
>>> Consider two systems, A and B.
>>>
>>> A sends ~1000 UDP packets per second to B.
>>>
>>> A timestamps each packet.
>>>
>>> These packets travel over an IP network, and suffer delay and jitter.
>>>
>>> B is supposed to re-send the
Harlan Stenn wrote:
> Are you using iburst?
Yes.
> Do you have good values in your ntp.drift files?
No!
cf. thread titled "Clock skew changes drastically between reboots"
On the systems I have to work with, ntpd finds a different frequency
offset every time. There is no "good" value for the
Hans Jørgen Jakobsen wrote:
> Spoon wrote:
>
>> Consider two systems, A and B.
>>
>> A sends ~1000 UDP packets per second to B.
>>
>> A timestamps each packet.
>>
>> These packets travel over an IP network, and suffer delay and jitter.
>>
>> B is supposed to re-send the packets it receives at the
Spoon wrote:
> Richard B. gilbert wrote:
>
>> Spoon wrote:
>>
>>> Richard B. gilbert wrote:
>>>
Spoon wrote:
> I've read this page:
> http://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP
> which explains how to let NTP determine the frequency offset (skew).
>
>>> In article <[EMAIL PROTECTED]>, Spoon <[EMAIL PROTECTED]> writes:
Spoon> Harlan Stenn wrote:
>> Good catch. I've updated the DeprecatingNtpdate page.
Spoon> Is it possible to specify "tinker step x" on the command line?
No, but you can have 2 ntp.conf files, one that has it and one that doe
Are you using iburst? Do you have good values in your ntp.drift files?
The other approach may be to get a good PPS signal distributed to all your
machines.
H
___
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/list
Maarten Wiltink wrote:
> Spoon wrote:
>
>> B is supposed to re-send the packets it receives at the rate they
>> were originally sent by A.
>>
>> If the clocks on A and B do not tick at the same rate, the buffer
>> used by B will either overflow or underflow.
>>
>> This is why I need A's clock a
Richard B. gilbert wrote:
> Spoon wrote:
>
>> Richard B. gilbert wrote:
>>
>>> Spoon wrote:
>>>
I've read this page:
http://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP
which explains how to let NTP determine the frequency offset (skew).
I have a strange
Thanks for the answers.
I'm dropping the local system clock as the server for the non-master
nodes.
The master node can have as many external time servers as desired. I
listed just one to simplify the ntp.conf in my posting.
DD
___
questions mailing li
Harlan Stenn wrote:
> Good catch. I've updated the DeprecatingNtpdate page.
Is it possible to specify "tinker step x" on the command line?
___
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions
Ryan Malayter <[EMAIL PROTECTED]> wrote:
> .
> On Apr 5, 5:12 am, Marc Brett <[EMAIL PROTECTED]> wrote:
> > Was NTP affected by this?
> I'd imagine that brief interruptions in GPS signals would affect some
> stratum-1 severs, but their peering arrangements and drift files
> should as a fallback t
Serge Bets wrote:
> Spoon wrote:
>
>> I've configured one box to serve its local clock to another box.
>> (I want them to drift together.)
>
> First of all: Do you really want one master server and a slave client,
> or don't you care which is master? In the later case, you could drop
> LOCAL(1)
___
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions
Was NTP affected by this?
http://www.noaanews.noaa.gov/stories2007/s2831.htm
During an unprecedented solar eruption last December, researchers at Cornell
University confirmed solar radio bursts can have a serious impact on the Global
Positioning System (GPS) and other communication technologies
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> And a few minutes later ...
Where a few minutes will be the very approximately 15 minutes needed to
verify a step change. If the local clock is the first one to become
reachable, it will lock onto that and then require the full brok
On 4 Apr 2007, at 16:28, Chris Cox wrote:
> I'd like to know something like this: If we assume the servers are
> reasonably accurate, and state the statistics of the network jitter
> and the
> behaviour of the client oscillator, and control the clock using NTP
> over the
> network, what frequ
In article <[EMAIL PROTECTED]>,
Richard B. gilbert <[EMAIL PROTECTED]> wrote:
> It's a little less than clear what you hoped to accomplish by this and
Making gross changes to the clock on a running machine is how people
think they can test that ntpd is synchronising the clock, when what they
sho
31 matches
Mail list logo
