F8/9 6-16x slower than XP to boot

[Dimi Paun]

Folks,

I have reported in the past slow boot times. I have performed
some more tests that may help people improve the situation.

Hardware: 2x2.13 GHz Intel Core Duo 6400, 4GB RAM
Software: Fedora 8, running Innotek's Virtual Box
Virtual Hardware: 538MB RAM, 8GB HDD
OS in Virtual Box: Fedora 9 Beta and XP

Test was to boot the box and start Firefox to the point where I can
interact with it (i.e. type in location bar).

Summary:
* F8 on real hardware, without BIOS time: 2:15
* F9 on virtual hardware: 7:00
* XP on virtual hardware: 0:22

For F8 boot, here is a breakdown of times:
0:00 -- Grub starts
1:25 -- login prompt
1:50 -- I can click on the Firefox icon
2:15 -- Firefox becomes usable

For F9 Beta boot, being so slow, I could record more details:
0:00 -- start of virtual box
0:45 -- "Welcome to Fedora" shows
1:30 -- udev finishes (took 45'!)
1:40 -- first graphics show (rhgb)
3:20 -- X restarts (I guess rhgb ends)
4:00 -- login prompt
6:15 -- Firefox icon is clickable
7:00 -- Firefox becomes usable

A few notes:
* I took out all times for user interaction
* I repeated the tests a few times, the results are stable
* For whatever reason, Fedora 9 Beta feels very sluggish in the
virtual machine (even the mouse stutters), whereas XP runs
extremely well. Maybe Innotek did some Windows-only optimizations?
* I measured to the point where I could interact with Firefox.
However, at that point XP appeared more responsive than Fedora,
even when compared to the Fedora that was running on the real
hardware, with a lot more RAM available.
* Even when comparing Fedora on real hardware vs XP on VM,
it took longer to just start Firefox in Linux vs. the entire
boot + starting of Firefox in Windows!

I'd be glad to provide more information if people are interested.

[Andrew Farris]

Post by Dimi Paun
0:00 -- start of virtual box
0:45 -- "Welcome to Fedora" shows
1:30 -- udev finishes (took 45'!)

It looks to me like Virtual Box has serious issues (bugs). This is absurdly
slow compared to my machines: macbook core 2 duo both as physical install and
vmware virtual machines (x86 and x86_64), and P4 2Ghz 1Gb rdram.

[Dimi Paun]

Post by Andrew Farris
It looks to me like Virtual Box has serious issues (bugs). This is
absurdly slow compared to my machines: macbook core 2 duo both as
physical install and vmware virtual machines (x86 and x86_64), and P4
2Ghz 1Gb rdram.

Oh, for sure there's something fishy in there. The only reason why I did
this test was that XP in VM was so fast (6x faster!) when compared to F8
on real hardware (with 8x more RAM) that I thought maybe somehow running
in the VM may be an advantage...

No matter how you cut it, we are at least 6x slower than XP to start.
Last time I brought this up, there were people suggesting that it's just
and impression, that XP is unusable for minutes after you login, etc.

I wanted to test this, and it didn't seem so. In fact, I found that even
though it was running in the VM, in XP I could click on the Firefox icon
within a few seconds from login, and browser will start quickly, and be
more responsive than the one started on F8 running on the real hardware.

Heck, XP boots in the VM faster than I can start Firefox on the real
hardware! (That happens after boot only of course, later on from a warm
cache it takes only 4sec to start Firefox vs. 1sec in XP)

[Dimi Paun]

Post by Andrew Farris
It looks to me like Virtual Box has serious issues (bugs). This is
absurdly slow compared to my machines: macbook core 2 duo both as
physical install and vmware virtual machines (x86 and x86_64), and P4
2Ghz 1Gb rdram.

Oh, for sure there's something fishy in there. The only reason why I did
this test was that XP in VM was so fast (6x faster!) when compared to F8
on real hardware (with 8x more RAM) that I thought maybe somehow running
in the VM may be an advantage...

No matter how you cut it, we are at least 6x slower than XP to start.
Last time I brought this up, there were people suggesting that it's just
and impression, that XP is unusable for minutes after you login, etc.

I wanted to test this, and it didn't seem so. In fact, I found that even
though it was running in the VM, in XP I could click on the Firefox icon
within a few seconds from login, and browser will start quickly, and be
more responsive than the one started on F8 running on the real hardware.

Heck, XP boots in the VM faster than I can start Firefox on the real
hardware! (That happens after boot only of course, later on from a warm
cache it takes only 4sec to start Firefox vs. 1sec in XP)

[Lubomir Kundrak]

Hi,

Post by Dimi Paun
* Even when comparing Fedora on real hardware vs XP on VM,
it took longer to just start Firefox in Linux vs. the entire
boot + starting of Firefox in Windows!

Not to devaluate your tests -- please bear in mind that we offer more
features and are much more secure than XP. I am wondering what the
results would be if you kickstarted fedora just with icewm and firefox
and compared that one.

NB: I bet my XT with 640K RAM boots Minix faster than my workstation
would boot XP. It's all about features again.

[Dimi Paun]

Post by Lubomir Kundrak
Not to devaluate your tests -- please bear in mind that we offer more
features and are much more secure than XP. I am wondering what the
results would be if you kickstarted fedora just with icewm and firefox
and compared that one.

They will be better, but I don't think by much -- it takes almost 1.5min
just to get to the point were we start GNOME, IceWM can't go back in
time. :)

And what features can we offer that we are willing to pay by an order
of magnitude in performance? (Firefox after boot in XP starts in 2-3s,
whereas in Fedora it takes 25-28s!).

The danger here is that we make ourselves feel better and ignore the
problem by saying we offer more features. 600% slower to start! I
remember the days back in 99 or around there, when Windows came on top
in performance. For months we tried to blame it on biased tests, etc.
Then the kernel folks got their act together and fixed the problem.

The same must happen here, and the first step is to acknowledge it.
This is a much more difficult problem I think then the other one,
and I'm afraid that RedHat is the only one capable to solve it (because
they employ enough key people in all the right places:
kernel/glibc/toolchain/GNOME). This is similar in the way to good thread
support that required tricky changes in kernel/glibc/toolchain.

