ma...@ntp.org (Danny Mayer) writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> David Woolley wrote:
Joseph Gwinn wrote:
> We have moved from the meaning of status code 9514 to the more general
But you should have kept the thread, even if the subject changed.
> i
Joseph Gwinn wrote:
> In article <49becf09$0$507$5a6ae...@news.aaisp.net.uk>,
> David Woolley wrote:
>
>> Joseph Gwinn wrote:
>>> We have moved from the meaning of status code 9514 to the more general
>> But you should have kept the thread, even if the subject changed.
>
> Opinion varies on th
Richard B. Gilbert wrote:
> Unruh wrote:
>>
>> I do not believe that say Linus every believed that he wrote the
>> kernel only for people who would support it themselves. It was a tool
As he wrote it as a student, I suspect he wrote it for the challenge of
doing it.
>> written for many by
Unruh wrote:
> David Woolley writes:
>
>> Actually a lot of commercial software, these days, is dumbed down,
>> supported, open source material.
>
> Nothing wrong with that, as long as the source is recognized and remains
> open.
>
A lot of it is BSD licenced. A lot of it uses the algorithms
Augustine wrote:
> On Mar 12, 3:59 am, Martin Burnicki
> wrote:
>>
>> Do you have some pointers where this is explained?
>
> Perhaps, suffice to look at page 252 and 293 of
>
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf
> where you can find the formula to calc
Dave Hart wrote:
> Unusually for me, the configuration and code on my reference clock
> test machine has been static for the last two days UTC. I've posted
> loopstats and graphs for that period on http;//davehart.net/ntp/
> refclock/
[]
> Cheers,
> Dave Hart
The program which Dave used to produc
>>> In article , Joseph Gwinn
>>> writes:
Joseph> In article ,
Joseph> Harlan Stenn wrote:
>> >>> In article , Joseph
>> >>> Gwinn writes:
>>
>> >> I think you are talking about one of my pet peeves:
>> >>
>> >> http://support.ntp.org/bin/view/Dev/NtpVariablesAndNtpq
Joseph> I don't think
"David J Taylor"
writes:
>Dave Hart wrote:
>> Unusually for me, the configuration and code on my reference clock
>> test machine has been static for the last two days UTC. I've posted
>> loopstats and graphs for that period on http;//davehart.net/ntp/
>> refclock/
>[]
>> Cheers,
>> Dave Hart
>
Unruh wrote:
[]
> Gads, those offsets are huge. And 3PPM variation is also pretty big.
Dell 4400 hardware sitting in a non-temperature controlled environment -
warm in the day, cold at night. I would happily accept five times the
jitter for a fifth of the offset!
Cheers,
David
__
At 10:38 PM -0400 3/15/09, Danny Mayer wrote:
>Joseph Gwinn wrote:
>>
>> What's the story for IBM's AIX?
>>
>
>It builds on AIX too. It builds on most Unix systems though maybe not on
>some of the oldest O/S versions.
Great.
I don't know why IBM doesn't have NTPv4 on their AIX boxes, as IBM
off
At 11:19 PM -0400 3/15/09, Danny Mayer wrote:
>Joseph Gwinn wrote:
>
The FAQ has to be the place for such explanations.
>>> I'm not sure if this qualifies as an FAQ as I don't recall that it has
>>> come up before. FAQ stands for Frequently Asked Questions.
>>
>> RAQ then? Rarely Asked Q
Status code values fixed.
At 10:47 PM -0400 3/15/09, Danny Mayer wrote:
>Joseph Gwinn wrote:
>> Hmm. OK, but I think that we've kind of run off the rails. Let me
>> summarize:
>>
>> 1. Sun Microsystems' current behavior is not the issue, as I'm loading
>> old software from an old CD onto o
On Mar 17, 5:25 pm, "David J Taylor" wrote:
>
> The program which Dave used to produce his graphs from loopstats data is
> available in an unsupported beta version here:
>
> http://www.satsignal.eu/software/net.htm#NTPplotter
Those are interesting graphs in their own right on that page. I
notic
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Gads, those offsets are huge. And 3PPM variation is also pretty big.
>Dell 4400 hardware sitting in a non-temperature controlled environment -
>warm in the day, cold at night. I would happily accept five times the
>jitter for a fifth of the offse
Joseph Gwinn wrote:
> More generally, it's hopeless to expect the world's sysadmins to read
> NTP code (or any other kind of code). They just don't have the time,
I had a look at the W32Time documentation in Technet and it seems to me
that you need access to the source code (and a thorough kn
On Mar 17, 9:21 pm, Unruh wrote:
> "David J Taylor"
> writes:
> >Dell 4400 hardware sitting in a non-temperature controlled environment -
> >warm in the day, cold at night. I would happily accept five times the
> >jitter for a fifth of the offset!
>
> Maybe when someone finally put refclock sup
Dave Hart wrote:
> On Mar 17, 5:25 pm, "David J Taylor" this-bit.nor-this.co.uk> wrote:
>>
>> The program which Dave used to produce his graphs from loopstats
>> data is available in an unsupported beta version here:
>>
>> http://www.satsignal.eu/software/net.htm#NTPplotter
>
> Those are interesti
Dave Hart writes:
>On Mar 17, 9:21=A0pm, Unruh wrote:
>> "David J Taylor" > writes:
>> >Dell 4400 hardware sitting in a non-temperature controlled environment -
>> >warm in the day, cold at night. =A0I would happily accept five times the
>> >jitter for a fifth of the offset!
>>
>> Maybe when som
Unruh wrote:
[]
> Maybe when someone finally put refclock support into chrony you will
> have
> your wish.
Not until it runs under Windows.
> It sounds like your temp changes causing rate changes on a
> scale
> that ntp cannot properly cope with. (ntp is terrible at coping with
> changes-- a purp
On Mar 17, 10:44 pm, Unruh wrote:
> Dave Hart writes:
> >That's one view. I look at ntpd as terribly suspicious of change ;)
> >The slow response is beneficial if you are relying on remote NTP
> >servers and the surviving sources change over time with different
> >apparent average offsets, much
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Maybe when someone finally put refclock support into chrony you will
>> have
>> your wish.
>Not until it runs under Windows.
Fair enough.
>> It sounds like your temp changes causing rate changes on a
>> scale
>> that ntp cannot properly cope with
Dave Hart writes:
>> >The minimum delay
>> >clock filter selects the shortest roundtrip delay of the last eight,
>> >based on the observation the least-delayed exchange results in the
>>
>> And if the variation in the delays is less than the jitter, this simply
>> results in throwing away most o
On 2009-03-17, Dave Hart wrote:
> And I would love to leave more of the evaluation to others but so far
> only a few brave souls have been downloading binaries or source.
> David J Taylor and Martin Burnicki have both discussed their results
> favorably. I can only hope the silence of the majori
23 matches
Mail list logo
