[linux-dvb] Re: SkyStar-1, network code and section packing

[Denis Fedorishenko <nuclearcat@nuclearcat.com>]

Hello Johannes,

Wednesday, March 10, 2004, 7:37:10 PM, you wrote:

JS> Denis Fedorishenko wrote:
>> Wednesday, March 10, 2004, 12:58:15 AM, you wrote:
>> 
>> JS> What happens with hw_sections=0 and enabled section packing?
>> Huge packetloss (more 30%).
>> Btw, we made another test, if i put customer on PID where is also
>> another customers (overall bandwidth 3-4 Megabit/s), same effect
>> (hw_sections=0):
>> Section packing on - packetloss
>> Without section packing - working well (even in PID, where is another
>> customers have section packing turned on).

JS> OK, with 3-4 Mbit/s on one PID you shouldn't exceed the bandwidth
JS> limitations. Something else must go wrong.
JS> So we've got to find out where packets are dropped.

JS> Does ifconfig and/or 'cat /proc/net/dev' report errors?

>> So maybe (but i cannot be sure), with hw_sections = 1 - it is
>> impossible to use network things (this beam is overall data rate 21
>> Mbit, but PID is didnt make any sense, this means even on PID
>> filtering bandwidth limited?).
>> But strange thing, i had look on old drivers (StartHWFilter):
JS> ...
>> If there any problem, it is maybe because of another firmware? Because
>> it means hw_sections is used on old drivers.

JS> The old driver/firmware did not support software section filtering.
JS> The bandwidth limit is in transferring data from card to PC, so
JS> hw_sections=1 is better (filtering happens on the card), but the
JS> downside is that the card does not do CRC check of section data.

>> JS> The bandwidth of the bus between av7110 and PCI is quite limited
>> JS> (I don't have exact numbers, but I think 10..15MBit/s). I guess you
>> JS> are close to that limit, and some insufficient error handling
>> JS> in the firmware causes the filter to stop when buffers are
>> JS> filled up with hw_sections=1. It shouldn't happen with
>> JS> hw_sections=0, though.
>> This problem happen, even if i assign to user separate PID, and he use
>> only up to 512 Kbit/s. Thats strange :(
>> Another thing, again, old firmware(?) working well (except 2.6 kernel
>> issues, and pc locking issue).

JS> I suspect the reason is stricter error checking in dvb_net.
JS> Check out dvb_net.c:dvb_net_sec() and compare the differences.

JS> Another possibility would be a bug in the software section filter,
JS> but I think it's rather unlikely.

I have checked, in any setting on hw_sections, when it have
packetloss, packets discarded i think not in dvb_net, because there is
no error on interface. My opinion - section packed packets is not
processed correct.

We have enabled debug in dvb_demux, and got many messages like this:

dvb_demux.c section ts padding loss: 68/68
dvb_demux.c pad data: 29 8d e8 20 e5 41 b2 a1 2e 55 05 12 a5 00 00 34 00 00 40
00 33 06 71 1a d1 42 78 1b c1 13 cc 38 00 50 71 48 54 73 cb 1f b2 31 0b 84 80 12 16 d0 32 ad 00 00 02 04 05 b4 01 01 04 02 01 03 03 00 70 a1 55 4c

another:

dvb_demux.c section ts padding loss: 21/910
dvb_demux.c pad data: 06 11 e7 1d 29 26 73 c9 ef 9a 5e 6d 3e c7 13 d9 ac ac 7d 17 97
dvb_demux.c section ts padding loss: 507/1649
dvb_demux.c pad data: 16 2c b3 3c e6 64 3e f4 0f 97 c6 58 b2 88 20 ae 96 9f 7b 27 bc 41 ac 5a 16 64 69 99 8a 14 a8 09 fb 1e a4 bf 5a c8 73 42 67 1f 5c 5d cd
dvb_demux.c section ts padding loss: 52/708
dvb_demux.c pad data: 96 79 53 50 ea eb 70 d9 82 51 91 37 71 2b b2 46 a2 12 36 46 5f dc 29 c7 c6 10 1a 23 da c0 c7 23 5f 04 ee 60 a9 e8 aa 79 5e 7d 0c 7a 91 2f 2b e6 15 03 eb 7b
dvb_demux.c section ts padding loss: 1063/1063
dvb_demux.c pad data: fa ac 71 37 d1 6d ba eb 2c 08 22 9f 26 e0 8e 97 70 98 9a c9 0d a4 3c 72 8d d9 e3 0e 0c eb 5d e0 51 e1 6f 28 bf 37 1c 6d c7 40 f4 39 32




-- 
Best regards,
 Denis                            mailto:nuclearcat@nuclearcat.com



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