[vdr] lagged responce on Nexus 2.2

Jon Burgess 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
/proc/32037/task/32037/status:SleepAVG: 88%
/proc/32037/task/32058/status:SleepAVG: 89%
/proc/32037/task/32059/status:SleepAVG: 98%
/proc/32037/task/32060/status:SleepAVG: 98%
...

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.

	Jon



More information about the vdr mailing list