Hey, come to think of it, we need Ingo to look at it! :)

I'm not even sure where the problem lies. Is PE inherently faster than
ELF? Is it the on-demand paging of apps that is done in the kernel under
Windows responsible for that much faster startup times? Do they have
that much better compilers/linkers? Or maybe better preloading from
disk?

I personally think a key piece in the puzzle is why is Firefox so
darn slow to load under Linux when compared to Windows?

[Eric Mesa]

I think it's a bit of a false comparison - give that they're running in
VMs. After all, F8 on the real hardware is only about 4 times slower. To
throw in my own experience, I have a self-built, pretty nice P4 running Win
XP and a cheap, $300, few years old Emachine running Fedora 8. If I start
them up at the same time, even counting the time it takes me to type in my
username/password on Linux (in Windows it just boots straight to the
desktop), I can use the Linux/Gnome computer up to a minute or more sooner
than I can Windows. Why? Because Norton Internet Security takes forever
and a day to start up and until it does, I can't do ANYTHING on my
computer. Even clicking the start button is a 20+ second wait. Norton is
essential to keep my computer running, so it would be unfair to compare it
to Windows without Norton. (BTW - I'm running Norton 2008 which runs a
heckuva lot faster than 2007)

And my Ubuntu machine (using upstart?) which is an under-powered laptop
starts up even faster than Fedora. So yeah, Fedora needs to work on startup
time, but I can be browing the internet/doing w/e I want a LOT faster in
Fedora than in Windows.

Post by Dimi Paun

Post by Lubomir Kundrak
Not to devaluate your tests -- please bear in mind that we offer more
features and are much more secure than XP. I am wondering what the
results would be if you kickstarted fedora just with icewm and firefox
and compared that one.

