public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@ecoscentric.com>
To: "M Arshad Khan" <marshadkhan@gmail.com>
Cc: ecos-discuss@ecos.sourceware.org,  ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Drift in Real Time Clock
Date: Wed, 06 Jun 2007 12:20:00 -0000	[thread overview]
Message-ID: <m37iqhgz0e.fsf@xl5.calivar.com> (raw)
In-Reply-To: <4690b0d10706060251nfb2c3a0o4f681317413e9616@mail.gmail.com>

"M Arshad Khan" <marshadkhan@gmail.com> writes:

> yes the problem was with the initialization value i varry this value
> and got delay of 1.5ms in 100 s using initialization value of 11934
> (very strange...). now i want to reduce the time of one tick from 10ms
> to 1ms... so that i can generate interrupt of 1ms i tried it by
> changing the values of clock resolution numerator and clock resolution
> denominator but same 10ms. any suggestion in this regard?...
>

You need to change the period value too, it is not changed
automatically if you just change the resolution parameters. However,
going to a 1KHz tick rate will make the drift worse. For better
accuracy it might make sense to choose a frequency that is more
directly related to the PC clock frequency. 

Also, the crystal that drives the clock will have limited accuracy,
which will vary with things like temperature. So there is only a
limited amount you can do to eliminate drift; unless you regularly
query an external clock and calibrate it in the way that fully
functional NTP clients do.

-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

WARNING: multiple messages have this Message-ID
From: Nick Garnett <nickg@ecoscentric.com>
To: "M Arshad Khan" <marshadkhan@gmail.com>
Cc: ecos-discuss@ecos.sourceware.org,  ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Drift in Real Time Clock
Date: Wed, 06 Jun 2007 14:29:00 -0000	[thread overview]
Message-ID: <m37iqhgz0e.fsf@xl5.calivar.com> (raw)
Message-ID: <20070606142900.a_y9WRrXqyrnl0jVGg_kaRIrlcCq-ZvXAbpRJoPyriY@z> (raw)
In-Reply-To: <4690b0d10706060251nfb2c3a0o4f681317413e9616@mail.gmail.com>

"M Arshad Khan" <marshadkhan@gmail.com> writes:

> yes the problem was with the initialization value i varry this value
> and got delay of 1.5ms in 100 s using initialization value of 11934
> (very strange...). now i want to reduce the time of one tick from 10ms
> to 1ms... so that i can generate interrupt of 1ms i tried it by
> changing the values of clock resolution numerator and clock resolution
> denominator but same 10ms. any suggestion in this regard?...
>

You need to change the period value too, it is not changed
automatically if you just change the resolution parameters. However,
going to a 1KHz tick rate will make the drift worse. For better
accuracy it might make sense to choose a frequency that is more
directly related to the PC clock frequency. 

Also, the crystal that drives the clock will have limited accuracy,
which will vary with things like temperature. So there is only a
limited amount you can do to eliminate drift; unless you regularly
query an external clock and calibrate it in the way that fully
functional NTP clients do.

-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  parent reply	other threads:[~2007-06-06 10:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-05  4:59 M Arshad Khan
2007-06-05 12:31 ` M Arshad Khan
2007-06-05 17:49 ` Andrew Lunn
2007-06-05 18:31   ` Andrew Lunn
2007-06-06 10:33   ` M Arshad Khan
2007-06-06 10:37     ` M Arshad Khan
2007-06-06 12:20     ` Nick Garnett [this message]
2007-06-06 14:29       ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m37iqhgz0e.fsf@xl5.calivar.com \
    --to=nickg@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=marshadkhan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).