[linux-dvb] Re: [PATCH] Skystar2 pid filters reorganization

["Augusto Cardoso" <augusto@carhil.net>]

Hi!

(Sorry about the long emails, we had a 4 day holiday here in US and it's cold and stormy outside... :) )

In relation to the FC and skystar2.c, IMHO, things are confused because there are two chips(and possibly a third FCIII) and they have different capabilities.

The Flexcop can be used just like any PCI bridge in the "budget" cards. However, it can do a lot more.
In most cases, working like the other budget cards is fine. This is the case for operation in a home environment, for watching, record shows, etc.

I was personally involved in the design of the chip. I worked with customers on their applications as well.
The chips is/was sold to a number of companies using it in embedded applications.
Even in systems with slow processors, X86 running at 133Mhz and PowerPC, enabling the whole transponder isn't a big hit on the CPU. It's not possible to run them like that because of the bus performance.

A few examples.
1) PowerPC PCI bridges, Early SIS chips set and Intel ZX bridge.
For these chips was necessary the use of the HW filters and in some cases(PowerPC) of the internal demux. 
For the SIS it was necessary to optimize of the chip settings. 
For the ZX, luckily on longer in production, it was a must to use the HW filter. This chipset "breaks" every PCI burst transfer in two DWORDS. This makes the DMA extremely inefficient.
2) FCIII - USB version. This only supports 11Mbps mode, in this case is necessary the use of the hw PIDS and the internal demux. You can open the whole transponder, but the data will be useless.
3) Multiple cards per system. I'm currently working on an application that requires 4-6 cards in one system. Without the HW filters, it's impossible to receive 6 streams (audio+video), read them from HD and send on the LAN.

In my opinion, the driver should be good enough for all types of applications. Having said that, the 6HW pids + group pid should be more than enough for the normal home user. The only time you must have a lot of PIDS is during scan, in which case you can open the whole transponder. When the card has a FCIIB in it, we can enable the other 32 PIDs. This should be the ideal solution. I don't believe it's necessary to emulate more PIDs at the skystar2.c level. If more PIDs are needed, there is already swfilters available. The DMA could be implemented in more efficient way, eliminating a lot of the packet copies, therefore rendering any PID compares at the skystar2.c level an extra step.

	Augusto

*********** REPLY SEPARATOR  ***********

On 11/29/2003 at 5:53 PM Roberto Ragusa wrote:

>On Sat, 29 Nov 2003 15:59:21 +0100
>Holger Waechtler <holger@convergence.de> wrote:
>
>> Roberto Ragusa wrote:
>
>> > In relation to "one of the first checks", do you think that the
>swfilter
>> > code is fast enough to let us just open_whole_bandwith when we're out
>of
>> > hw filters?
>> 
>> sure, why not? All other decoder-less PCI cards wotk reliably the same 
>> way...
>
>Maybe I didn't explain well what I meant.
>I'm not saying "will the hardware be fast enough?".
>I'm saying, instead, the following:
>
>skystar2 filter emulation:
>- let S2EMU be the time for every packet examined (and then accepted or
>refused)
>
>swfilter:
>- let SWF be the time for every packet examined (and then accepted or
>refused)
>
>With skystar2 filter emulation, processing one packet takes:
>  S2EMU + SWF * fraction_accepted
>
>With swfilter only, processing one packet takes:
>  SWF
>
>"Swfilter only" is better if SWF < S2EMU / ( 1 - fraction_accepted )
>
>Now, what we have is
>  S2EMU = a small time (comparison between pid value and an array of 10 or
>            20 elements)
>  fraction_accepted = 0.1 or 0.2
>
>so the question is if SWF is really less than 0.9 S2EMU.
>This is where I want your opinion.
>
>You said that it is one of the first tests, but I'm wondering if it is
>really fast enough to be the best choice.
>For example, if the packet is copied to a buffer, SWF is certainly
>very big. Even if there is no copy, I guess that S2EMU is too small
>to be beaten.
>
>> I'd suggest to implement and activate the PID filters mostly to save PCI 
>> bus bandwidth, keeping the PCI latency low with many cards in your PC is 
>> usually a much more serious problem than CPU load caused by the software 
>> demux.
>> 
>> And in most environments you don't need the entire 38MBit Stream but 
>> audio, video and some section data streams which sum up to 4-10MBit...
>
>This is perfectly right.
>If we can filter before PCI traffic, we do it.
>But when we have no choice (too many pids wanted) the problem I described
>above takes place.
>
>
>-- 
>   Roberto Ragusa    r.ragusa at libero.it
>
>
>-- 
>Info:
>To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.





-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.