They will be better, but I don't think by much -- it takes almost 1.5min
just to get to the point were we start GNOME, IceWM can't go back in
time. :)
And what features can we offer that we are willing to pay by an order
of magnitude in performance? (Firefox after boot in XP starts in 2-3s,
whereas in Fedora it takes 25-28s!).
The danger here is that we make ourselves feel better and ignore the
problem by saying we offer more features. 600% slower to start! I
remember the days back in 99 or around there, when Windows came on top
in performance. For months we tried to blame it on biased tests, etc.
Then the kernel folks got their act together and fixed the problem.
The same must happen here, and the first step is to acknowledge it.
This is a much more difficult problem I think then the other one,
and I'm afraid that RedHat is the only one capable to solve it (because
kernel/glibc/toolchain/GNOME). This is similar in the way to good thread
support that required tricky changes in kernel/glibc/toolchain.
Hey, come to think of it, we need Ingo to look at it! :)
I'm not even sure where the problem lies. Is PE inherently faster than
ELF? Is it the on-demand paging of apps that is done in the kernel under
Windows responsible for that much faster startup times? Do they have
that much better compilers/linkers? Or maybe better preloading from
disk?
I personally think a key piece in the puzzle is why is Firefox so
darn slow to load under Linux when compared to Windows?
--
Dimi Paun <dimi at lattica.com>
Lattica, Inc.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

--
Eric Mesa
http://www.ericsbinaryworld.com
http://server.ericsbinaryworld.com
"Do not worry about those things that are outside of your circle of
influence. For since they are outside of your power to control them it is
simply a waste of time and energy to dwell on them. Instead, turn your
attention to those things that you can control and grow your influence in
those areas and you will see the effects begin to trickle out to those items
that were previously out of your power to influence." ? Eric Mesa inspired
by Covey's 7 Habits of Highly Effective People
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080328/55ddf0fb/attachment.html

[Emmanuel Seyman]

Post by Dimi Paun
The same must happen here, and the first step is to acknowledge it.

The first step is actually to eliminate variables in the test so as
to better isolate the problem. Can you run your test again with the
same platforms on real hardware ? That would eliminate any slowness
due to the virtual setup.

Emmanuel

[Balaji Ravindran]

Hi,

Yea accept,

1. What you might want to try is use either VM or real hardware, but if you
choose something stick to it, (meaning perform the tests for the OS's with
same specs) I'm sure you would have done this., am just asking you to double
check.

2. GNOME and XP has lot of different start-up services which might affect
the test results., SO i would suggest after the initial install of both OS,
disable any un-important startup services in both., and restart the test.
(When i say services it also includes, disabling any anti-virus blah blah
blah)

3. Perform the test in different VM's(VM's by different vendors) possibility
is that some vendors custom there optimizations for a particular OS, so by
performing the test on different VM's from various vendors we can come at an
average time, would lead to a better benchmark.

4. Perform the tests with KDE and XP, coz, that might be a more closer match
with XP's startup themes and processes.

5. Then running the test 2-3 times with the above procedures will give a
more accurate result, and will also help identify where exactly fedora is
slower.

(Am sure your findings are true, but inorder to help developers isolate the
problem requires more vigorous testing)

Am sure other people will also be helping in testing simultaneously, which
should reduce your burden a bit.

Thanks

Balaji R
On Fri, Mar 28, 2008 at 9:07 AM, Emmanuel Seyman <

Post by Emmanuel Seyman

Post by Emmanuel Seyman

Post by Dimi Paun
The same must happen here, and the first step is to acknowledge it.

The first step is actually to eliminate variables in the test so as

to better isolate the problem. Can you run your test again with the
same platforms on real hardware ? That would eliminate any slowness
due to the virtual setup.
Emmanuel
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080328/b8a72a32/attachment.html

[Oscar Victorio Calixto Bacho]

you can see phoronix benchmark

http://www.phoronix.com/scan.php?page=article&item=fedora_boot_perf&num=1

Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080328/0ff81b6c/attachment.html

[Jakub 'Livio' Rusinek]

Dnia 2008-03-28, pi? o godzinie 19:59 -0600, Oscar Victorio Calixto

Post by Oscar Victorio Calixto Bacho
you can see phoronix benchmark
http://www.phoronix.com/scan.php?page=article&item=fedora_boot_perf&num=1

Fedora is not a daemon of speed, but the speed is purpose-dependent.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: To jest =?UTF-8?Q?cz=C4=99=C5=9B=C4=87?=
=?UTF-8?Q?_wiadomo=C5=9Bci?= podpisana cyfrowo
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/d1a676f3/attachment.bin

[Martin Sourada]

Post by Jakub 'Livio' Rusinek
Dnia 2008-03-28, pi? o godzinie 19:59 -0600, Oscar Victorio Calixto

