[linux-dvb] Re: Quality of dvb-kernel in upcoming 2.6

[Emard <emard@softhome.net>]

HI Michael!!

> These patches replace the static firmware blob with the generic 
> "firmware_class" loading mechanism. They haven't been updated lately, 
> because there are still problems with it. You shouldn't apply these 
> patches (or at least read README.firmware... ;-)

MMmm seems interesting, now I got one idea around this, namely
when using budget-patch I first load dvb-ttpci because it
loads the firmware and then remove dvb-ttpci and load budget-patch 
(both of them react on the same PCI:id of course, 
bacause they are two different drivers for the same card)

Even though I'm not using most of its sophisticated functions, 
firmware is good to have loaded because of diseqc.

Now, can I load dvb-s firmware from the budget-patch directly, 
that would be much better than loading and unloading dvb-ttpci ?

> Please try again with a fresh 2.6.0-test8 -- there, all the latest 
> patches have gone in. 2.6.0-test7 is fairly old.

Seems the development happens at high pace, it didn't took me so
much to install new distribution and get *-test7 running, do few
sensible tests while in the meantime they popped new test release

> Yes, this should be improved, ie. proper module locking for both 
> frontend devices and drivers. Jon Burgess did a first try, but 
> unfortunately the missed something, so the usage counter was screwed 
> after a few device uses.

;-> I see, I forgot to try several devices uses :)))

> Hm, I just tried with 2.6.0-test8 and had no problems recording 
> something. No skips, but I admit that I have a perfect signal here, so 
> users with weak signals might have problems that I haven't seen yet.

Hmmm I should also be getting 100% good reception on weather with no rain.
When it rains heavyly, some weaker transponders (radio harmony.fm on astra
tend to get packets missing, but stronger transponders like ZDF are still
100% even on bad weather)


> The crc-checking code is currently broken in 2.6, but I don't know if 
> network stuff uses crc-checking by default.
> 
> You might want to try to "makelinks" the dvb-kernel driver, because 
> there have been fixes that I haven't sent to Linus yet.

I see! (before I had just patched the kernel)

> Probably something within in the network device subsystem, which has 
> changed in 2.6. recently. Probably this is a bug in the driver which did 
> not look bad in 2.4...

:) some lucky mix of circumstances in 2.4 gave that nice behaviour.
dvb0_0 went away as if it were ppp0 disappearing after modem hangup :)


> >The mysterious packet loss can be seen with e.g. ethereal when the
> >whole bandwidth is captured and then attempted to follow. (click on
> >some tcp entry and select "Time-sequence graph (Stevens)"
> >On X axis is time, on Y axis is byte offset. Discontinuities on
> >Y axis. Packet loss denote vertical jumps or missing vertical dots 
> >on the graph. Here I enclose 2 png's of ethereal, one having
> >no packet loss and the other I draw red arrows at some packet loss 
> >points, you could spot more...
> 
> Unfortunately, I don't have the time to work on the network stuff, so 
> feel free to investigate this further and send a patch. 8-)

This is the insofar the investigation (on 2.4)

I loaded and got running ultrafast mmap edition of the packet
capture library, no noticeable help to the loss!!

I encreased input IP network buffers to over 100-fold their
default values  (rmem_max et co.), used up over 300 MB of 
buffer area on a generous 1 GB P4 2.4 machine, used IP filtering to 
receive just some real small amount of traffic 
below 1 Mbit but no way to get rid of the loss.

I checked the reception during the network loss tests and it seems
to be good.

I took the low level dvbtraffic routine posted around here, based
on raw TS analysis, which shows active PIDs and associated traffic 
- seems OK.

also the network reception with iptraf seems to give the statistic
that is within the measurement error the same thing that low level
dvbtraffic gives - seems OK.

Packet loss definitely has some repeatable pattern, and it steeply
rises when provider rises the PID bandwith from cca 10 Mbit (almost no
loss) to cca 40 Mbit (over 20% loss). It seems to me that the network 
packet decoding hack in dvb_net.c does not cover some cases that can 
occur in practical transmission. 
I wish I knew more of ethernet packet structure and dvb encapsulation.
We definitely would benefit of some low-level IP and encapsulation 
network guru

SOMETIMES, regardless of high input traffic, loss seems to 
VANISH AND RECEPTION IS 100% CLEAR!!!! It can last for an hour
and the loss appears again.

I got to the point that I applied 2 cards in parallel 
(antenna goes to LNB IN of budget-patch and from its LNB OUT signal 
goes into LNB IN of normal budget card) and, imagine, 
BOTH CARDS HAD THE SAME NETWORK PACKETS MISSING!!

Maybe the above 2 cards - same loss phenomenon could be the
most meritable for locating the point of the problem.

After measurement with the 2 cards it is clear to me that the 
loss doesn't come statistically like from bad reception/too weak 
signal for some tuner/decoder or by random dropping by the kernel going
running low on input buffers. if it does, then 2 cards would
easily cover the missing 10-20% of missing packets.

(end of network saga episode, to be continued)

Emard


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