🚀 go-pugleaf

carlo@ozspace.brisnet.org.au (Carlo Hamalainen) writes:
>
>just wondering what experiences people have had with P5-90 boxes and linux
>(and dos and everything else for that matter).
>
>Thanks,

I just picked one up two weeks ago.
Its a P5-90 with 256k cache ram, with an NCR 53c810 PCI SCSI card.
I also have a fast VRAM graphics card. Diamond Stealth 64.
I bought the InfoMagic Dec 94 CD's and it screams.
X-Windows is great at 1152x864 in 24 bit. :-)

For FPU performance its quicker than the single CPU Sparc 10 server
we have here at work.

>-- Carlo

--
  _-_|\      r.luiten@nmsd.oz.au                       /Disclaimer:
 /     * <-- Network Performance Management (Telstra),/
 \_.-._/     Telecom East Tower Roma St,             /   C references
      v      Brisbane, Australia.                   /   are NULL && void*

Carlo Hamalainen (carlo@ozspace.brisnet.org.au) wrote:
: just wondering what experiences people have had with P5-90 boxes and linux
: (and dos and everything else for that matter).

I'm using a Gateway P-90 with SCSI disks (Adaptec 1542 SCSI).  I haven't
spent time on the Gateway packaged sound system and the ATI Mach-64
is currently running as an SVGA at 1024x768.  All considered its working very
well. If feels faster than a Sparc 5 in every way except NFS.
I'm using NFS (a 3COM?509 ethernet card) with a mixture of UNIX
workstations.  Sony CDROM, Colorado Jumbo 250 tape.

Software:
     1.1.85 kernel
     2.02   ftape
     X11R6 (and R5)

- Don Ledford     ledford@networx.com

luiten@nmsd.oz.au (Robin Luiten) writes:

>carlo@ozspace.brisnet.org.au (Carlo Hamalainen) writes:
>>
>>just wondering what experiences people have had with P5-90 boxes and linux
>>(and dos and everything else for that matter).
>>
>>Thanks,

>I just picked one up two weeks ago.
>Its a P5-90 with 256k cache ram, with an NCR 53c810 PCI SCSI card.
>I also have a fast VRAM graphics card. Diamond Stealth 64.
>I bought the InfoMagic Dec 94 CD's and it screams.
>X-Windows is great at 1152x864 in 24 bit. :-)

>For FPU performance its quicker than the single CPU Sparc 10 server
>we have here at work.

But be careful with those ncr53c810 cards!

I spent almost $4000 on a P90 system to run Linux only on. I researched all
the FAQs and purchased all parts that SHOULD work with Linux. However on my
particular machine the 53c810 refuses to work reliably. I found out later it is
a known timing problem with the driver. I had to get an Adaptec 1542 to get this
box running. Hopefully sooner or later a better driver for the 53c810 will come
out, and I can use the card. When the machine was working with the 53c810,
it was VERY fast.

Carlo Hamalainen (carlo@ozspace.brisnet.org.au) wrote:
: just wondering what experiences people have had with P5-90 boxes and linux
: (and dos and everything else for that matter).

: Thanks,

I am currently running Linux v1.1pl75 on home-made-no-name Intel P5/90, 256c, 32MB
motherboard based computer. It has ncr53c815 PCI SCSI adapter and OAK ISA-087
"accelerator" SVGA adapter. Linux package I'm using is Slackware v2.1.0
After newer kernel there hasn't been a problem of any kind.
This computer (lux.iuakk.fi in fact) is used for our Internet mail-gw, http-server,
ftp & lotsa other Internet-related things.

Forget to mention, it has Quantum-Empire 2100S 2160MB SCSI drive- with ncr scsi
adapter it runs lightingly fast!

jani.kurki-suonio@iuakk.fi

Robin Luiten (luiten@nmsd.oz.au) wrote:
: carlo@ozspace.brisnet.org.au (Carlo Hamalainen) writes:
: >
: >just wondering what experiences people have had with P5-90 boxes and linux
: >(and dos and everything else for that matter).
: >
: >Thanks,

: For FPU performance its quicker than the single CPU Sparc 10 server
: we have here at work.

Likewise, I have a P5/90 with 32 MB RAM, gig disk, etc.  I ran a matrix
decomposition on a matrix of order 300 or so, and it compared favorably
to our HPs.  CPU time was about equal.  The HP was a 735 or 755.  Someone
else has run a Space Shuttle/Mir docking simulation on the Pentium, and it
ran twice as fast on the P5 than on our SGI Iris workstation.  That may be
the fault of SGIs new OS though.  Still, quite impressive.

James

--
----------------------------------------------------------------------
James P. Smith
NASA/JSC, Mail Code ES
Houston, Texas 77058
smithj@smithj.jsc.nasa.gov
smithj@smd4.jsc.nasa.gov