Post by Oscar Victorio Calixto Bacho
you can see phoronix benchmark
http://www.phoronix.com/scan.php?page=article&item=fedora_boot_perf&num=1

Fedora is not a daemon of speed, but the speed is purpose-dependent.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/ad296e49/attachment.bin

[Gianluca Sforna]

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

I am not sure rawhide kernels can be compared with official release
ones, as they usually carry debugging stuff which may ( or may not ;)
) justify that difference.

I also have to note they do not state what "spin" they used for the
Ubuntu counterpart; if it was the liveCD, we are comparing apples and
oranges

[Martin Sourada]

Post by Gianluca Sforna

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

I am not sure rawhide kernels can be compared with official release
ones, as they usually carry debugging stuff which may ( or may not ;)
) justify that difference.

Well, it probably does, but for F8 final it's 12MB/s which is still
about 2.5x less than in F5...

Post by Gianluca Sforna
I also have to note they do not state what "spin" they used for the
Ubuntu counterpart; if it was the liveCD, we are comparing apples and
oranges

They're comparing Fedora with Fedora. Ubuntu runs different (and less)
services and cannot be effectively compared to Fedora. In fact, if you
trim the services a bit you can gain similar boot times in F8 that are
in Ubuntu (bellow 30s), so I'd rather not compare the results for Fedora
with results for Ubuntu...

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/6377598c/attachment.bin

[Martin Sourada]

Post by Gianluca Sforna

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

I am not sure rawhide kernels can be compared with official release
ones, as they usually carry debugging stuff which may ( or may not ;)
) justify that difference.

Well, it probably does, but for F8 final it's 12MB/s which is still
about 2.5x less than in F5...

Post by Gianluca Sforna
I also have to note they do not state what "spin" they used for the
Ubuntu counterpart; if it was the liveCD, we are comparing apples and
oranges

They're comparing Fedora with Fedora. Ubuntu runs different (and less)
services and cannot be effectively compared to Fedora. In fact, if you
trim the services a bit you can gain similar boot times in F8 that are
in Ubuntu (bellow 30s), so I'd rather not compare the results for Fedora
with results for Ubuntu...

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/6377598c/attachment-0002.bin

[Alan Cox]

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

Alan

[David Nielsen]

Post by Alan Cox

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

I have a similar experience, my desktop machine has two 400 gb drives in a
mdraid RAID0 which hosts / and /home on lvm with dmcrypt enabled. With an
Ubuntu (Hardy, their current development release) install I can restore my
backup from my USB harddrive at 23mb/s, same setup using the current
Rawhide the transfer speed is a mere 13mb/s.

I am thinking it's this one:
https://bugzilla.redhat.com/show_bug.cgi?id=232843
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/ad08ebc9/attachment.html

[Dave Jones]

Post by Alan Cox

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

The idea of using bootchart to measure disk performance seems a bit suspect.
For example, FC5 had the readahead service enabled, so the disk got to do a
serialised burst of reading of a few hundred MB of data. Now that we don't have
that service, the disk isn't being used as much, so we never see those sorts of peaks,
leading to more 'spiky' bursts of IO in the graph than large blocks.

Treating this as a "how fast disk throughput is" is bogus. It's "what was the
largest amount of data we read in one second". Given the access patterns
are completely different between releases, comparisons of this number are
completely meaningless.

