LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Erik Mouw <erik@harddisk-recovery.com>
To: Lapo TIN <lapolapolapo@tin.it>
Cc: linux-smp@vger.kernel.org, linux-kernel@vger.kernel.org,
	"'Robert Hancock'" <hancockr@shaw.ca>
Subject: Re: smp and irq conflict
Date: Fri, 2 Feb 2007 12:08:54 +0100	[thread overview]
Message-ID: <20070202110853.GA16296@harddisk-recovery.com> (raw)
In-Reply-To: <45C0FAE300242D46@vsmtp14.tin.it>

On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote:
> I need to capture at 25 frame per second from each channel...
> So 25 x 8 total frames per second on the pci.

Each PAL frame takes about 800k, so that makes 20MB/s per channel. With
8 channels that makes 160 MB/s. That will most certainly overwhelm a
normal 33 MHz 32 bit PCI bus which has a theoretical bandwidth of 132
MB/s (90MB/s max in practice). Modern PCs have faster PCI busses
(66MHz, 64 bit, PCI-X, or PCI-e) so there's less chance on bus
contention.

On the other hand, I suppose you will store the video streams on disk.
That will use another 20MB/s per channel on the bus so the total
becomes 320 MB/s. You need some careful system design in order to get
that right. Especially look carefully at bus contention, if the system
has multiple busses, distribute the bttv cards over those busses. Also
be sure to have enough bandwidth for the disk subsystem.

> So do you think I have to change the motherboard ?
> What is important ? the chipset ? is there specification I need ?

Last time I had to record frame-synchronous video from 3 streams (8
years ago) PCs could hardly manage 2 streams over their bus and there
was no way to guarantee frame sync. The only way out was to use an SGI
Onyx2 with 3 digital video option cards and a large disk subsystem.
That made the whole system much more expensive but at that time it was
the only way to meet all requirements.

I don't know about current PCs, bus speeds have improved. It is however
still important how those busses are connected together and to the
chipset. You have to figure out from your motherboard documentation if
there is enough bandwidth available. If there isn't, get a faster
motherboard, or consider using compressing grabber cards like the
Hauppauge PVR 150 or PVR 500.


Erik
-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

  parent reply	other threads:[~2007-02-02 11:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.bd33YMixT9/jJwHfbD/DebGgVXs@ifi.uio.no>
2007-02-01 23:29 ` Robert Hancock
2007-02-02  0:04   ` Lapo TIN
2007-02-02  0:59     ` Robert Hancock
2007-02-02 11:08     ` Erik Mouw [this message]
2007-02-14 17:59       ` Manu Abraham
2007-02-01 17:46 Lapo TIN
2007-02-02  4:32 ` Andrew Morton
2007-02-02  5:22   ` Len Brown
2007-02-02 14:52 ` Bill Davidsen
2007-02-05 10:33   ` Benny Amorsen
2007-02-14 16:45     ` Bill Davidsen

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=20070202110853.GA16296@harddisk-recovery.com \
    --to=erik@harddisk-recovery.com \
    --cc=hancockr@shaw.ca \
    --cc=lapolapolapo@tin.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-smp@vger.kernel.org \
    --subject='Re: smp and irq conflict' \
    /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).