In article <1995Feb6.094005.40@nntp.brisnet.org.au>,
carlo@ozspace.brisnet.org.au (Carlo Hamalainen) wrote:

> just wondering what experiences people have had with P5-90 boxes and linux
> (and dos and everything else for that matter).
>

My friend jus got his working OK on a 90MHz PCI Pentium with Diamond
Stealth 64, Sony CDP-1730, Creative Labs CD-16, 32MB RAM, 850MB IDE, 900MB
SCSI.  He's using IDE for linux, coz the SCSI driver is only alpha for his
SCSI card.  No problems so far, even though it seems that linux says it
supports 386 and 486 (no mention of Pentium).

Maybe the latest releases of linux explicitly mention Pentium support...

In article <1995Feb6.094005.40@nntp.brisnet.org.au>,
Carlo Hamalainen <carlo@ozspace.brisnet.org.au> wrote:
>just wondering what experiences people have had with P5-90 boxes and linux
>(and dos and everything else for that matter).
>

Linux, DOS, Windows, Windows NT, OS/2 work as well as the code will let them
on a P-90. I tried them all, it's great...

						-Gel

--
*******************************************************************************
               Gilles Khouzam, McGill University, Montreal, Canada
	       (gel@cs.mcgill.ca) && (http://www.cs.mcgill.ca/~gel)
If I ever become so pathetic as to listen to country music, please SHOOT ME!!!

Don Ledford (ledford@squid.networx.com) wrote:

: I'm using a Gateway P-90 with SCSI disks (Adaptec 1542 SCSI).  I haven't
: spent time on the Gateway packaged sound system and the ATI Mach-64 
: is currently running as an SVGA at 1024x768.  All considered its working very
: well. If feels faster than a Sparc 5 in every way except NFS.
: I'm using NFS (a 3COM?509 ethernet card) with a mixture of UNIX
: workstations.  Sony CDROM, Colorado Jumbo 250 tape.


I hate to say it but the reason your NFS performance is bad isn't
because of your hardware.  Try running FreeBSD 2 on the same gear and
you'll see NFS performance more than double (seriously).  I was porting
mSQL to both Linux and FreeBSD a while back using an NFS mounted source
tree onto a Pentium and with FreeBSD I didn't even notice it wasn't
local.  With Linux I just about shot myself waiting for the
compilation.  The slow-down was that dramatic.

--
   __                                  David J. Hughes  -  Bambi@Bond.edu.au
  /  \               /  /   /           http://Bond.edu.au/People/bambi.html
 /___/ __   _   ____/  /   / _     
/   \ /  \ / \ /   /  /   / / \  /   Senior Network Programmer, Bond University
\___/ \__//  / \__/   \__/ /  / /    Qld.   4229   AUSTRALIA    (+61 75 951450)

In article <3h89kf$57c@pendragon.jsc.nasa.gov>,
James Conrad Pope Smith <smithj@smithj.jsc.nasa.gov> wrote:
>Likewise, I have a P5/90 with 32 MB RAM, gig disk, etc.  I ran a matrix
>decomposition on a matrix of order 300 or so, and it compared favorably
>to our HPs.  CPU time was about equal.  The HP was a 735 or 755.

    A 735/99 turns in over twice the SPECfp of a Pentium/90 (the Pentium
comes within 20% or so on just one of the suite, alvinn), which should make
you wonder about this. Perhaps you didn't turn on full optimization on the
HP, or were thrashing.
    Jon
    __@/

David J. Hughes (bambi@Bond.edu.au) wrote:

> I hate to say it but the reason your NFS performance is bad isn't
> because of your hardware.  Try running FreeBSD 2 on the same gear and
> you'll see NFS performance more than double (seriously).  I was porting
> mSQL to both Linux and FreeBSD a while back using an NFS mounted source
> tree onto a Pentium and with FreeBSD I didn't even notice it wasn't
> local.  With Linux I just about shot myself waiting for the
> compilation.  The slow-down was that dramatic.

I've heard this so many times that it must be true. Does anybody know where
the bottle neck is. i.e. is it

1) Linux networking.
2) Linux NFS client.
3) NFS server.
4) Ethernet drivers.

Because if it's the NFS server then using the BSD one should provide the
same speed. But I have noticed ftp speed under Linux isn't as fast as what
I expected. I get about 200K/s to 300K/s over unloaded ethernet bus. So
maybe the TCP/IP stack under Linux is a bit slower than FreeBSD.
-- 
--     .    +----------------------------------------------------------------+
   ,--_|\   | John Saunders  - (Work) johns@rd.scitec.com.au       (78 cols) |
  /  Oz  \  |                - (Home) john@pacer.apana.org.au                |
  \_,--\_/  | SCITEC LIMITED - Phone +61 2 428 9541 - Fax +61 2 428 9933     |
        v   +----------------------------------------------------------------+