Something else also stands out, comparing the graphs.
The peaks in all the earlier "high score" results are during either
the readahead service, or rhgb (earlier versions of X did tons of disk IO
doing dumb things like loading modules it didn't need).


None of this excuses why bootup performance still sucks in F9, but
"the disk got slower" isn't the reason. Or at least it shouldn't be.
I'd rather see results from a real disk benchmark confirming this than
the hand-waving done by the phoronix guys misinterpreting what bootchart is saying.

Dave

[David Mansfield]

Post by Alan Cox

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

Couldn't it be more an issue of the number of concurrent read/write
streams created during the startup sequence?

David

[David Nielsen]

Post by Alan Cox

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

I have a similar experience, my desktop machine has two 400 gb drives in a
mdraid RAID0 which hosts / and /home on lvm with dmcrypt enabled. With an
Ubuntu (Hardy, their current development release) install I can restore my
backup from my USB harddrive at 23mb/s, same setup using the current
Rawhide the transfer speed is a mere 13mb/s.

I am thinking it's this one:
https://bugzilla.redhat.com/show_bug.cgi?id=232843
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/ad08ebc9/attachment-0002.html

[Dave Jones]

Post by Alan Cox

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

The idea of using bootchart to measure disk performance seems a bit suspect.
For example, FC5 had the readahead service enabled, so the disk got to do a
serialised burst of reading of a few hundred MB of data. Now that we don't have
that service, the disk isn't being used as much, so we never see those sorts of peaks,
leading to more 'spiky' bursts of IO in the graph than large blocks.

Treating this as a "how fast disk throughput is" is bogus. It's "what was the
largest amount of data we read in one second". Given the access patterns
are completely different between releases, comparisons of this number are
completely meaningless.

Something else also stands out, comparing the graphs.
The peaks in all the earlier "high score" results are during either
the readahead service, or rhgb (earlier versions of X did tons of disk IO
doing dumb things like loading modules it didn't need).


None of this excuses why bootup performance still sucks in F9, but
"the disk got slower" isn't the reason. Or at least it shouldn't be.
I'd rather see results from a real disk benchmark confirming this than
the hand-waving done by the phoronix guys misinterpreting what bootchart is saying.

Dave

[David Mansfield]

Post by Alan Cox

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

Couldn't it be more an issue of the number of concurrent read/write
streams created during the startup sequence?

David

[Gianluca Sforna]

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

I am not sure rawhide kernels can be compared with official release
ones, as they usually carry debugging stuff which may ( or may not ;)
) justify that difference.

I also have to note they do not state what "spin" they used for the
Ubuntu counterpart; if it was the liveCD, we are comparing apples and
oranges

[Alan Cox]

Post by Martin Sourada
Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

That would be a bug or a misconfiguration somewhere. I'm suprised someone
would put that in an article instead of filing a bug.

Alan

[Martin Sourada]

Post by Jakub 'Livio' Rusinek
Dnia 2008-03-28, pi? o godzinie 19:59 -0600, Oscar Victorio Calixto

Post by Oscar Victorio Calixto Bacho
you can see phoronix benchmark
http://www.phoronix.com/scan.php?page=article&item=fedora_boot_perf&num=1

Fedora is not a daemon of speed, but the speed is purpose-dependent.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Yeah, I agree, but after going trough the article I cannot pass by in
silence the fact that while in Fedora 5 the disk maximum throughput was
29 MB/s in Rawhide it's only 8 MB/s which is nearly 4x less...

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/ad296e49/attachment-0002.bin

[Jakub 'Livio' Rusinek]

Dnia 2008-03-28, pi? o godzinie 19:59 -0600, Oscar Victorio Calixto

Post by Oscar Victorio Calixto Bacho
you can see phoronix benchmark
http://www.phoronix.com/scan.php?page=article&item=fedora_boot_perf&num=1

Fedora is not a daemon of speed, but the speed is purpose-dependent.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: To jest =?UTF-8?Q?cz=C4=99=C5=9B=C4=87?=
=?UTF-8?Q?_wiadomo=C5=9Bci?= podpisana cyfrowo
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080329/d1a676f3/attachment-0002.bin

[Oscar Victorio Calixto Bacho]

you can see phoronix benchmark

http://www.phoronix.com/scan.php?page=article&item=fedora_boot_perf&num=1

Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080328/0ff81b6c/attachment-0002.html

[Balaji Ravindran]

Hi,

Yea accept,

1. What you might want to try is use either VM or real hardware, but if you
choose something stick to it, (meaning perform the tests for the OS's with
same specs) I'm sure you would have done this., am just asking you to double
check.

2. GNOME and XP has lot of different start-up services which might affect
the test results., SO i would suggest after the initial install of both OS,
disable any un-important startup services in both., and restart the test.
(When i say services it also includes, disabling any anti-virus blah blah
blah)

3. Perform the test in different VM's(VM's by different vendors) possibility
is that some vendors custom there optimizations for a particular OS, so by
performing the test on different VM's from various vendors we can come at an
average time, would lead to a better benchmark.

4. Perform the tests with KDE and XP, coz, that might be a more closer match
with XP's startup themes and processes.

5. Then running the test 2-3 times with the above procedures will give a
more accurate result, and will also help identify where exactly fedora is
slower.

