[vdr] lagged responce on Nexus 2.2
jburgess at uklinux.net
Wed Oct 5 20:41:46 CEST 2005
Vladimir Shved wrote:
> I'm trying to figure out why starting recording on budget card would fix
> this lagged behavior on FF card. Its like something flushes/clears the data
> pipe to FF card when I start recording on budget card, the FF card starts to
> respond very fast and without pauses. I guess the issue is specific to my
> setup only, possibly an issue with PCI bus transfers. I'm going to try to
> move my FF card to another system and see how it behaves there.
I suspect it is a subtle timing problem myself. I suspect that it is
some excess IO being done on one of the DVB devices. I'm guessing that
excess calls to read/write/ioctl's would probably show up as excess "wa"
time with no real block IO.
If you run a non NPTL system (or start the progrma as
"LD_ASSUME_KERNEL=2.4 vdr") then you may be able to track down which
thread is causing the problem since each thread will then appear in the
top output with an individual PID.
While poking in /proc I think I found a way to get some similar
information about the thread activity on NPTL systems too. try:
[root at shark ~]# grep SleepAVG /proc/`pidof vdr`/task/*/status
If you set your syslog.conf file to log debug messages then you should
be able to cross reference this using VDR thread ID's in /var/log/messages.
Alternatively you might be able to get a feel for what is happening by
attaching GDB and doing a few ctrl-c / continues. By the law of
averages, code which is taking most CPU time is most likely to be
running when you interrupt the program.
Alternatively you might try briefly running strace on VDR while it is
mis-behaving and again when it is running normally. If you compare the
system calls being done in the two situations you may be able to narrow
down what is using all the excess CPU.
The problem with all of these approaches is that you'll be overwhelmed
with data so it may make it tricky to see what is really going wrong.
More information about the vdr