Ok. 19" screen, 1200x1024 resolution, 16bpp I ran (I believe) a mesa demo
called tunnel(?) that scored my fps at almost 300 because it really wasn't
doing much, and was probably using display lists to speed up performance. I'm
not sure which game it was that I was running that gave me a 35fps score, but
I believe it was Soldier of Fortune set on one of the insane 'everybody comes
back from the dead to shoot at you again' settings. Again, it's a Voodoo3
3000 with XF86 ver. 4.1.0 on dual celeron 433 with 512M ram. Same resolution
and as full a screen I could get on both apps.
What I really meant to get at was that Linux is a little more efficient with
most hardware, but when it comes to things like video cards, even the
companies that make them tend to fudge the drivers a bit. Look at older
NVidia drivers for an indication of this (these have improved). You can't
really base any buying decisions on benchmarks alone. My Voodoo3 is good
enough for me, and runs accelerated OGL just fine. A G-Force 3 might have
better overall performance but it's not better enough to warrant going out an
buying a new card. That's pretty much all I meant.
Just don't make cash decisions based on benchmarks unless you do them
yourself.
Glen
On Sunday 09 December 2001 21:39, you wrote:
> 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
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:05:10 EDT