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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
