-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Wiriadisastra escribió: > Also Ubuntu is trying > http://www.ubuntuforums.org/showthread.php?t=271532&highlight=upstart > Upstart instead of init now they seem to be heading to the direction of > running it fully. It will be interesting to see how it performs > hopefully it improves the boot process even more. I thought there was work in progress for a new init system, called initng if I recall correctly, which supposedly would load and process start up scripts in tandem rather than sequentially. Stuff which can be loaded all at once will be loaded at once, and that which require prior stuff is loaded when the reqs are met. I thought Fedora was going to use this type of init system instead of upstart (or upstart could be a new name for initng from what I can make out of that post). This with login-early would greatly improve boot up times. I thought some of these stuff is what makes XP boot so fast (at least concurrent loading of services and an early login, while the system finishes booting when the users start their sessions). > > Other factors I'm not sure why but fedora seems less responsive compared > to ubuntu. I'm not sure where to lay the blame. My comparative figures > come from playing games using cedega. > > Thats not to say fedora is bad I had worse results with vanilla debian. > Yet on boot up and responsiveness on the desktop it was great. > > Could it be kernel? I know ubuntu separates there server kernel's and > the desktop kernels? Is this an option? > Most certainly this is a kernel issue. I'm betting this has to do with the internal Hz value used in the kernel. This determines the tick frequency. By default the vanilla value is of 100Hz, and I believe the Fedora kernel also has this value. Increasing this value to 1000Hz improves a great deal the desktop "perceived performance", not actual desktop speed, but much greater interactivity. There are other values, but I believe (from reading some "performance patches" documentation and mailing lists, like that for Con Kolivas' patch) that the safe value for server machines is 100-200 Hz, while for desktop interactivity the recommended is 1000Hz. There was a time when the actual CPU speed would have a great impact on this (make Hz value half of that of CPU... If you had a 2 GHz CPU use a 1000Hz value, if you had a 1 GHz CPU use a 500 Hz tick value, and the like), I think this no longer applies. Plus there are lots of patches the Fedora kernel incorporates over a vanilla kernel which may induce a performance hit, most of them deal with security issues (security > speed). That's one of the reasons why I usually run custom built kernels (trying to keep most of Fedora's patches) with some other performance enhancement patches (beyond sources for instance). Wine and Cedega really benefit from a higher Hz tick rate and other enhancements found on CK-based and Andrew Morton's patches (though Andrew's patches are considered to be much more experimental stuff, while CK is considered to be stable stuff). The impact a kernel can have on a system's performance is quite big, however for the last couple kernel updates, I have not been able to tell any really significant difference (except for a few) between custom built kernels with additional patches and Fedora's stock kernel. Not even when patching without Fedora's patches and only applying performance enhancers to a vanilla kernel. One particular area that could be much better, though is the use of more current libata on fedora kernels, as S-ATA performance with stock kernels is not as high, another reason why I use custom kernels. Another reason why some times performance feels quite lower is due to the way many programs are built. In terms of linking. The more dynamically linked libraries a program requires, the more time it takes to load (see firefox's start up times!), however this should be addressed on FC6, which incorporates ways to boost load times of dynamically linked code, thanks to improvements on GlibC's routines. Some time it is strange that a GTK application in GNOME takes almost the same amount of time to load as Qt application (which has to load the KDE stuff if it requires it, like K3B). Loading up K3B and firefox usually take the same time (and lots of disk activity). The situation is only worse if you have a multilib system (like an x86_64 or PPC64 machine with 32-bit libraries and programs). In my case, 64-bit firefox loads many times faster than 32-bit firefox (because 32-bit firefox has to load up a bunch of other 32-bit libs too). I guess some programs may really benefit from statically linking, at least in terms of start up times. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFKaLWXM+XOp70dwoRApZsAJ93hy38smvBVtYCZLuumJdYU/xUxACghaTZ eN8/oCmsddEH4C2ghF+3d30= =YqBi -----END PGP SIGNATURE----- -- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list
