On 2013-04-02, David Woolley wrote:
> unruh wrote:
>
>> needs to remember only the last couple of measurements. It is a Markovian
>> process.
>>
>
> Which is s statistics term. The biggest difference between chrony and
> ntpd, is that chrony seems to have been designed using statistics
> algo
unruh wrote:
needs to remember only the last couple of measurements. It is a Markovian
process.
Which is s statistics term. The biggest difference between chrony and
ntpd, is that chrony seems to have been designed using statistics
algorithms (linear filters), and ntpd using engineering o
On 2013-04-01, David Woolley wrote:
> unruh wrote:
>
>>
>> Well, modulo Mills' prejudices as to how ntpd should work. In short, if
>> the user has different requirements from those that Mills had, there may
>> be a way of using the data differently to get better results. But you
>> really really
On 2013-04-01, David Woolley wrote:
> unruh wrote:
>
>> ntpd only uses two points of history-- the last measurement used and teh
>> current one. But it slowly adjusts the clock. If the offset is there, it
>
> However, it is affected by infinitely many points, even though they are
> all wrapped up
Woolley wrote:> Mischanko, Edward T wrote:
>> What can be done with ntpd's code to address the lack of
>> speed in ramping down the time constant as needed to keep
>> up with changes in the local clock?
>
> The problem is that it only sees the effects and doesn't
> know the cause.
> To really
unruh wrote:
ntpd only uses two points of history-- the last measurement used and teh
current one. But it slowly adjusts the clock. If the offset is there, it
However, it is affected by infinitely many points, even though they are
all wrapped up into the phase and frequency of the local clock
unruh wrote:
Well, modulo Mills' prejudices as to how ntpd should work. In short, if
the user has different requirements from those that Mills had, there may
be a way of using the data differently to get better results. But you
really really have to know what you are doing.
As the OP mentione
On 2013-03-30, Claudio Carbone wrote:
> Thank you to those who answered, I'm learning a great deal about network
> time compensation.
>
>
> On 30/03/13 07:55, David Taylor wrote:
>> Claudio,
>>
>> I offer you three monitoring techniques - two programs and MRTG. The
>> programs are listed here:
>
On 2013-03-30, Mischanko, Edward T wrote:
> What can be done with ntpd's code to address the lack of speed in ramping
> down the time constant as needed to keep up with changes in the local clock?
Rewrite the code.
Run chrony instead ( which responds much faster).
>
>> You are observing on a t
On 2013-03-29, Claudio Carbone wrote:
> On 29/03/13 19:26, Brian Utterback wrote:
>> As unruh said, if there was a way to improve the accuracy of the
>> measurement over the network like that, NTP would already be doing it.
>
> If so why doesn't the offset oscillate?
> If NTP were a real compensa
On 2013-03-30, David Woolley wrote:
> Mischanko, Edward T wrote:
>> What can be done with ntpd's code to address the lack of speed in ramping
>> down the time constant as needed to keep up with changes in the local clock?
>>
>
> The problem is that it only sees the effects and doesn't know the ca
On 2013-03-29, Brian Utterback wrote:
> On 3/29/2013 1:26 PM, Claudio Carbone wrote:
>> I mean that, when I have certain timings from different machines, if I
>> correct them by their average offset from a common source, doesn't
>> this augment the precision of the measure?
>> I'm using a single
On 2013-03-29, Claudio Carbone wrote:
> On 29/03/13 18:04, David Woolley wrote:
>> Single PPS source with equal length cables to each machine.
> Impossible.
> Machines are moving robots, and we operate indoor.
Well, equal depends on your requirements. Thus, equal could mean 300km
difference if yo
I wrote:
> BTW what kind of accuracy do you need and how quickly must your machines
> converge to it? Ntpd may not be your best choice. It's designed to
> synchronize always-on machines with relatively low drift rates over the
> Internet.
Claudio writes:
> That depends entirely on the performan
On 3/30/2013 09:47, David Woolley wrote:
Claudio Carbone wrote:
That depends entirely on the performance of the communication
framework we are using.
Which is what I'm trying to measure.
That's your basic problem: you are trying to measure with a mechanism
that is subject to the parameters
Claudio Carbone wrote:
That depends entirely on the performance of the communication framework
we are using.
Which is what I'm trying to measure.
That's your basic problem: you are trying to measure with a mechanism
that is subject to the parameters you are trying to measure!
I'm open
John Hasler wrote:
converge to it? Ntpd may not be your best choice. It's designed to
synchronize always-on machines with relatively low drift rates over the
Internet.
It can cope with high drift rates, it is higher derivatives that can be
a problem.
__
On 30/03/13 13:43, John Hasler wrote:
BTW what kind of accuracy do you need and how quickly must your machines
converge to it? Ntpd may not be your best choice. It's designed to
synchronize always-on machines with relatively low drift rates over the
Internet.
That depends entirely on the perf
Claudio writes:
> Then why does NTP give a number to the offset and delay?
Because the information is often useful. You can use it to evaluate
performance. The name may be a bit misleading. It isn't the actual
instantaneous offset: you can never know that.
> If the algorithm knows that it's la
On 30/03/2013 11:22, Claudio Carbone wrote:
[]
Thank you David, I had already spotted your site in another message to
this list/ng, unfortunately I work under linux, so can't use your
programs. But it was really interesting none the less.
[]
Have all a nice Easter holiday.
Claudio
I'm please
Claudio Carbone wrote:
why should a well-designed compensation system keep lagging or leading
to avoid ringing?
It ultimately boils down to the relevance of the amplitude of the error.
I think in my case ringing would not be relevant, while lenghty
leading/lagging would.
Some of this is due
Claudio Carbone wrote:
If the algorithm knows that it's lagging by X s, why doesn't it correct
for that lag?
Because it assumes the error is in the measurement, not in the local
clock, as it assumes that local clocks can't drift off that fast, once
initial lock has been achieved.
As you ar
On 30/03/13 12:22, Claudio Carbone wrote:
Sure but a well-designed compensation system should also keep lagging
or leading to avoid oscillation.
I meant:
why should a well-designed compensation system keep lagging or leading
to avoid ringing?
It ultimately boils down to the relevance of the
Thank you to those who answered, I'm learning a great deal about network
time compensation.
On 30/03/13 07:55, David Taylor wrote:
Claudio,
I offer you three monitoring techniques - two programs and MRTG. The
programs are listed here:
Thank you David, I had already spotted your site in ano
Mischanko, Edward T wrote:
What can be done with ntpd's code to address the lack of speed in ramping
down the time constant as needed to keep up with changes in the local clock?
The problem is that it only sees the effects and doesn't know the cause.
To really speed it up, you would need to,
On 28/03/2013 18:16, Claudio Carbone wrote:
Hello.
I'm new to NTP and my needs aren't really rooted in the mechanism of
synchronization and time seeding.
[]
Thank you very much.
Best regards
Claudio
Claudio,
I offer you three monitoring techniques - two programs and MRTG. The
programs ar
What can be done with ntpd's code to address the lack of speed in ramping
down the time constant as needed to keep up with changes in the local clock?
> You are observing on a time scale much shorter than the loop time
> constant. ntpd has an adaptive time constant, and once it has gained
> initi
On 3/29/2013 3:27 PM, Claudio Carbone wrote:
On 29/03/13 19:26, Brian Utterback wrote:
As unruh said, if there was a way to improve the accuracy of the
measurement over the network like that, NTP would already be doing it.
If so why doesn't the offset oscillate?
If NTP were a real compensation
Claudio Carbone wrote:
On 29/03/13 19:26, Brian Utterback wrote:
As unruh said, if there was a way to improve the accuracy of the
measurement over the network like that, NTP would already be doing it.
If so why doesn't the offset oscillate?
If NTP were a real compensation system, it should osc
Claudio Carbone wrote:
On 29/03/13 19:26, Brian Utterback wrote:
As unruh said, if there was a way to improve the accuracy of the
measurement over the network like that, NTP would already be doing it.
If so why doesn't the offset oscillate?
If NTP were a real compensation system, it should osc
On 03/29/13 15:27, Claudio Carbone wrote:
On 29/03/13 19:26, Brian Utterback wrote:
As unruh said, if there was a way to improve the accuracy of the
measurement over the network like that, NTP would already be doing it.
If so why doesn't the offset oscillate?
If NTP were a real compensation sy
Claudio Carbone wrote:
> I mean that, when I have certain timings from different machines, if I
> correct them by their average offset from a common source, doesn't this
> augment the precision of the measure?
NTP has already used the offset to correct the system clock. You don't
need or want to
On Mar 29, 2013, at 12:27 PM, Claudio Carbone wrote:
> On 29/03/13 19:26, Brian Utterback wrote:
>> As unruh said, if there was a way to improve the accuracy of the measurement
>> over the network like that, NTP would already be doing it.
>
> If so why doesn't the offset oscillate?
It usually do
On 29/03/13 19:26, Brian Utterback wrote:
As unruh said, if there was a way to improve the accuracy of the
measurement over the network like that, NTP would already be doing it.
If so why doesn't the offset oscillate?
If NTP were a real compensation system, it should oscillate around the
setpo
On 3/29/2013 1:26 PM, Claudio Carbone wrote:
I mean that, when I have certain timings from different machines, if I
correct them by their average offset from a common source, doesn't
this augment the precision of the measure?
I'm using a single external source to compare all other clocks.
In
On 2013-03-29, Claudio Carbone wrote:
> On 29/03/13 16:59, unruh wrote:
>> I have no idea what you want to do-- your description just left me
>> confused, but perhaps the above may allow you to decide if the ntp
>> protocol might be useful to you.
>
> I have a network of machines with a master ser
On 29/03/13 18:04, David Woolley wrote:
Single PPS source with equal length cables to each machine.
Impossible.
Machines are moving robots, and we operate indoor.
If the clocks are already synchronised by NTP, none of these will give
you a better time; all they will do is given you an idea o
Claudio Carbone wrote:
To do this ideally I should have a single clock, but that is plainly
impossible.
Single PPS source with equal length cables to each machine.
So the next best thing is to use the single machines kernel clocks
corrected with the NTP data.
But to do this I need to perio
On 29/03/13 16:59, unruh wrote:
I have no idea what you want to do-- your description just left me
confused, but perhaps the above may allow you to decide if the ntp
protocol might be useful to you.
I have a network of machines with a master server which is the only one
connected to the intern
On 2013-03-28, Claudio Carbone wrote:
> Hello.
>
> I'm new to NTP and my needs aren't really rooted in the mechanism of
> synchronization and time seeding.
>
> What I intend to do is a kind of ping/traceroute of a networked
> architecture where OS level ping and traceroutes do not suffice.
>
> S
Hello.
I'm new to NTP and my needs aren't really rooted in the mechanism of
synchronization and time seeding.
What I intend to do is a kind of ping/traceroute of a networked
architecture where OS level ping and traceroutes do not suffice.
So I'm designing my own little apps to push messages
41 matches
Mail list logo
