[MPlayer-dev-eng] Adding threaded functionality to mplayer

Zoltan Hidvegi mplayer at hzoli.2y.net
Thu Sep 9 18:53:34 CEST 2004


> lol, do you realy believe that PCI-Express will solve the I/O issue ?
> Todays normal PCI interface can handle about 135MByte/s (33.3MHz, 32bit)
> but in reality you can hardly go over 80MB/s with a single device. Using

I can get over 100 MB/s sustained read from a PCI PATA card reading
from two disks in parallel (in raid).  The read is limited by the disk
surface read speed.  The onboard IDE interfaces are often on a
separate bus, I have an nForce2 board, where I can get over 200GB/s
total sustained bandwidth from 4 disks (during kernel raid5 resync),
which is possible because the disk on the onboard IDE channels are not
on the legacy PCI bus.  I have a TV tuner on the same PCI bus as the
PCI IDE card, and when there is full load on the disks, there is not
enough PCI bandwidth left for the TV, and you can see horizontal
stripes on the TV, but the picture is still mostly OK.

> more than one decreases the overall bandwidth further. But even 80MB/s
> should be enough for most videos, but unfortunately, we have another
> bottleneck: RAM. Every I/O operation uses RAM and as long as this stupid
> PC design continues, this will be one of the major bottlenecks.

The theoretical badwidth to RAM is 2GB/s or higher, and you can achive
at least 50% of this in practice.  PC design is still stupid, but it
is way way better than it used to be.

> But the PC would actualy profit more from a redesign of it's I/O
> architecture then from new busses, but that doesnt sell as well as
> bigger numbers.

The Athlon64 and Opteron has a completely new I/O and memory
architecture, and they are selling pretty well, at relatively low
prices.

Zoli




More information about the MPlayer-dev-eng mailing list