59 replies to this topic

[Dimitrij]

I guess Bri just won't believe us until he finds out for himself. Ah well, he'll learn two things then...

+1

[Bri]

I will believe it if anyone says he has installed the root fs on internal hard disk and tried it out. :-)
UBI fs and JFFS2 uses compression. How does this influence the time to load a file? Did anyone tried to investigate why enigma2 needs so long to start? Is the driver initialization, dynamic linking, python scripting initialization, hardware scan, loading the settings or something else the reason? I can not believe that a 400MHz MIPS CPU is not able to boot linux and start a TV application in 30s.

[nietgiftig]

I can not believe that a 400MHz MIPS CPU is not able to boot linux and start a TV application in 30s.

That's the spirit.

And now we are all waiting for the moment you show us how to do it.
Success!!!

[Erik Slagter]

LOL! Honestly, we also don't understand how DMM managed to make it so slow, but apparently they succeeded!

[Bri]

I thought you are enigma2 hackers knowing every line of the source code and the only thing I have to do is to ask the right questions. ;-)

Erik you said that suspend to disk is not supported for MIPS in the kernel. I think this is not correct. In the kernel configuration I found the following lines for MIPS:

config ARCH_HIBERNATION_POSSIBLE
def_bool y
depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP

config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP

Suspend to disk seems to be possible if SMP is disabled or support for hot plug CPUs is enabled. The question is is it enough to compile the support for hot plug CPUs in the kernel or do we need hardware support for hot plug CPUs? This might be a second chance to boot in 30s if other fails.

[Rob van der Does]

Not being a specialist (even far from that) I noticed epg,dat and channel/bouquetlist to be very important to boottime (and E2 restart time of course).
If epg.dat is small (or even absent) and only a few channels are in the settings booting is even very fast.

[Erik Slagter]

Hmmm interesting on itself, but you really wouldn't want to turn off the second core/thread only for this!

I've been using suspend-to-disk for some time on linux (i386 arch) and I can say, don't bet your money on it, it's actually quite slow and sometimes it tends to crash.

[Bri]

My new hard disk arrived yesterday. I installed openpli on hard disk and found some adjustments to speed up the boot process. My box needs 40s now.(27s linux, 13s enigma2)

- installation on hard disk: saves 3s over all (mount needs some seconds therefore the speed gain is not as high as expected, most time is needed for the large 1.4TB partition, might be mounted later in background to save additional 3s)
- static ip address: saves 10s-12s if network cable is not plugged in, otherwise about 2s
- samba & dropbear disabled in rc3.d, getty disabled in inittab: 2s
- removed all not needed satellites in file satellites.xml (good advice from SatKiekerd): saves 3s

Reading XML setting files in enigma2 is slow. I guess there is much room for optimizations. Many parts of enigma2 are written in python. Not a good idea for an embedded system with limited CPU power. I will try to rewrite some slow parts in C++.

[pieterg]

xml parsing has been implemented in c++, indeed for performance reasons

[Bri]

I know. But parsing a 6500 lines XML file is slow in C++ too. An easy to parse ASCII file format might be better because there is no overhead for a DOM in memory. XML has many advantages for the programmer. But the user does not care about the format the data is stored. The user only sees a program that needs 20s to start.
As far as I know the satellites file is parsed in C++ but the data is stored in a python data structure. Within the next few days I will try to locate the bottlenecks with a profiler.

[MiLo]

Reading and parsing the satellites.xml file takes about 2 seconds. I tried replacing it with a Python binary (pickle) file, which still took one second to load, and had some nasty side-effects. Apparently, loading that file also does some initialization as a side-effect, and skipping it results in malfunction.

Actually, the data from satellites.xml isn't being used at all, until you go into sat searching and stuff. So it's a waste of CPU and memory to begin with. That's a much better path to pursue - don't load it at all!

[pieterg]

My intention is to load sats.xml in a workerthread, to make proper use of SMP.
starting e2 consumes 100% on just one of the cores.

[Erik Slagter]

So enigma starts faster on a custom slimmed down sats.xml? Good to know...

[daddelfalk]

Hi,

found a german wiki for this research process:

http://wiki.blue-pan..._aus_meiner_Box

[Robinson]

- removed all not needed satellites in file satellites.xml (good advice from SatKiekerd): saves 3s

Hi guys,

What's the best way to go about removing unwanted satellites from satellites.xml file? I thought I could remove satellites using DreamBoxEdit but I think I can only remove individual transponders and not the whole satellites? Or do I just use my FTP application? In my case, it would be Total Commander.

And do I need to stop Enigma2 to be able to modify the file or is it not necessary?

[hemispherical1]

Dbedit should work, filter by the satellite you want to remove & all services, ctrl-a to select all (all visible belong to the filtered sat) and delete. Save the results...

--
hemi

[MiLo]

found a german wiki for this research process:

Be aware that this wiki is not about OpenPLi, a lot of the things mentioned there won't apply. For example, multiboot will only make it slower, unused skins have no effect at all, and skin parsing in OpenPLi is way faster anyway so don't expect much there.

[Erik Slagter]

The best way to remove unused satellite-positions in the sattelites.xml file, is to stop enigma (init 4), load the file in an editor, remove the unused positions, write the file and then start enigma again (init 3).

Or download an alternative satellites.xml file and overwrite the existing one, then restart enigma.

[greatred]

found a german wiki for this research process:

Be aware that this wiki is not about OpenPLi, a lot of the things mentioned there won't apply. For example, multiboot will only make it slower, unused skins have no effect at all, and skin parsing in OpenPLi is way faster anyway so don't expect much there.

Hi,

and what about all the "unused" localizations found in usr/share/enigma2/po? I always tend to remove all of them except from en, but obviosuly, next Software Update will place them all again. Would that be possible to implement in OpenPLi a function where only the current used language will be kept?
Eventually please correct me if I`m wrong and the remaining localisations dont influence the boot process but are only occupying the flash memory space.

[MiLo]

Can't imagine that unused languages have any effect (other than occupying flash space). It only accesses the language file you actually use. So unless someone proves me wrong, I see no reason to build such a thing.