Searching \ for '[PIC] Crystal drift? was Re: [PIC] PIC16F87 intern' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'Crystal drift? was Re: [PIC] PIC16F87 intern'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Crystal drift? was Re: [PIC] PIC16F87 intern'
2005\05\08@204646 by Mark Rages

face picon face
On 5/8/05, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamembedinc.com> wrote:
> phil B wrote:
> > I should have been a bit clearer.  I am checking when
> > I sync up the time.  At that point the PC clock should
> > be  pretty close.
>
> No, that was my point.  Take a look at the clock when you sync up.  It
> doesn't jump suddenly, unless maybe it's way off.  In some cases anyway, the
> system appears to try adjusting it smoothly.  It may take a while for it to
> get to the "correct" time.  You'll be much better off checking with a real
> reference.

No, his method is fine for the accuracies he's talking about.  At work
I have a bunch of servers that syncronize time using NTP. They stay
within a few milliseconds of each other.  This is becuse the NTP
daemon continuously varies the hardware clock speed to keep in sync
with the reference, kind of like a very slow-running PLL.  ( My
machines run Linux, but I've noticed Windows XP comes with an NTP
daemon too, now. I assume it works equally well. )

P.S. Phil, to get a quick fix on the time, issue "rdate time.nist.gov"
on a Linux box.  Error should be less than a second, because NTP takes
network latency into account.

Regards.
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\05\09@030547 by Robert Rolf

picon face
Mark Rages wrote:

> On 5/8/05, Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com> wrote:
>
>>phil B wrote:
>>
>>>I should have been a bit clearer.  I am checking when
>>>I sync up the time.  At that point the PC clock should
>>>be  pretty close.
>>
>>No, that was my point.  Take a look at the clock when you sync up.  It
>>doesn't jump suddenly, unless maybe it's way off.  In some cases anyway, the
>>system appears to try adjusting it smoothly.  It may take a while for it to
>>get to the "correct" time.  You'll be much better off checking with a real
>>reference.
>
> No, his method is fine for the accuracies he's talking about.  At work
> I have a bunch of servers that syncronize time using NTP. They stay
> within a few milliseconds of each other.  This is becuse the NTP
> daemon continuously varies the hardware clock speed to keep in sync
> with the reference, kind of like a very slow-running PLL.

 You sure about that?
More likely it adjusts the software clock tics by adding or dropping
them as needed. The HARDWARE tic clock is not tweakable in a PC.
(Ok, it is, but not very granular, and not with a system API.
It is VERY hardware specific.
14.31818 Mhz/12/65536 =18.20650736 Hz system tic rate.)

  ( My
> machines run Linux, but I've noticed Windows XP comes with an NTP
> daemon too, now. I assume it works equally well. )

Nope, it doesn't. There is NO 'varying the hardware clock speed'.
You get what you get. The software makes NO effort
to correct for drift errors. It just jams the new time into
the clock if the error is not too large.

There was a really old DOS shim that doubled the clock timer
rate and then added or dropped tics as it learned the
error of both the CMOS clock and the SYSTEM clock.
It learned the error for the system clock AND it also
added a compensating offset for the CMOS every boot.
It did NOT use NTP (since back when it was written,
network connectivity (mail, news, etc. was DIALUP).

I have yet to find anything like that for Winblows.
(anyone have a lead?).

> P.S. Phil, to get a quick fix on the time, issue "rdate time.nist.gov"
> on a Linux box.  Error should be less than a second, because NTP takes
> network latency into account.

Yes, but Winblows happily lets the system lock out interrupts
for extended periods, and the 'date/time' counter drops
tics quite IRREGULARLY as a result. I'm involved in a couple
of radio astronomy projects, so I've learned to NOT trust
winblows time call AT ALL. You want accurate time stamps,
you use a board designed for the task.

Robert

2005\05\09@044116 by Alan B. Pearce

face picon face
>  You sure about that?
>More likely it adjusts the software clock tics by adding or dropping
>them as needed. The HARDWARE tic clock is not tweakable in a PC.
>(Ok, it is, but not very granular, and not with a system API.
>It is VERY hardware specific.
>14.31818 Mhz/12/65536 =18.20650736 Hz system tic rate.)

That is under all the DOS based systems. My understanding is that the NT
based systems change the divisor to something like a 1mS tick.

2005\05\09@110116 by phil B

picon face
my win2K system simply just changes the time to what
ever is set - the clock jumps.  But as I said, this
issue has NOTHING to do with the PC and I am truely
sorry for even mentioning it.

I'm not sure the tag is correct on this thread now....

Phil "I don't need no stinkin PC clock" Barrett


--- "Alan B. Pearce" <A.B.PearcespamKILLspamrl.ac.uk> wrote:
{Quote hidden}

> --

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...