Hello out there !
Is it possible to speed up the vdr start (e.g. on my system) ??? I'm running vdr on a SuSE 8.2 System with 2.4 Kernel driver.
The start of the runvdr script is initiated by a runlevel script (runlevel 3 and 5).
It took about 90 seconds until i got a picture. Here is my runlevel order:
S01random -> ../random S02network -> ../network S03syslog -> ../syslog S04fbset -> ../fbset S05lircd -> ../lircd S06vdrRunlevel -> ../vdrRunlevel S07hotplug -> ../hotplug S08resmgr -> ../resmgr S09portmap -> ../portmap S12vdrconvert -> ../vdrconvert S13alsasound -> ../alsasound S13sshd -> ../sshd S14joystick -> ../joystick S14kbd -> ../kbd S14postfix -> ../postfix S14splash -> ../splash S15atd -> ../atd S15cron -> ../cron S15fam -> ../fam S15nscd -> ../nscd S16xdm -> ../xdm
vdr is started at position 6 but on the console i see jobs as alsasound and joystick starting before i got a picture.
How can i speed up the starting of the dvb driver and vdr ?
When i run the runvdr script manually, it took also a few seconds before the picture is shown on tv. Can this startup be speeded up ? Any hints are welcome.
Thanks in advance, Christoph
On Sun, Aug 07, 2005 at 09:29:04PM +0200, Christoph Hermanns wrote:
This topic has been covered in the German VDR wiki http://www.vdr-wiki.de/wiki/index.php/VDR_Bootzeiten.
For the record, my 900 MHz system starts up in 40 seconds. Some 11 or 12 seconds are wasted in the proprietary BIOS. I'd use LinuxBIOS if my mainboard were supported by it.
To shorten the boot time, I removed almost everything that is not strictly necessary: hotplug, usb drivers, X11, SMTP daemon, network file systems, fam, cron, syslogd, etc. Basically, only VDR+softdevice+DirectFB and OpenSSH are running. Most drivers are compiled into the kernel (currently 2.6.12.3).
How can i speed up the starting of the dvb driver and vdr ?
I'd also like to know if there's a way to postpone the scanning of existing recordings when starting up. The scan takes a couple of seconds on my system. It'd be nicer to start showing video while scanning.
Use OProfile to identify the bottlenecks in vdr startup.
Marko
Christoph Hermanns wrote:
Is it possible to speed up the vdr start (e.g. on my system) ??? I'm running vdr on a SuSE 8.2 System with 2.4 Kernel driver.
No security updates for 8.2 anymore, don't connect it to a network.
On 8.2 the simplest non-intrusive way probably is to just run the vdr and dvb init scripts from boot.local. You don't need to deactivate all the other boot scripts for that.
cu Ludwig
Am Sun, 7 Aug 2005 22:52:04 +0300 schrieb Marko Mäkelä marko.makela@hut.fi:
In http://www.vdr-wiki.de/wikiindex.php/VDR_Bootzeiten There are only times compared on this web-side, but no hints about the speedup tricks. But i read the topic on vdrportal.de before, my boot time was even longer before i reorder the runlevel scripts manually.
My intention is 1.st to start the dvb-driver and vdr and after that all other things, then it should be unimportant what is started after the vdr.
What is OProfile ? Is it part of any standard gcc package ? From where can I get OProfile ?
Christoph
Am Mon, 8 Aug 2005 09:31:02 +0200 schrieb Ludwig Nussel ludwig.nussel@suse.de:
How can i deactivate the network ? I doesn't have a network card in my pc. Can i easily change the name of the runlevel script from the network from S02network to s02network to deactivate it ? I have in mind that the network service is referenced in another runlevel script....but i don't have it in my mind which script this was.
Oh, that's a good hint. I will try this....thanks.
Regards, Christoph
Hi,
Am Dienstag, den 09.08.2005, 19:00 +0200 schrieb Christoph Hermanns:
Here few simple hints : * run any vdr-nonrelevant services like ssh after vdr, * deactive/reduced automated hardware detection/probing * install dvb-driver on kerneldir, and load only necessary driver (originial buildscript from dvb-driver load all frontends)
Me help http://www.bootchart.org/ to find some bottleneck on startup... It's produce a chart like this http://deltab.de/vdr/bootchart.png
HTH, Andreas
On Tue, Aug 09, 2005 at 07:00:24PM +0200, Christoph Hermanns wrote:
OProfile http://oprofile.sourceforge.net/ is a continuous profiler that is independent of any compiler. It merely produces more readable output if you compile the code with gcc -g. No compile-time, link-time or run-time instrumentation is needed, as is the case with gprof, efence and valgrind, respectively. Instead, OProfile makes use of the performance counters embedded in any modern processor (I guess Pentium and later). The performance penalty depends on the accuracy requested, but typically it is a few percent only. The tool is comparable to DEC (then Compaq then HP) DCPI and Intel VTune.
I've used OProfile on Intel Celeron, Intel Pentium M and AMD Opteron, maybe even the AMD K6-2, on 2.4 and 2.6 series kernels. Be sure to enable the local APIC, or otherwise the NMI based performance counter interrupts won't be available. On my vdr box, I have tuned the softdevice plugin based on OProfile measurements.
Generally, for measuring start-up bottlenecks, I think you'd better use bootchart. I haven't tried it, since apparently it hasn't been packaged for Debian GNU/Linux.
Marko
Christoph Hermanns wrote:
Nowadays one does not change runlevel links manually. chkconfig or insserv will do it for you.
cu Ludwig
The syslog runlevel script references to the network service, so if i want to decativate the network then i must delete this reference from the syslog runlevel script, is this correct ? Can i do this without getting into other problems ?
Regards, Christoph
Am Wed, 10 Aug 2005 09:00:25 +0200 schrieb Ludwig Nussel ludwig.nussel@suse.de:
Christoph Hermanns wrote:
Yes, alternatively you could add a dummy script that provides network.
Can i do this without getting into other problems ?
Should be safe.
cu Ludwig
hi,
Marko Mäkelä writes:
I tried to check where all the cycles in the VDR box go:
CPU: P4 / Xeon, speed 2398.74 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000 samples cum. samples % cum. % image name app name symbol name 47908471 47908471 27.5110 27.5110 vmlinux vmlinux get_offset_pmtmr 13718848 61627319 7.8779 35.3889 libc-2.3.2.so libc-2.3.2.so (no symbols) 13160494 74787813 7.5573 42.9462 xineplug_post_tvtime.so xineplug_post_tvtime.so DeinterlaceGreedy2Frame_SSE 8346769 83134582 4.7930 47.7392 vmlinux vmlinux sysenter_past_esp 5992342 89126924 3.4410 51.1802 libpthread-0.60.so libpthread-0.60.so __pthread_mutex_unlock_usercnt 4959342 94086266 2.8479 54.0281 libxine.so.1.12.0 libxine.so.1.12.0 yv12_to_yuy2_mmxext
I wonder why 27.5 % of samples go to get_offset_pmtmr... It seems to be found in /usr/src/linux-2.6.9/arch/i386/kernel/timers/timer_pm.c
Would this be normal, or what should I trim?
yours, Jouni
-
Andreas Brachold -
Christoph Hermanns -
Jouni Karvo -
Ludwig Nussel -
Marko Mäkelä