(Am sure your findings are true, but inorder to help developers isolate the
problem requires more vigorous testing)

Am sure other people will also be helping in testing simultaneously, which
should reduce your burden a bit.

Thanks

Balaji R
On Fri, Mar 28, 2008 at 9:07 AM, Emmanuel Seyman <

Post by Emmanuel Seyman

Post by Emmanuel Seyman

Post by Dimi Paun
The same must happen here, and the first step is to acknowledge it.

The first step is actually to eliminate variables in the test so as

to better isolate the problem. Can you run your test again with the
same platforms on real hardware ? That would eliminate any slowness
due to the virtual setup.
Emmanuel
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080328/b8a72a32/attachment-0002.html

[Eric Mesa]

I think it's a bit of a false comparison - give that they're running in
VMs. After all, F8 on the real hardware is only about 4 times slower. To
throw in my own experience, I have a self-built, pretty nice P4 running Win
XP and a cheap, $300, few years old Emachine running Fedora 8. If I start
them up at the same time, even counting the time it takes me to type in my
username/password on Linux (in Windows it just boots straight to the
desktop), I can use the Linux/Gnome computer up to a minute or more sooner
than I can Windows. Why? Because Norton Internet Security takes forever
and a day to start up and until it does, I can't do ANYTHING on my
computer. Even clicking the start button is a 20+ second wait. Norton is
essential to keep my computer running, so it would be unfair to compare it
to Windows without Norton. (BTW - I'm running Norton 2008 which runs a
heckuva lot faster than 2007)

And my Ubuntu machine (using upstart?) which is an under-powered laptop
starts up even faster than Fedora. So yeah, Fedora needs to work on startup
time, but I can be browing the internet/doing w/e I want a LOT faster in
Fedora than in Windows.

Post by Dimi Paun

Post by Lubomir Kundrak
Not to devaluate your tests -- please bear in mind that we offer more
features and are much more secure than XP. I am wondering what the
results would be if you kickstarted fedora just with icewm and firefox
and compared that one.

They will be better, but I don't think by much -- it takes almost 1.5min
just to get to the point were we start GNOME, IceWM can't go back in
time. :)
And what features can we offer that we are willing to pay by an order
of magnitude in performance? (Firefox after boot in XP starts in 2-3s,
whereas in Fedora it takes 25-28s!).
The danger here is that we make ourselves feel better and ignore the
problem by saying we offer more features. 600% slower to start! I
remember the days back in 99 or around there, when Windows came on top
in performance. For months we tried to blame it on biased tests, etc.
Then the kernel folks got their act together and fixed the problem.
The same must happen here, and the first step is to acknowledge it.
This is a much more difficult problem I think then the other one,
and I'm afraid that RedHat is the only one capable to solve it (because
kernel/glibc/toolchain/GNOME). This is similar in the way to good thread
support that required tricky changes in kernel/glibc/toolchain.
Hey, come to think of it, we need Ingo to look at it! :)
I'm not even sure where the problem lies. Is PE inherently faster than
ELF? Is it the on-demand paging of apps that is done in the kernel under
Windows responsible for that much faster startup times? Do they have
that much better compilers/linkers? Or maybe better preloading from
disk?
I personally think a key piece in the puzzle is why is Firefox so
darn slow to load under Linux when compared to Windows?
--
Dimi Paun <dimi at lattica.com>
Lattica, Inc.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

--
Eric Mesa
http://www.ericsbinaryworld.com
http://server.ericsbinaryworld.com
"Do not worry about those things that are outside of your circle of
influence. For since they are outside of your power to control them it is
simply a waste of time and energy to dwell on them. Instead, turn your
attention to those things that you can control and grow your influence in
those areas and you will see the effects begin to trickle out to those items
that were previously out of your power to influence." ? Eric Mesa inspired
by Covey's 7 Habits of Highly Effective People
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080328/55ddf0fb/attachment-0002.html

[Emmanuel Seyman]

Post by Dimi Paun
The same must happen here, and the first step is to acknowledge it.

The first step is actually to eliminate variables in the test so as
to better isolate the problem. Can you run your test again with the
same platforms on real hardware ? That would eliminate any slowness
due to the virtual setup.

Emmanuel

[Dimi Paun]