John Saunders (johns@rd.scitec.com.au) wrote:

: Because if it's the NFS server then using the BSD one should provide the
: same speed. But I have noticed ftp speed under Linux isn't as fast as what
: I expected. I get about 200K/s to 300K/s over unloaded ethernet bus. So
: maybe the TCP/IP stack under Linux is a bit slower than FreeBSD.

From what I can recall the stack was just about written from scratch.
Maybe that's not the case with NET-2 (I'm not that much into things) but
I can't understand why the BSD code wasn't beaten into the kernel.  When
you have people like VJ and the CSRG guys spending man years getting 
amazing performance out of the BSD code it makes sense to run with it.  

I listened to Van speaking in San Francisco in '93 when he was outlining 
the work his group had done to the BSD code.  Statements like 

	"we _only_ got one order of magnitude performance increase from 
	the XYZ module" 

showed how well they'd done with the entire stack as a whole.

--
   __                                  David J. Hughes  -  Bambi@Bond.edu.au
  /  \               /  /   /           http://Bond.edu.au/People/bambi.html
 /___/ __   _   ____/  /   / _     
/   \ /  \ / \ /   /  /   / / \  /   Senior Network Programmer, Bond University
\___/ \__//  / \__/   \__/ /  / /    Qld.   4229   AUSTRALIA    (+61 75 951450)

johns@rd.scitec.com.au (John Saunders) writes:
>I've heard this so many times that it must be true. Does anybody know where
>the bottle neck is. i.e. is it

>1) Linux networking.
>2) Linux NFS client.
>3) NFS server.
>4) Ethernet drivers.

I seem to recall having heard that the problem is in the way the NFS
support in the kernel works (in effect, the "client") -- particularly
the fact that, unlike other NFS inmplementations, no caching is done.
This had something to do with the way the Linux buffer cache worked.
Don't quote me on this though, I don't even have a network. :-)

 - Mike

scotta@jolt.mpx.com.au (Scott A Howard) writes:
>Mike Battersby (michaelb@aurora.cc.monash.edu.au) wrote:
>: I seem to recall having heard that the problem is in the way the NFS
>: support in the kernel works (in effect, the "client") -- particularly
>: the fact that, unlike other NFS inmplementations, no caching is done.
>Cacheing of non-local filesystems is basically impossible, as you never 
>know when the remote files have changed, and thus when you need to 
>re-read the data.

