David Woolley writes:
>Unruh wrote:
>> David Woolley writes:
>>
>>> Unruh wrote:
David Woolley writes:
>>
> Looking at the graphs, one needs the first derivative of the rate, as
> well.
Why? If you want the details of how chrony works, I could supply it, but
it u
Unruh wrote:
> David Woolley writes:
>
>> Unruh wrote:
>>> David Woolley writes:
>>>
>
Looking at the graphs, one needs the first derivative of the rate, as well.
>>> Why? If you want the details of how chrony works, I could supply it, but it
>>> uses
>
>> Because most of the time the fi
David Woolley writes:
>Unruh wrote:
>> David Woolley writes:
>>
>>> Looking at the graphs, one needs the first derivative of the rate, as well.
>>
>> Why? If you want the details of how chrony works, I could supply it, but it
>> uses
>Because most of the time the first derivative is almost
Unruh wrote:
> David Woolley writes:
>
>> Looking at the graphs, one needs the first derivative of the rate, as well.
>
> Why? If you want the details of how chrony works, I could supply it, but it
> uses
Because most of the time the first derivative is almost constant, which
will force an a
Unruh wrote:
> Evandro Menezes writes:
>
>
>> On Nov 9, 9:21=A0am, "David J Taylor" > bit.nor-this.co.uk.invalid> wrote:
>>
>>> Here's the offset:
>>> =A0http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_offset-tod.png
>>>
>>> and here's the rate:
>>> =A0http://www.satsignal.eu/ntp/2009-
David Woolley writes:
>Unruh wrote:
>> Well, you do have that choice, only in different names. chrony uses an
>> entirely
>> different algorithm (directly estimating the rate and the offset from a
>> sequence
>Looking at the graphs, one needs the first derivative of the rate, as well.
Why? I
"David Woolley" <> wrote in message
news:hda3tb$j1...@news.eternal-september.org...
[]
> Looking at the graphs, one needs the first derivative of the rate, as
> well.
Loopstats are available here:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#loopstats
Cheers,
David
_
Evandro Menezes wrote:
> I'd sure like to decide what's good for me, not Mills.
What is stopping _you_ from modifying NTP to meet your needs?
--
E-Mail Sent to this address
will be added to the BlackLists.
___
questions mailing list
questions@list
Unruh wrote:
> Well, you do have that choice, only in different names. chrony uses an
> entirely
> different algorithm (directly estimating the rate and the offset from a
> sequence
Looking at the graphs, one needs the first derivative of the rate, as well.
> of measurments). Of course you do
Evandro Menezes writes:
>On Nov 9, 9:21=A0am, "David J Taylor" bit.nor-this.co.uk.invalid> wrote:
>>
>> Here's the offset:
>> =A0http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_offset-tod.png
>>
>> and here's the rate:
>> =A0http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_frequency-tod.pn
On Nov 9, 9:21 am, "David J Taylor" wrote:
>
> Here's the offset:
> http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_offset-tod.png
>
> and here's the rate:
> http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_frequency-tod.png
>
> where values for the last two and half days have been overla
"Unruh" wrote in message
news:6gujm.51215$db2.19...@edtnps83...
[]
> a) This is windows.
.. and so more of a challenge to get good timekeeping.
> b) Except for the abberation at 12, the offset seems to track the disk
> temp.
> However, it is not the offset which is important but the rate. It
David Woolley writes:
>David J Taylor wrote:
>> http://www.satsignal.eu/mrtg/performance_narvik.php
>How much of that offset do you attribute to actual clock error?
>If most of it, that graph makes a strong case for a low maxpoll, or a
>different algorithm.
a) This is windows.
b) Except for
David J Taylor wrote:
> http://www.satsignal.eu/mrtg/performance_narvik.php
How much of that offset do you attribute to actual clock error?
If most of it, that graph makes a strong case for a low maxpoll, or a
different algorithm.
___
questions mail
"David Woolley" wrote in message
news:hd8j1u$ou...@news.eternal-september.org...
> David J Taylor wrote:
>
>> http://www.satsignal.eu/mrtg/performance_narvik.php
>
> How much of that offset do you attribute to actual clock error?
>
> If most of it, that graph makes a strong case for a low maxpo
"Unruh" wrote in message
news:6mkjm.51168$db2.25...@edtnps83...
> "David J Taylor"
> writes:
>
>>"Hal Murray" <> wrote in message
>>news:v72dnrrfbauf8wvxnz2dnuvz_t5i4...@megapath.net...
>>>
NTPD is at its best from about 2300 local time to 0700 local time. The
net quiets down and NTP pa
"David J Taylor"
writes:
>"Hal Murray" <> wrote in message
>news:v72dnrrfbauf8wvxnz2dnuvz_t5i4...@megapath.net...
>>
>>>NTPD is at its best from about 2300 local time to 0700 local time. The
>>>net quiets down and NTP packets travel with minimal and highly
>>>predictable delays.
>>
>> Except at
David J Taylor wrote:
> "Hal Murray" <> wrote in message
> news:v72dnrrfbauf8wvxnz2dnuvz_t5i4...@megapath.net...
>
>>> NTPD is at its best from about 2300 local time to 0700 local time. The
>>> net quiets down and NTP packets travel with minimal and highly
>>> predictable delays.
>>>
>>
"Hal Murray" <> wrote in message
news:v72dnrrfbauf8wvxnz2dnuvz_t5i4...@megapath.net...
>
>>NTPD is at its best from about 2300 local time to 0700 local time. The
>>net quiets down and NTP packets travel with minimal and highly
>>predictable delays.
>
> Except at 3 AM when the cron jobs go off and
>> What do you suggest to mitigate the wild swings between daytime and
>> nighttime, sunny and cloudy, cold-front and warm-front, etc, of both
>> the offset and the frequency?
>
>If this in fact a real problem, I'd suggest wrapping some insulation
>around the clock crystal.
>
>This would make tem
>NTPD is at its best from about 2300 local time to 0700 local time. The
>net quiets down and NTP packets travel with minimal and highly
>predictable delays.
Except at 3 AM when the cron jobs go off and warm up the system.
--
These are my opinions, not necessarily my employer's. I hate spam.
Terje Mathisen writes:
>Evandro Menezes wrote:
>> On Nov 6, 3:10 pm, Terje Mathisen wrote:
>>>
>>> Making it more convenient to lock polling at 64s isn't a good idea, imho.
>>
>> What do you suggest to mitigate the wild swings between daytime and
>> nighttime, sunny and cloudy, cold-front and wa
"David J Taylor"
writes:
>"Evandro Menezes" wrote in message
>news:d9a76148-a9c9-45d5-ac72-4e7588c61...@m7g2000prd.googlegroups.com...
>> I've come to the conclusion that since NTP doesn't correct for
>> temperature variations, it's long-term compensation is counter-
>> productive. Therefore,
Richard,
It's amazing how much bullshit is spread by others without checking the
documentation, the code, the loopstats data and for that matter the
papers and the book. You correctly observe the poll interval does change
in response to measured system jitter and oscillator wander. As
confirme
Terje Mathisen wrote:
> Evandro Menezes wrote:
>> On Nov 6, 3:10 pm, Terje Mathisen wrote:
>>>
>>> Making it more convenient to lock polling at 64s isn't a good idea,
>>> imho.
>>
>> What do you suggest to mitigate the wild swings between daytime and
>> nighttime, sunny and cloudy, cold-front and
Evandro Menezes wrote:
> On Nov 6, 3:10 pm, Terje Mathisen wrote:
>>
>> Making it more convenient to lock polling at 64s isn't a good idea, imho.
>
> What do you suggest to mitigate the wild swings between daytime and
> nighttime, sunny and cloudy, cold-front and warm-front, etc, of both
> the off
"Evandro Menezes" wrote in message
news:d9a76148-a9c9-45d5-ac72-4e7588c61...@m7g2000prd.googlegroups.com...
> I've come to the conclusion that since NTP doesn't correct for
> temperature variations, it's long-term compensation is counter-
> productive. Therefore, instead of letting the poll peri
Unruh wrote:
> Evandro Menezes writes:
>
>> On Jul 12, 3:21=A0pm, Unruh wrote:
>>> The way ntp works, faster polling also means worse rate estimation and
>>> more annoyance of the providers of the time. The current setup is done
>>> that way to try to minimize the rate error, so if your sconnect
Hal Murray wrote:
>> One thing you could try would be to put your clock in a thermostatically
>> controlled oven. I'm not talking about something you could bake a pizza
>> in, but rather something that will keep 140 degrees F +/- half a degree.
>
> 140 is pretty warm. That will reduce the lif
> From: hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
> Date: Thu, 16 Jul 2009 17:18:01 -0500
> Sender: questions-bounces+oberman=es@lists.ntp.org
>
>
> >One thing you could try would be to put your clock in a thermostatically
> >controlled oven. I'm not talking about something yo
>One thing you could try would be to put your clock in a thermostatically
>controlled oven. I'm not talking about something you could bake a pizza
>in, but rather something that will keep 140 degrees F +/- half a degree.
140 is pretty warm. That will reduce the lifetime of most
electronics q
David Woolley wrote:
> So, basically, as long as you act irresponsibly with respect to use of
> energy and other resources, you will have no problem.
>
> Powering down is often the optimum way of minimising energy usage and
> maximising the time till land fill.
>
> To avoid temperature transient
David Woolley wrote:
> Richard B. Gilbert wrote:
>> David Woolley wrote:
>
>>>
>>> Such improvements are unlikely as it turns out that the subject of
>>> this thread is an area where Dave Mills refuses to acknowledge a
>>> problem.
>>
>> There is no problem unless you insist on shutting down you
Richard B. Gilbert wrote:
> David Woolley wrote:
>>
>> Such improvements are unlikely as it turns out that the subject of
>> this thread is an area where Dave Mills refuses to acknowledge a problem.
>
> There is no problem unless you insist on shutting down your system
> frequently.
So, basica
John Hasler wrote:
> Evandro Menezes writes:
>> In the real world, ambient temperature changes frequently even in
>> air-conditioned environments, system load affect its internal
>> temperature, network load affects packet jitter, etc. And all this also
>> affects a system's peers, compounding the
"Richard B. Gilbert" writes:
>David Woolley wrote:
>> David J Taylor wrote:
>>> John Hasler wrote:
>>> []
The Chrony source is available under the GPL. I'm sure someone would
be willing to port it for you for suitable compensation.
>>>
>>> If I were paying my money, I would rather it w
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> There is not terribly much that can at present be done to improve ntp
>> so
>> it would be hard to find ways of spending the money. While with
>> chrony,
>> you would have a totally new time keeping program for Windows at the
>> end
>> of the day, a
>
> This is all noise. You want to filter it out, not track it.
No, it isn't. Or at least the temperature effect on the crystal
frequency should be tracked more closely, because it can vary
significantly enough to throw NTP's loop off.
Thanks.
___
qu
Richard B. Gilbert writes:
> One thing you could try would be to put your clock in a thermostatically
> controlled oven. I'm not talking about something you could bake a pizza
> in, but rather something that will keep 140 degrees F +/- half a degree.
Just glue a thermoelectric device and a thermi
Evandro Menezes wrote:
> On Jul 15, 6:22 am, "Richard B. Gilbert"
> wrote:
>> There is no problem unless you insist on shutting down your system
>> frequently.
>
> That's not the only case. In the real world, ambient temperature
> changes frequently even in air-conditioned environments, system l
Evandro Menezes writes:
> In the real world, ambient temperature changes frequently even in
> air-conditioned environments, system load affect its internal
> temperature, network load affects packet jitter, etc. And all this also
> affects a system's peers, compounding the issue of NTP's slow reac
On Jul 15, 6:22 am, "Richard B. Gilbert"
wrote:
>
> There is no problem unless you insist on shutting down your system
> frequently.
That's not the only case. In the real world, ambient temperature
changes frequently even in air-conditioned environments, system load
affect its internal temperatu
On Wed, Jul 15, 2009 at 01:47:17AM +, Unruh wrote:
> "David J Taylor"
> writes:
>
> >John Hasler wrote:
> >[]
> >> The Chrony source is available under the GPL. I'm sure someone would
> >> be willing to port it for you for suitable compensation.
>
> >If I were paying my money, I would rath
On Wed, Jul 15, 2009 at 6:22 AM, Richard B.
Gilbert wrote:
> There is no problem unless you insist on shutting down your system
> frequently.
These days, even production servers are frequently shut down
off-hours. Things like VMware's Dynamic Power Management
(http://www.vmware.com/products/vi/vc/
David Woolley wrote:
> David J Taylor wrote:
>> John Hasler wrote:
>> []
>>> The Chrony source is available under the GPL. I'm sure someone would
>>> be willing to port it for you for suitable compensation.
>>
>> If I were paying my money, I would rather it went towards improving
>> the official
David J Taylor wrote:
> John Hasler wrote:
> []
>> The Chrony source is available under the GPL. I'm sure someone would
>> be willing to port it for you for suitable compensation.
>
> If I were paying my money, I would rather it went towards improving the
> official NTP, to be honest.
Such impr
Unruh wrote:
[]
> There is not terribly much that can at present be done to improve ntp
> so
> it would be hard to find ways of spending the money. While with
> chrony,
> you would have a totally new time keeping program for Windows at the
> end
> of the day, a program with a very different philoso
Unruh writes:
> That is fine, but there are decisions which were and are made re ntp
> which no amount of money will change-- decisions which severely limit the
> accuracy of ntp.
It should be noted that there are good reasons for these decisions, which
don't apply to most Chrony applications.
--
"David J Taylor"
writes:
>John Hasler wrote:
>[]
>> The Chrony source is available under the GPL. I'm sure someone would
>> be willing to port it for you for suitable compensation.
>If I were paying my money, I would rather it went towards improving the
>official NTP, to be honest.
That is f
>>> In article , "David J
>>> Taylor"
>>> writes:
David> John Hasler wrote: []
>> The Chrony source is available under the GPL. I'm sure someone would be
>> willing to port it for you for suitable compensation.
David> If I were paying my money, I would rather it went towards improving
David>
John Hasler wrote:
[]
> The Chrony source is available under the GPL. I'm sure someone would
> be willing to port it for you for suitable compensation.
If I were paying my money, I would rather it went towards improving the
official NTP, to be honest.
Cheers,
David
___
Unruh wrote:
[]
> You asked if there was Windows support OR refclock support, not AND.
> Also, if you want time accuracy, don't run windows in the first place.
> If you run windows, then the additional accuracy chrony could give you
> is irrelevant anyway. ntp is good enough for Windows:-).
Please
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Unless someone comes online wanting to port it to Windows, windows
>> support is a pretty remote possibility.
>> chrony now has support for the shm ref-clock, and any refclock can be
>> interfaced through that. It also has as of a week ago, support f
David writes:
> Thanks, Bill, but these are useless to me (and 90% of the computer
> population) unless it works with Windows.
The Chrony source is available under the GPL. I'm sure someone would be
willing to port it for you for suitable compensation.
--
John Hasler
j...@dhh.gt.org
Dancing Hor
Unruh wrote:
[]
> Unless someone comes online wanting to port it to Windows, windows
> support is a pretty remote possibility.
> chrony now has support for the shm ref-clock, and any refclock can be
> interfaced through that. It also has as of a week ago, support for
> kernel PPS I believe. Both of
"David J Taylor"
writes:
>John Hasler wrote:
>> Unruh writes:
>>> Actrually I think but am not sure, that chrony can also run on
>>> FreeBSD but I might be wrong
>>
>> FreeBSD is supported as of 1.23.
>Is there any chance of Windows support, John, or of ref-clock support?
Unless someone comes
John Hasler wrote:
> Unruh writes:
>> Actrually I think but am not sure, that chrony can also run on
>> FreeBSD but I might be wrong
>
> FreeBSD is supported as of 1.23.
Is there any chance of Windows support, John, or of ref-clock support?
David
___
> (I have seen it but have no references to give you. Ie, a group altered
> ntp to use the computer temperature to predict the rate changes, and
> found that they got a significant improvement in the clock discipline
> doing that.
Some references for this:
http://dx.eng.uiowa.edu/dave/ntptemp.php
Evandro Menezes writes:
>On Jul 13, 12:04=A0pm, Unruh wrote:
>>
>> Or use the temperature controlled ntp ( reads the temp and uses that to
>> estimate the clock rate changes due to temp variations)
>Where can I find this NTP?
googleing on "ntp temperature compansation" gave as the first item
Unruh writes:
> Actrually I think but am not sure, that chrony can also run on FreeBSD
> but I might be wrong
FreeBSD is supported as of 1.23.
--
John Hasler
j...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
___
questions mailing list
questions@lists
"Richard B. Gilbert" writes:
>Evandro Menezes wrote:
>> On Jul 12, 3:21 pm, Unruh wrote:
>>> The way ntp works, faster polling also means worse rate estimation and
>>> more annoyance of the providers of the time. The current setup is done
>>> that way to try to minimize the rate error, so if you
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Use chrony. Much much faster reaction time and better clock control.
>> However you must be running Linux (yet another reason to change).
>[]
>Not much point in changing to Linux if all the applications I run require
>a different OS.
>For timekeep
Evandro Menezes wrote:
> On Jul 12, 3:21 pm, Unruh wrote:
>> The way ntp works, faster polling also means worse rate estimation and
>> more annoyance of the providers of the time. The current setup is done
>> that way to try to minimize the rate error, so if your sconnection to
>> ntp goes down, y
On Jul 13, 12:04 pm, Unruh wrote:
>
> Or use the temperature controlled ntp ( reads the temp and uses that to
> estimate the clock rate changes due to temp variations)
Where can I find this NTP?
TIA
___
questions mailing list
questions@lists.ntp.org
h
Unruh wrote:
[]
> Use chrony. Much much faster reaction time and better clock control.
> However you must be running Linux (yet another reason to change).
[]
Not much point in changing to Linux if all the applications I run require
a different OS.
For timekeeping, FreeBSD has a good reputation.
Evandro Menezes writes:
>On Jul 12, 3:21=A0pm, Unruh wrote:
>>
>> The way ntp works, faster polling also means worse rate estimation and
>> more annoyance of the providers of the time. The current setup is done
>> that way to try to minimize the rate error, so if your sconnection to
>> ntp goes
On Jul 12, 3:21 pm, Unruh wrote:
>
> The way ntp works, faster polling also means worse rate estimation and
> more annoyance of the providers of the time. The current setup is done
> that way to try to minimize the rate error, so if your sconnection to
> ntp goes down, your system can freewheel wi
"Richard B. Gilbert" writes:
>Evandro Menezes wrote:
>> On Jul 10, 2:40 pm, Unruh wrote:
>>> And you have at least a 1/5 chance that IT is the bad server. What do
>>> you do then?
>>
>> Well, bar a false ticker, when it's ignored, it would keep NTP in
>> shorter poll periods. IOW, "honest".
>>
Evandro Menezes writes:
>On Jul 10, 2:40=A0pm, Unruh wrote:
>>
>> And you have at least a 1/5 chance that IT is the bad server. What do
>> you do then?
>Well, bar a false ticker, when it's ignored, it would keep NTP in
>shorter poll periods. IOW, "honest".
>I wonder though if the right thing
Evandro Menezes wrote:
> On Jul 10, 2:40 pm, Unruh wrote:
>> And you have at least a 1/5 chance that IT is the bad server. What do
>> you do then?
>
> Well, bar a false ticker, when it's ignored, it would keep NTP in
> shorter poll periods. IOW, "honest".
>
> I wonder though if the right thing
On Jul 10, 2:40 pm, Unruh wrote:
>
> And you have at least a 1/5 chance that IT is the bad server. What do
> you do then?
Well, bar a false ticker, when it's ignored, it would keep NTP in
shorter poll periods. IOW, "honest".
I wonder though if the right thing would be to configure 6 servers
wit
On Jul 10, 4:42 pm, "Richard B. Gilbert"
wrote:
>
> If you have one server out of five that has gone astray, ntpd should
> notice it fairly quickly.
Actually, it's anything bu quickly. If NTP has settled at 1024s poll
intervals, it may take over 30min or even 45min for it to realize the
goof up.
E-Mail Sent to this address will be added to the BlackLists wrote:
> Unruh wrote:
>> Evandro Menezes writes:
>>> As I mentioned before, in some cases, NTP relies too
>>> much on low-stratum servers, even when they're blatantly
>>> wrong. For instance, the last leap second event, when
>>> many
Unruh wrote:
> Evandro Menezes writes:
>> As I mentioned before, in some cases, NTP relies too
>> much on low-stratum servers, even when they're blatantly
>> wrong. For instance, the last leap second event, when
>> many pool servers were poorly configured.
>
>> Mulling over that, I wondered ho
Evandro Menezes writes:
>As I mentioned before, in some cases, NTP relies too much on low-
>stratum servers, even when they're blatantly wrong. For instance, the
>last leap second event, when many pool servers were poorly configured.
>Mulling over that, I wondered how I could tip NTP to scale d
As I mentioned before, in some cases, NTP relies too much on low-
stratum servers, even when they're blatantly wrong. For instance, the
last leap second event, when many pool servers were poorly configured.
Mulling over that, I wondered how I could tip NTP to scale down the
poll period in such ca
76 matches
Mail list logo
