All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin D Bennett <colin@gibibit.com>
To: grub-devel@gnu.org
Subject: Re: Higher resolution timers
Date: Tue, 20 May 2008 10:20:47 -0700	[thread overview]
Message-ID: <20080520102047.23b0456e@gibibit.com> (raw)
In-Reply-To: <483058D9.6060701@nic.fi>

On Sun, 18 May 2008 19:27:05 +0300
Vesa Jääskeläinen <chaac@nic.fi> wrote:

> Colin D Bennett wrote:
> > I think that using the TSC (w/ RDTSC instruction) and calibrating it
> > with a quick 2-3 RTC tick loop at startup might be the easiest
> > option.
> 
> Hi Colin,
> 
> What kind of accuracy would you need?
> 
> I am just wondering if you just define function like:
> 
> grub_uint64_t
> grub_timer_[nu]time(void);
> 
> This could return time in nanoseconds, or microseconds from epoch.
> 
> Then during grub init you would call some platform function to 
> initialize time (calibrate when using rdtsc), and set proper offset 
> value so you get correct time when asking for time. On every system
> it would return time in this format, but granularity would be
> different.
> 
> This could be:
> 
> void
> grub_timer_init(void)
> 
> What do you think?

Vesa,
It sounds good.  Actually, for the kind of the situations I am
thinking of, high resolution timing is not required to be based on any
absolute real time, so we would not necessarily need to base it on RTC
time. Synchronizing it to RTC time would probably not be difficult, but
I thought I would mention what my requirements will be.

Here is the kind of situation I envision, in an event loop that handles
accepting user input and updating the screen at regular intervals
(possibly at 30 to 60 frames/sec, hence the need for higher resolution
timers) to support the user interface:

 /* Event loop */
 grub_uint32_t nextframe_time = 0;
 grub_uint32_t now;
 while (1)
 {
   now = grub_timer_utime();
   if (now >= nextframe_time)
   {
     /* Schedule the next frame. */
     nextframe_time = now + 1000000 / FRAMES_PER_SEC;
     do_animation_step();
   }
   if (key_is_pressed())
   {
     /* Handle key presses... */
   }
 }

So all I care about is the value relative to other calls to
grub_timer_utime() during a particular runtime of grub. It could start
at 0 if that is easier, but either way is fine.

Colin



  reply	other threads:[~2008-05-20 17:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-12 16:33 Higher resolution timers Colin D Bennett
2008-05-14 16:26 ` Vesa Jääskeläinen
2008-05-18 16:27 ` Vesa Jääskeläinen
2008-05-20 17:20   ` Colin D Bennett [this message]
2008-05-20 17:46 ` Colin D Bennett
2008-05-23 11:55   ` Marco Gerards
2008-05-23 14:28     ` Colin D Bennett
2008-05-24  9:23       ` Marco Gerards
2008-05-28 13:43         ` Robert Millan
2008-05-23 11:48 ` Marco Gerards
2008-05-24 15:25   ` Vesa Jääskeläinen

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=20080520102047.23b0456e@gibibit.com \
    --to=colin@gibibit.com \
    --cc=grub-devel@gnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.