I'm happy that your system shows some better performance, after all
the new year is here to achieve some improvement.
BTW I started manual applying your ttf-ps modification patch to the
latest convergence driver sources from CVS. Are you still using the
old driver sources? IMHO newer sources are more stable.
About Latency and stability:
When you get improvement in PCI latency, here is short description
how did I calculate right latency for each PCI card and other PCI
devices integrated on the mainboard:
Frist do lspci -vvv, spot every line like:
Latency: 80 (2500ns min, 2500ns max), cache line size 08
You see, for this device having 2500ns min latency I've choosen latency 80.
Simple calculation leads to this:
2500 / 33 = 75.757575 => 80
choose first higher latency integer divisible by 8, therefore we get 80.
Why 128 For DVB cards:
Latency: 128 (3750ns min, 9500ns max)
3750 / 33 = 113.636363636364 => 128
Do that for all the PCI devices lspci can find.
For other PCI devices having uspecified min/max latency, set latency 48.
Latency is maximum number of PCI clock cycles that the card is allowed
to hold the PCI bus. When long transfer is exceeding latency time, card is
forced to postpone the part of transfer and if it has low or no internal
buffer it may loose data and packets. Depending on the driver this may
lead to unpredictable results. Some drivers+cards like network cards are
resistant to such conditions, but seems that DVB isn't.
min latency in ns is card's required minimum time to transfer a complete packet.
max latency in ns is card's maximum allowed time other PCI devices can hold
the PCI bus before the card will drop or loose data.
If sum of all latencies * 33ns in your system is greater that some card's
max latency, this card may have problems. In our case sum of all your
PCI latencies (48 + 128 + 80 etc) * 33ns should not exceed 9500 ns
otherwise DVB card will be deemed to loose data if all other PCI devices
become active in the same moment. I know it's a very tight requirement,
almost impossible to achieve in PC with all PCI slots occupied.
> After your comment, I've removed the NIC and set the PCI Latency to 128;
> then loaded the (modified) DVB drivers; again, there isn't any shared IRQ;
> the surprise is that VDR now works!!! and is possible to interact
> with it; playing old records works fine and while recording, the image/
> sound is OK, but the new records don't play well (starting from top of
> screen are three areas, the first from the record, the second a big
> "mesh of artifacts" and the third is the old and unmodified picture; seems
> as all PES packets are invalid somewhere and its "expasion" abort,
Maybe more precise pci tuning will enlarge the first, correct looking
part of the screen.
> without complet any frame). Thinking on HD performance, I tested it with
> 'hdparm -tT /dev/hda' and the results was about a 20% lower (HD read at
> ~10 MB/sec); a few seconds after the test end, I got the "normal" Kernel
This performace is normal and is a result of narrowing of the pci bandwidth
for HD due to DVB activity.
> Panic (by first time, the crash happened after about 10 minutes!!!).
>
> For the next attempt, I've added the NIC at the same PCI slot (no shared
> IRQ's) and forgot to change the PCI Latency; again, VDR works with my
Actually I have seen that I can cope with shared IRQ's (DVB+USB+NIC)
on the same IRQ, only not (DVB+DVB) on the same. I checked interrupt
sharing with very heavy system load and worked for me.
> Well, without understand anything :-(, now that the system sometimes
> works, seems that are more problems to solve.
> >Therefore, disabling onboard ARM of DVB-S completely and using just your
> >hardware modification one can get cleaner card behaviour free of strange
> >firmware and also cleaner driver structure. Then DVB-S would work in Budget
> >only mode and should be much more stable.
>
> But we want also the "transfer mode" and OSD !, to have the good image/
> sound that have the premium cards!; that's, have the best of both cards,
> on one :-).
Of course, option to disable ARM would be of good just during development
phase, to have something stable (with faster CPU, one can use mplayer to view,
quality is excellent). and then continue development towards stabilization
of OSD.
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
