On Sunday 09 December 2001 16:04, you wrote:
> *Most* hardware runs faster under Linux. Video cards are still in
> the realm of stingy docs, so they are the worst hardware to try to
> benchmark under Linux - we have to figure them out on our own.
> Let's see MS do that and get benchmarks like we do.
>
> Glen
>
As another writer has mentioned, if a piece of hardware gets a series
of bits through its wiring, it can't tell if the pulses come from
Windows or Linux and will handle them the same. The rub is getting
the right pulses to the right connectors in the right order in a big
hurry ... that is the work assigned drivers and is a software issue.
I did my own benchmark that, while far from exhaustive, seemed
conclusive to me ... and strongly influenced my decision to learn how
to use Linux exclusively.
Here's how I did it. It's fiendishly easy to duplicate, localized for
your own hardware.
I set my computer up to dual boot Windows 98 and Mandrake 7.2 ,
making sure I installed 'tree' in Mandrake. Windows still includes it
in the "olddos" directory of your install CD. Just copy it to
somewhere on your path. C:\ is as good a place as any.
Get a stopwatch and calculator. Boot to one of the OS's. Fire up a
GUI (your choice) in Linux, open a terminal session and fire up tree
against the root directory. Calculate the number of files that hit
the screen per second by adding the number of directories found (they
are actually files) to the number of regular files found and dividing
by the elapsed time.
Using the command of "$time tree" against a ReiserFS, my own numbers
are :
1724 directories, 20795 files
0.52user 0.41system 0:04.85elapsed 19%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (130major+1823minor)pagefaults 0swaps
YMMV, but this gives me a total of 22,519 files divided by 4.85
seconds for a final number of 4,643 files to the screen per second.
Now, do the same in Windows by opening a window to an MS-DOS prompt
and running the identical program (tree). Using a stopwatch is
probably not as precise as using the Linux "time" command, but the
difference is probably going to be so glaring as to render slight
imprecision in stopping / starting the watch moot. I consider the
processing overhead of running "time" to be lost in the larger error
of using a stopwatch to time Windows.
I no longer have a copy of Windows with tree installed, but when I
did, Linux had a >3:1 advantage. It whupped Windows rather handily.
Now Win98 is just one more program on my hard drive. It runs in
VMware and interferes with printing from Linux so I don't leave it
loaded.
It is possible to define an outcome and then create a benchmark to
meet that outcome. Be VERY cautious about online benchmarks. There
are lots of ways to jiggle the numbers. The simple test I did on my
home computer was compelling to me in that I KNEW that both OS's were
running stock off the install CD and that they were absolutely
accessing the identical hardware. (Also stock, but different file
systems. Although Linux could have dealt with vfat95, Windows
couldn't have handled ext2fs. I gave each their own.)
Run your own tests on your own equipment. FPS is a good measure of
vid card speed ... but did you notice that Glen did not tell you the
size / resolution of the screen he was running ? A couple hundred fps
in a 2"/2" window running an 8 color palette at low resolution is not
especially encouraging. It's only nice if you just want to run test
patterns. :-)
I don't think Glen did this ... not at all ... but my point is that
he did not document the exact circumstances at which he got a very
favorable frame rate.
I have found that Linux either does a good job supporting a piece of
hardware or else declares its support to be either "iffy" or
non-existent. If Linux, absolutely and without further qualification,
says it supports a vid card and you are getting rotten numbers on it,
quite likely you have an error in your setup ... possibly going all
the way back to the kernel or your X server.
Even if it says the support is "iffy", there is a very real chance
that all the major components of it are running and, unless you press
it very hard, you may never find the point of failure.
My ATI Rage 128 (16 meg) is well supported. I don't even try gaming
(lack of interest) so frame rate is not a critical number for me. But
I do push 1600 x 1200 x 24 bpp (iirc) into a 19" monitor and have
never noticed a lag in screen re-draw. Since this is a user interface
issue, if I can't detect it, it effectively doesn't exist.
Bill
--
total used free shared buffers cached
Mem: 1545352 957360 587992 0 315336 402612
Swap: 401584 0 401584
Total: 1946936 957360 989576
Linux a.genesis.com 2.4.14 #3 Fri Nov 9 23:14:31 EST 2001 K7 750MHz
7:17pm up 20:31, 2 users, load average: 0.12, 0.25, 0.59
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:04:26 EDT