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@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