Not true, but I don't know if NFS does it that way (I doubt it, now
that I think a bit more).  Maybe it's due to the lack of read-ahead
or async writes or something [ okay, so I'm grabbing at straws :) ] --
I'm convinced it was related to the buffer cache.

 - Mike

Andrew J. Cosgriff (andrewc@penfold.cc.monash.edu.au) wrote:
> wongm@latcs1.lat.oz.au writes:
> >Mike Battersby (michaelb@aurora.cc.monash.edu.au) wrote:
> >
> >: I seem to recall having heard that the problem is in the way the NFS
> >: support in the kernel works (in effect, the "client") -- particularly
> >	  ^^^^^^^^^^^^^
> >
> >I thought Linux NFS implementation is not  in kernel, but a user-level thing ?
> >Can someone confirm this ?

> I can confirm that it's in the kernel...

Yes, the NFS client is configured as one of the filesystems when you build
a new kernel. The NFS server is a daemon process (in.nfsd, in.mountd, in.ugidd)
that runs outside of the kernel. While I'm on topic, has anybody gotten
in.ugidd to actually work? I have 2 machines networked and and it isn't
properly mapping user ID's and group ID's, yet the daemon is running.
For example if user 'john' has ID 100 on one machine and ID 200 on the
other, then NFS doesn't display the correct owner on the NFS mounted
filesystem.
-- 
--     .    +----------------------------------------------------------------+
   ,--_|\   | John Saunders  - (Work) johns@rd.scitec.com.au       (78 cols) |
  /  Oz  \  |                - (Home) john@pacer.apana.org.au                |
  \_,--\_/  | SCITEC LIMITED - Phone +61 2 428 9541 - Fax +61 2 428 9933     |
        v   +----------------------------------------------------------------+

In article <3hqcv9$qho@bunyip.cc.uq.oz.au> cs307319@student.uq.edu.au (Julian Boot) writes:
> scotta@jolt.mpx.com.au (Scott A Howard) writes:
> 
> >Cacheing of non-local filesystems is basically impossible, as you never 
> >know when the remote files have changed, and thus when you need to 
> >re-read the data.

Sorry, its been done for 10+ years... You do need lome method
of reliably controlling things though.

> So what is the *real* difference between reading a file 1 second before
> it is deleted on a local filesystem, and reading a file 1 second after
> it has been deleted on a remote filesystem, because it is cached?
> 
> Sure, you get data tha may not be quite current, but can happen at
> anytime on a multiuser system.  And althogh I have not had a close
> look at the kernel NFS src, I see to get some caching on my systems.

The difference is in stable, predictable defined semantics of the
opperation. Replace 1 min with 1 day, and ask the question again.

Most systems define deletion to be a deletion request, that happens
when the last user closes (de-accesses ) the file. Many, but not all,
systems will not allow opens after a delete operation. A few systems
treat a delete as a 'de-reference' operation, and only destroy(sic)
the file when its reference count is 0.

Any of them is fine. Win some, lose some. But if the system is properly
done, you can design a reliable race-free system on to of them.
If the system is not predictable, you are in deep smelly brown stuff...

--
~Paul
                                                       +61 (09) 257-1001
prep@yarrow.wt.uwa.edu.au ( preferred )                1 Crescent Rd,
zrepachol@cc.curtin.edu.au                             Kalamunda,
                                                       West Aust    6076

Followup to:  <PREP.95Feb16015835@yarrow.wt.uwa.edu.au>
By author:    prep@yarrow.wt.uwa.edu.au (Paul Repacholi)
In newsgroup: aus.computers.linux
> 
> Most systems define deletion to be a deletion request, that happens
> when the last user closes (de-accesses ) the file. Many, but not all,
> systems will not allow opens after a delete operation. A few systems
> treat a delete as a 'de-reference' operation, and only destroy(sic)
> the file when its reference count is 0.
> 
> Any of them is fine...
> 

Actually, the unlink() system call on POSIX systems have very specific
semantics: it removes the directory name (link) of a file.  A
file can only be opened by referencing though a link, so once the
final link is removed, the file cannot be opened again except by a
process which can clone a file descriptor.  After all links are
removed and all file descriptors referring to the file are closed, the
file becomes inaccessible and its storage space is reclaimed by the
file system.

	/hpa

Here's what I understand:
The reason that Linux NFS performance is less than wonderful (or was less than
wonderful, assuming that has changed) was due to the buffering; namely, none
was done in order to ensure files had correct timestamps. AIXv 2.2.1 (which we
run on a bunch of eight-year-old IBM PC RTs we just got) has a biod- a block I/O
daemon- which I believe takes care of the I/O for NFS and takes care of this
problem.
--
Mike Acar -=- macar@mcs.kent.edu -=- Reality exists through being perceived. -=-
 -=- Linux: Free 32-bit multitasking Unix for the PC. -=- Ask me about it. -=-
    -=- Diamond video card problems under XFree86? Finger me for info. -=-
      -=- Linux and XFree86: Because life's too short to run Windows. -=-
         -=- MARS Home Page URL: http://nimitz.mcs.kent.edu/~macar -=-

Carlo Hamalainen (carlo@ozspace.brisnet.org.au) wrote:
: just wondering what experiences people have had with P5-90 boxes and linux
: (and dos and everything else for that matter).

: Thanks,

: -- Carlo

Mine works just great.  It's nice to compile a kernel in under 10 mins.

-- 
 .---------------------------------------------------------------------------.
 |      Paul Cardwell             | email address: arc@mama.indstate.edu     |
 |________________________.-------------------------.________________________|
 `---*Team OS/2*---------OS/2 WARP / Linux / AmigaCD32-----------------------'

In article <hpa.2f4e6942.Allah.u.Abha@sleipner.yggdrasil.com> hpa@sleipner.yggdrasil.com (H. Peter Anvin) writes:

>> In article <hpa.2f433d11.Linux.is.free@asgard.yggdrasil.com>
>> hpa@asgard.yggdrasil.com (H. Peter Anvin) writes: 
>> 
>> >Actually, the unlink() system call on POSIX systems have very specific
>> >semantics: it removes the directory name (link) of a file.  A
>> >file can only be opened by referencing though a link, so once the
>> >final link is removed, the file cannot be opened again except by a
>> >process which can clone a file descriptor.  After all links are
>> >removed and all file descriptors referring to the file are closed, the
>> >file becomes inaccessible and its storage space is reclaimed by the
>> >file system.
>> 
>> But unfortunately, this is not what standard NFS does.
>> 
>
>No?  It did last I checked...?

Possibly this behaviour is a common extension, just like file locking is a
common extension. But I don't believe that the standard NFS conformance
document supports it.

The reason is that the unlink() behaviour is an inherently stateful
operation (like file locks) whereas NFS is supposed to be stateless.

--

Chris Bitmead
chrisb@ind.tansu.com.au