Re: smp and irq conflict

[Manu Abraham]

On 2/2/07, Erik Mouw <erik@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.

such devices can do a max of one input or 2 inputs. There are cards
that do 16/32 video inputs, do hardware MPEG4 compression and write to
disk/ stream out through the network interface.

But most such devices have proprietory drivers and have issues working
properly. Got bitten by a bug similarly, recently. The vendor was pig
headed to either fix the driver or to provide driver source.
(http://dvr.neugent.net/ They talked too much of Linux, but really
pathetic stuff overall, claimed their issue was Intellectual Property)

They claimed the Linux kernel was buggy rather than stating that their
driver was buggy.
In the end, luckily got my money back for the hardware.

Manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/