LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: John <me@privacy.net>
Cc: linux-kernel@vger.kernel.org, tglx@timesys.com, mingo@elte.hu,
	akpm@osdl.org, shill@free.fr
Subject: Re: One-shot high-resolution POSIX timer periodically late
Date: Wed, 24 Jan 2007 11:02:27 -0800	[thread overview]
Message-ID: <1169665347.6905.3.camel@localhost.localdomain> (raw)
In-Reply-To: <45B729AF.4030701@privacy.net>

On Wed, 2007-01-24 at 10:41 +0100, John wrote:
> I'm using the POSIX timers API. My platform is x86 running Linux
> 2.6.18.6 patched with the high-resolution timer subsystem.
> 
> http://www.tglx.de/hrtimers.html
> 
> I've written a small "de-jittering engine" that receives packets in
> small bursts due to network jitter (typical average rate of 1000 packets
> per second), and re-sends them at a "smooth" rate.
> 
> Just before I re-send a packet, I arm a one-shot timer in order to
> receive a signal when it is time to send the next packet.
> 
> I've noticed a strange phenomenon that I cannot explain.
> 
> Sometimes (rarely) the one-shot timer will expire more than 50 µs later
> than expected. This would seem normal, except that it happens periodically.
> 
> For example, my app had been running normally for 2 minutes when it
> started printing diagnostics (see below).
> 
> The first T_NEXT_POP is the date the timer was supposed to expire,
> 
> NOW is the date the timer was handled after returning from sigwaitinfo
> (I am aware that blocking signals, and handling them at a specific point
> in the code will add some latency)
> 
> The second T_NEXT_POP is the date the next timer is supposed to expire.
> 
> DIFF is the difference between real and expected dates.
> 
> (All dates are CLOCK_MONOTONIC by the way.)
> 
> As you can see, the first diagnostic came at 472.410501014... Then
> another diagnostic almost exactly two seconds apart 9 times in a row!
> 
> My process is the only SCHED_FIFO process on the system. There are no
> user-space processes with a higher priority. AFAICT, only a kernel
> thread could keep the CPU away from my app.
> 
> Is there a periodic kernel thread that runs every 2 seconds, cannot be
> preempted, and runs for over 50 µs??

This sounds like a BIOS SMI issue. Can you reproduce this behavior on
different hardware? 

thanks
-john


       reply	other threads:[~2007-01-24 19:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <45B729AF.4030701@privacy.net>
2007-01-24 19:02 ` john stultz [this message]
2007-01-24 20:09   ` Ingo Molnar
     [not found] <fa.NwnlFyMPfa3XG6my3HKGWnCW3x4@ifi.uio.no>
     [not found] ` <fa.Ji4GnAbBF2FR5JbSxvxn2haJZIk@ifi.uio.no>
2007-01-25  9:59   ` John
2007-01-25 22:19     ` john stultz
     [not found]   ` <fa.8TBiwbgs8B881k+3X+IlFjhqpLI@ifi.uio.no>
2007-01-25 12:03     ` John
     [not found] <fa.mtUvfgenNQkCc8835prYbwyiPQs@ifi.uio.no>
     [not found] ` <fa.lwkMc548uRMcUjd9KZ2pC1DMKT4@ifi.uio.no>
     [not found]   ` <fa.dTtI0ctv1nu+tCWiK6jGPnrX69k@ifi.uio.no>
     [not found]     ` <fa.CMU3scpnLxfHVWRFPcmfRl2CjhA@ifi.uio.no>
2007-01-30 17:38       ` John
2007-01-30 20:25         ` Ingo Molnar
     [not found] <fa.4zD54Ie6Ozt0P4YqQSicS+XzXGw@ifi.uio.no>
     [not found] ` <fa.G+/T32f2o1M3+YGLca/O8NaAQyY@ifi.uio.no>
     [not found]   ` <fa.6Ua8xjNfLKQEZZgDsoJgPMyww4g@ifi.uio.no>
     [not found]     ` <fa.yQlV+WU0TgrJTVqjopa01tgCnT0@ifi.uio.no>
     [not found]       ` <fa.ucVrLJ1Lh6FjdBHRglsIUc8/evk@ifi.uio.no>
     [not found]         ` <fa.Id9oufyELrVbe5Wb8SRakwC0V50@ifi.uio.no>
2007-02-01 10:18           ` John
2007-02-06 12:37             ` Ingo Molnar
2007-02-07 10:13               ` John
2007-02-05 16:37           ` John
2007-02-06  7:31             ` Peter Zijlstra
2007-02-07 10:25               ` John
2007-02-08 17:32                 ` Thomas Gleixner
2007-02-09 15:25                   ` John
2007-02-09 16:21                     ` Benedikt Spranger
2007-02-09 16:43                     ` Thomas Gleixner

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=1169665347.6905.3.camel@localhost.localdomain \
    --to=johnstul@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@privacy.net \
    --cc=mingo@elte.hu \
    --cc=shill@free.fr \
    --cc=tglx@timesys.com \
    --subject='Re: One-shot high-resolution POSIX timer periodically late' \
    /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

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 NNTP newsgroup(s).