All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: tvtime and the Linux 2.6 scheduler
Date: Mon, 24 May 2004 15:38:45 -0400	[thread overview]
Message-ID: <c8tikk$u6f$1@gatekeeper.tmr.com> (raw)
In-Reply-To: <20040523224908.25194.qmail@web40607.mail.yahoo.com>

szonyi calin wrote:
>  --- Billy Biggs <vektor@dumbterm.net> a écrit : >   I am the
> author of tvtime, a TV application with advanced
> 
>>image
>>processing algorithms.  Some users are complaining about poor
>>performance under Linux 2.6, and I would like more information
>>about how
>>tvtime will be treated by the scheduler.  Here is an example
>>of the
>>intended usage:
>>
>>  - Program running as root and SCHED_FIFO
>>  - NTSC, input ~30 fps, each field processed for an output of ~60 fps
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
>>  - CPU intensive processing, say 9 ms per field on my P3-733
>>  - with a typical AGP card, the X driver takes 4 ms to draw
>>  - Wait using /dev/rtc set to 1024 Hz
>>
>>  for(;;)
>>      9 ms : process frame
>>      4 ms : draw frame
>>      3 ms : wait until next field time using /dev/rtc
>>      9 ms : process frame
>>      4 ms : draw frame
>>      3 ms : block on /dev/video0 for next frame
>>     -----
>>     33 ms : time per NTSC frame
	[___snip___]
> For me it works ok
> Running tvtime with 2.6.6-mm5 load average 26 (twenty six) it
> works 
> almost perfect (no frame skipped -- at least not reported by
> tvtime)
> at full rate (50 frames/sec). Computer: AMD Duron 700 MHz, 256MB
~~~~~~~~~~~~~~~~^^^
> Ram,
> VIA KT133 chipset, AGP 4x, Ati Radeon 7200 

There have been pretty good explanations of this, so I'll just say that 
it might be that someone with a machine of limited capacity would be 
able to generate 50fps and not 60fps. In much of Europe the TV flickers 
at the same frequency as the lights ;-)

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  reply	other threads:[~2004-05-24 19:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-23 15:48 tvtime and the Linux 2.6 scheduler Billy Biggs
2004-05-23 16:20 ` Jose Luis Domingo Lopez
2004-05-23 16:54 ` Con Kolivas
2004-05-23 17:20   ` Billy Biggs
2004-05-23 21:03   ` Oswald Buddenhagen
2004-05-24  8:43   ` Ingo Molnar
2004-05-24  6:58     ` Nick Piggin
2004-05-24  9:12       ` Ingo Molnar
2004-05-24  7:14         ` Nick Piggin
2004-05-24  9:34         ` Ingo Molnar
2004-05-23 22:49 ` szonyi calin
2004-05-24 19:38   ` Bill Davidsen [this message]
2004-05-25  8:49     ` Tobias Diedrich
2004-05-24  9:20 ` Ingo Molnar
2004-05-24 11:45   ` Oswald Buddenhagen
2004-05-27 11:35 ` Redeeman

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='c8tikk$u6f$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.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.