[Fedora-marketing-list] Fedora Core 6 Pre release review

Gian Paolo Mureddu gmureddu at prodigy.net.mx
Mon Oct 9 01:16:06 UTC 2006


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




More information about the Fedora-marketing-list mailing list