Post by Lubomir Kundrak
Not to devaluate your tests -- please bear in mind that we offer more
features and are much more secure than XP. I am wondering what the
results would be if you kickstarted fedora just with icewm and firefox
and compared that one.

They will be better, but I don't think by much -- it takes almost 1.5min
just to get to the point were we start GNOME, IceWM can't go back in
time. :)

And what features can we offer that we are willing to pay by an order
of magnitude in performance? (Firefox after boot in XP starts in 2-3s,
whereas in Fedora it takes 25-28s!).

The danger here is that we make ourselves feel better and ignore the
problem by saying we offer more features. 600% slower to start! I
remember the days back in 99 or around there, when Windows came on top
in performance. For months we tried to blame it on biased tests, etc.
Then the kernel folks got their act together and fixed the problem.

The same must happen here, and the first step is to acknowledge it.
This is a much more difficult problem I think then the other one,
and I'm afraid that RedHat is the only one capable to solve it (because
they employ enough key people in all the right places:
kernel/glibc/toolchain/GNOME). This is similar in the way to good thread
support that required tricky changes in kernel/glibc/toolchain.

Hey, come to think of it, we need Ingo to look at it! :)

I'm not even sure where the problem lies. Is PE inherently faster than
ELF? Is it the on-demand paging of apps that is done in the kernel under
Windows responsible for that much faster startup times? Do they have
that much better compilers/linkers? Or maybe better preloading from
disk?

I personally think a key piece in the puzzle is why is Firefox so
darn slow to load under Linux when compared to Windows?

[Dimi Paun]

Folks,

I have reported in the past slow boot times. I have performed
some more tests that may help people improve the situation.

Hardware: 2x2.13 GHz Intel Core Duo 6400, 4GB RAM
Software: Fedora 8, running Innotek's Virtual Box
Virtual Hardware: 538MB RAM, 8GB HDD
OS in Virtual Box: Fedora 9 Beta and XP

Test was to boot the box and start Firefox to the point where I can
interact with it (i.e. type in location bar).

Summary:
* F8 on real hardware, without BIOS time: 2:15
* F9 on virtual hardware: 7:00
* XP on virtual hardware: 0:22

For F8 boot, here is a breakdown of times:
0:00 -- Grub starts
1:25 -- login prompt
1:50 -- I can click on the Firefox icon
2:15 -- Firefox becomes usable

For F9 Beta boot, being so slow, I could record more details:
0:00 -- start of virtual box
0:45 -- "Welcome to Fedora" shows
1:30 -- udev finishes (took 45'!)
1:40 -- first graphics show (rhgb)
3:20 -- X restarts (I guess rhgb ends)
4:00 -- login prompt
6:15 -- Firefox icon is clickable
7:00 -- Firefox becomes usable

A few notes:
* I took out all times for user interaction
* I repeated the tests a few times, the results are stable
* For whatever reason, Fedora 9 Beta feels very sluggish in the
virtual machine (even the mouse stutters), whereas XP runs
extremely well. Maybe Innotek did some Windows-only optimizations?
* I measured to the point where I could interact with Firefox.
However, at that point XP appeared more responsive than Fedora,
even when compared to the Fedora that was running on the real
hardware, with a lot more RAM available.
* Even when comparing Fedora on real hardware vs XP on VM,
it took longer to just start Firefox in Linux vs. the entire
boot + starting of Firefox in Windows!

I'd be glad to provide more information if people are interested.

[Andrew Farris]

Post by Dimi Paun
0:00 -- start of virtual box
0:45 -- "Welcome to Fedora" shows
1:30 -- udev finishes (took 45'!)

It looks to me like Virtual Box has serious issues (bugs). This is absurdly
slow compared to my machines: macbook core 2 duo both as physical install and
vmware virtual machines (x86 and x86_64), and P4 2Ghz 1Gb rdram.

[Lubomir Kundrak]

Hi,

Post by Dimi Paun
* Even when comparing Fedora on real hardware vs XP on VM,
it took longer to just start Firefox in Linux vs. the entire
boot + starting of Firefox in Windows!

Not to devaluate your tests -- please bear in mind that we offer more
features and are much more secure than XP. I am wondering what the
results would be if you kickstarted fedora just with icewm and firefox
and compared that one.

NB: I bet my XT with 640K RAM boots Minix faster than my workstation
would boot XP. It's all about features again.