Re: [vdr] Vdr or driver performance dropout
On 01 Feb 2007 Reinhard Nissl [EMAIL PROTECTED] wrote: Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. I don't think that the problem is related to anything on VDR side. AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout. I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation. Budget cards doesn't have this limitation, they can transfer the full transponder without problems. Regards. -- Stefan Huelswitt [EMAIL PROTECTED] | http://www.muempf.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Stefan Huelswitt kirjoitti: On 01 Feb 2007 Reinhard Nissl [EMAIL PROTECTED] wrote: Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. I don't think that the problem is related to anything on VDR side. AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout. I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation. Budget cards doesn't have this limitation, they can transfer the full transponder without problems. I know the performance was better when I was using vdr-1.3.22. I know I had 9 recordings going on and still I was able to watch a previous recording and I was using a slower cpu and a ff card. Ofcourse my recent test does prove your point, hence the question what is the best combination of hw and sw?. \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Kartsa schrieb: Stefan Huelswitt kirjoitti: On 01 Feb 2007 Reinhard Nissl [EMAIL PROTECTED] wrote: Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. I don't think that the problem is related to anything on VDR side. AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout. I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation. Budget cards doesn't have this limitation, they can transfer the full transponder without problems. I know the performance was better when I was using vdr-1.3.22. I know I had 9 recordings going on and still I was able to watch a previous recording and I was using a slower cpu and a ff card. Ofcourse my recent test does prove your point, hence the question what is the best combination of hw and sw?. Guess the best would be if you could/would be able to limit the possible number of recordings on a single card (or one would be able to set a limit for FF Cards or a fixed limit would be set in VDR at compile time) Then you could have a combination of FF and budget cards like most here have most likely. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Kartsa kirjoitti: Kartsa kirjoitti: Marko Mäkelä kirjoitti: In any case, you could profile the old and new version of vdr and see if there is any obvious difference. I'll have to take that into consideration. I'll have to download the old version and all that :) I was unsuccesfull with setting up an environment where I could run vdr-1.3.22. It just exits with exit code 2 with no other explanation in. It tells me to turn off NPTL by setting LD_ASSUME_KERNEL=2.4.1 and then all I get is error while loading shared libraries to about any command I try. And then cannot open shared object file: No such file or directory and depending on the command the library file varies. So no comparison :( This thread changed to talking about different issues like ati and xine which are actually far from the original meaning of my post. I still have this performance issue. I could not make the comparison with earlier vdr version but I did do some profiling. I did a seven minute session where I had 5 test recordings which started one minute apart and ended at the same time. After each recording had started I tested the responce of remote by just pussing menu button. After three recordings there began to be delay in menu appearance and after fourth recording the menu came up in pieces and after fifth recording there were no menu or if it ever did appear after several menu presses it was incomplete. This can be seen in the log (timeout waiting in LoadBitmap). Playback of a recording started to have small problems after third recording started and with four and five simultaneous recordings you really do not want to wath a movie like that. This is the log during the test: Mar 3 21:34:20 localhost kernel: oprofile: using NMI interrupt. Mar 3 21:35:00 localhost vdr: [2389] timer 1 (1 2135-2142 'TestRec1') start Mar 3 21:35:00 localhost vdr: [2389] record /srv/vdr/TestRec1/2007-03-03.21.35.50.99.rec Mar 3 21:35:19 localhost vdr: [2389] replay /srv/vdr/@Seabiscuit_-_amerikkalainen_legenda/2007-03-03.21.22.50.99.rec Mar 3 21:36:01 localhost vdr: [2389] timer 2 (2 2136-2142 'TestRec2') start Mar 3 21:36:01 localhost vdr: [2389] record /srv/vdr/TestRec2/2007-03-03.21.36.50.99.rec Mar 3 21:37:00 localhost vdr: [2389] timer 3 (7 2137-2142 'TestRec3') start Mar 3 21:37:00 localhost vdr: [2389] record /srv/vdr/TestRec3/2007-03-03.21.37.50.99.rec Mar 3 21:38:00 localhost vdr: [2389] timer 4 (8 2138-2142 'TestRec4') start Mar 3 21:38:00 localhost vdr: [2389] record /srv/vdr/TestRec4/2007-03-03.21.38.50.99.rec Mar 3 21:39:00 localhost vdr: [2389] timer 5 (9 2139-2142 'TestRec5') start Mar 3 21:39:00 localhost vdr: [2389] record /srv/vdr/TestRec5/2007-03-03.21.39.50.99.rec Mar 3 21:39:21 localhost kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1 Mar 3 21:40:19 localhost kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1 Mar 3 21:40:59 localhost last message repeated 2 times Mar 3 21:42:03 localhost vdr: [2389] timer 1 (1 2135-2142 'TestRec1') stop Mar 3 21:42:03 localhost vdr: [2389] timer 2 (2 2136-2142 'TestRec2') stop Mar 3 21:42:03 localhost vdr: [2389] timer 3 (7 2137-2142 'TestRec3') stop Mar 3 21:42:03 localhost vdr: [2389] timer 4 (8 2138-2142 'TestRec4') stop Mar 3 21:42:04 localhost vdr: [2389] timer 5 (9 2139-2142 'TestRec5') stop Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (1 2135-2142 'TestRec1') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (2 2136-2142 'TestRec2') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (7 2137-2142 'TestRec3') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (8 2138-2142 'TestRec4') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (9 2139-2142 'TestRec5') During the test CPU idle was over 90% all the time. I used oprofiler during the test and these are the results: CPU: P4 / Xeon, speed 3192.31 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 GLOBAL_POWER_E...| samples| %| -- 145068 47.4769 vdr GLOBAL_POWER_E...| samples| %| -- 137420 94.7280 vdr 7648 5.2720 anon (tgid:2389 range:0xfa6000-0xfa7000) 99854 32.6796 libc-2.5.so 35565 11.6395 libpthread-2.5.so 9336 3.0554 no-vmlinux 2888 0.9452 libcrypto.so.0.9.8b 2430 0.7953 oprofiled GLOBAL_POWER_E...| samples| %| -- 2419 99.5473 oprofiled 11 0.4527 anon (tgid:3372 range:0xfb9000-0xfba000) 2269 0.7426 libqt-mt.so.3.3.7 1544 0.5053 sshd GLOBAL_POWER_E...| samples| %| -- 1418 91.8394 sshd 108 6.9948 anon (tgid:3027 range:0x2a9000-0x2aa000) 14 0.9067 anon (tgid:3080 range:0x4a6000-0x4a7000) 4 0.2591 anon (tgid:3385
Re: [vdr] Vdr or driver performance dropout
hi, Seppo Ingalsuo writes: Jouni Karvo wrote: Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. I wonder if this would help in xorg.conf Device section Option UseEvents True This alone did not help, but I got this tip and it helped to my random video freeze problems with Nvidia binary driver and Xv. changing from xvmc to xv did. thanks. Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Jouni Karvo wrote: Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. I wonder if this would help in xorg.conf Device section Option UseEvents True (from http://www.gossamer-threads.com/lists/mythtv/users/242086) I got this tip and it helped to my random video freeze problems with Nvidia binary driver and Xv. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
hi, I have also currently the responsiveness problem. I have a P4 2.4GHz which runs at aout 20% load, so it should not be a performance problem. Currently home-made lirc, vdr-xine and 1.4.1 (and that's why I haven't reported before you started complaining, as I have not had the energy to upgrade lately). Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. For me, the vdr watchdog helps, but it definitely is not a DVB-driver problem, as I have modified runvdr to _not_ to reload DVB drivers, as that never helps anything anyway. yours, Jouni -- http://www.tkk.fi/%7ekex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Hi, Jouni Karvo wrote: I have also currently the responsiveness problem. I have a P4 2.4GHz which runs at aout 20% load, so it should not be a performance problem. Currently home-made lirc, vdr-xine and 1.4.1 (and that's why I haven't reported before you started complaining, as I have not had the energy to upgrade lately). Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. For me, the vdr watchdog helps, but it definitely is not a DVB-driver problem, as I have modified runvdr to _not_ to reload DVB drivers, as that never helps anything anyway. Are you using xine's video output driver xxmc? I experience deadlocks with this driver on either nVidia or Via EPIA hardware. For example, when you replay a recording and press the pause button: the pause symbol (OSD) will never appear on screen, input_vdr's RPC thread blocks forever, vdr-xine waits for the RPC result while VDR is caught in cXineOsd::Flush(). I'm working on this issue but still do not have a complete solution to it: the deadlock is gone, but the OSD is still not shown on screen. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
hi, Reinhard Nissl writes: Are you using xine's video output driver xxmc? yes, I am. I experience deadlocks with this driver on either nVidia or Via EPIA hardware. For example, when you replay a recording and press the pause button: the pause symbol (OSD) will never appear on screen, input_vdr's RPC thread blocks forever, vdr-xine waits for the RPC result while VDR is caught in cXineOsd::Flush(). hmm... it has once locked, and sometimes the pause symbol does not show, but a quick re-pauseing fixes it. I wonder if the slow responses to remote clicking can then be due to the same, or are there several unrelated issues... yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Marko Myllymaa [EMAIL PROTECTED] wrote: Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. And third problem which have gone worse is weird black output I get. Vdr is up and running, osd is shown, but no live video. Changing channels are very slow (ie. vdr shows the info screen very long). Restarting vdr corrects this (propably reloading the drivers is the actual fix). This has happened with 1.3.19 about once a week. Now with 1.4.4 I had to restart vdr everyday. That's not so nice. me 2 also on this point. exactly the same behalfier. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote: Marko Myllymaa [EMAIL PROTECTED] wrote: Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. What type of remote receiver are you using? I've had delays with some remotes but not others: 1. USB2 Nova-T receiver with the remote plugin: works most of the time but goes through phases where it seems to be ignoring keypresses so I press the button again (several times!) and then a few seconds later it catches up and I end up in a different menu, etc. to what I wanted! Works OK but can be very annoying! Also gives the wrong codes, i.e. keys, sometimes which can be confusing! 2. PCI Nova-T receiver through lirc: works much better than the USB receiver but does feel as if there is a lag between pressing keys and things happening. Does sometimes do the buffering thing mentioned above but nowhere near as bad. 3. Home-made simple lirc receiver on a serial port through lirc: much more responsive than the two proper remote receivers! I would recommend this to anyone who can build the simple receiver. Finally got round to building another one for my main vdr system and it is so so much better now (was using the USB receiver previously). I never worked out where the delays occurred, i.e. whether it was down to the DVB drivers or vdr itself. Seeing as the lirc receiver works fine, I'd be suspicious of the driver. The above observations are on a 1.2 GHz Via Epia system, so not that powerful all things considered. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Laz [EMAIL PROTECTED] wrote: On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote: Marko Myllymaa [EMAIL PROTECTED] wrote: Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. What type of remote receiver are you using? I've had delays with some remotes but not others: home brewed ir receiver on serial port using lirc. the same as you say worked best for you. i'm sure the problem is not on the IR side but on vdr, as that setup was not changed between vdr upgrades. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Clemens Kirchgatterer kirjoitti: Laz [EMAIL PROTECTED] wrote: On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote: Marko Myllymaa [EMAIL PROTECTED] wrote: Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. What type of remote receiver are you using? I've had delays with some remotes but not others: home brewed ir receiver on serial port using lirc. the same as you say worked best for you. i'm sure the problem is not on the IR side but on vdr, as that setup was not changed between vdr upgrades. I have home brewed also and I either do not think IR side is the problem. The delays became the longer the more recordings are on simultaneously. I just tested just to be sure that after second recording the playback of another recording starts to snap crackle and pop both sound and picture. Very small but noticeable. After third recording responces to remote are either very sluggish or in some remote actions nothing happens. And as I said earlier this behaviour is similar in PIII 550 and AMD 3000+. And actually I think what ever is causing this may also be the reason for the AV sync problem I reported in another thread. I mean after the third recording AV sync is about all the time out of sync or atleast its no fun to watch. I'll report about this in the related thread. \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Thu, 1 Feb 2007, Kartsa wrote: Marko Mäkelä kirjoitti: On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources. In any case, you could profile the old and new version of vdr and see if there is any obvious difference. I'll have to take that into consideration. I'll have to download the old version and all that :) Hi, I'll have to agree with this performance drop. I have very slow machine (P1 166 and 64 megs ram), it has fujitsu-siemens FF dvb-c card. I used 1.3.19 for very long time and it worked perfectly. Some time ago I decided to upgrade to 1.4.4, wrong decision. Now I cannot watch dvd while vdr is recording tow recordings at the same time. No problem here with earlier version. Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. And third problem which have gone worse is weird black output I get. Vdr is up and running, osd is shown, but no live video. Changing channels are very slow (ie. vdr shows the info screen very long). Restarting vdr corrects this (propably reloading the drivers is the actual fix). This has happened with 1.3.19 about once a week. Now with 1.4.4 I had to restart vdr everyday. That's not so nice. Sometimes vdr finds the live video, after pressing 'ok' or something else. Is there any cure for this? (Other than making script to send some channel number every hour, unless theres user activity...) I haven't tried to do _many_ recordings at same time with vdr-1.4.4, with 1.3.19 I tried, and I could record 4 channels at the same time and watch a recording. Watching 5th channel live was a bit jerky, but hey, it's a very low end machine... Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Fri, Feb 02, 2007 at 04:05:10PM +0200, Marko Myllymaa wrote: On Thu, 1 Feb 2007, Kartsa wrote: Marko Mäkelä kirjoitti: On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources. In any case, you could profile the old and new version of vdr and see if there is any obvious difference. I'll have to take that into consideration. I'll have to download the old version and all that :) [snip] Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. I've experienced this once or twice on my setup (softdevice -vo dfb:mgatv, probably some late vdr 1.3.x, on 900 MHz Celeron with 128 or 256 MB of RAM). I sent a command via SVDRP, and it took something like a couple of minutes for VDR to react. As far as I remember, it wasn't recording anything - only replaying a recording or viewing live stream. This may of course be related to some anomaly of softdevice. In the past 2 years that I've used vdr and softdevice, a few times softdevice has failed to start properly. It would play about 0.5 to 1 frames per second and use very little CPU. Restarting VDR has always helped. Before setting up oprofile, you could attach strace to a running vdr and capture the output to a file for a few seconds. Do this for both the old and the new version of vdr, and see if you can find anything. The output will probably vary between runs, so attempts to use tools like diff may be futile. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On to, 2007-02-01 at 19:29 +0200, Kartsa wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Hi, Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote: Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame. Mrako ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Reinhard Nissl kirjoitti: Hi, Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Marko Mäkelä kirjoitti: On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote: Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: Marko Mäkelä kirjoitti: I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources. In any case, you could profile the old and new version of vdr and see if there is any obvious difference. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Marko Mäkelä kirjoitti: On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources. In any case, you could profile the old and new version of vdr and see if there is any obvious difference. I'll have to take that into consideration. I'll have to download the old version and all that :) \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
