From: Bela Lubkin <belal@sco.COM>
Subject: speed of high-buffers, Re: Performa[n]ce degradation under SCO
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Wed, 23 Dec 1992 19:06:44 GMT
Precedence: bulk

Dave Van Allen wrote:

> If you don't have the cache, then yanking the extra memory is your only 
> recourse anyway. Right?  

No, actually there's a much better one.  Simply disable the external
cache completely, but *leave the internal cache enabled*.  Now, I
realize that not all motherboard/BIOS combinations allow this, but if
yours does, do it.  Remember those performance figures: no cache=1,
external only=3, internal only=8, both=11.  So with internal only, you
run about 75% of full speed, which is much better than (sometimes full
speed) (sometimes 1/11 speed).

(Those performance factors are from one very informal test, don't bother
trying to hold me to them.  I know they're wrong for most purposes but
they're right enough for purposes of making this decision).

> > ..........................................SCO UNIX 3.2v4/ODT 2.0 knows
> > whether your host adapter/bus combination can DMA above 16MB.  It goes
> > to a lot of effort to make sure that things that might need to be DMA'd
> 
> I have seen cases where it "guessed" wrong. The AST Premium 386 with the
> 486 upgrade module is one. If more than 16 meg of memory is installed
> when you access past the 16MB limit, the box DMA's down and find its way
> not into so magical buffer pool, but onto the scsi drive. AST confirms
> this as a problem.

Can you explain that with a bit more detail?  That sounds like a
motherboard design bug, not anything the kernel could avoid, but I don't
really understand what you're saying the problem is.

> You posted, a good explaination of the cache problem along with the
> tag ram explaination a while back. Any chance you have that again?

Oh, somewhere.  Digging it up would be difficult.

> I'm not quite sure that I am ready to agree that doing DMA above 16MB
> (on an ISA bus) is as quick as you suggest:
> 
> > Let's just suppose that you're
> > running at 33MHz and that it takes 20 cycles per byte (a wildly
> > pessimistic estimate) to copy memory.  So to copy a 512-byte buffer
> > takes 512*20 = 10240 cycles, or 10240/33 uSec, or .31 milliseconds.
> 
> But, I find it hard to argue with your statement right now. AND, it's
> not often that you err. :-)

Well, I'm certainly wrong in one respect or another, because I both say
that and say that I think I must be wrong!  That time is so short.

So to test the theory, I wrote this program:

main(){
  char bigbuf[512000], bigbuf2[512000];
  int i;

  for (i=0; i<10; i++) memcpy(bigbuf,bigbuf2,512000);
}

Which is to say, copy 500K of memory ten times.  The cached 486/33 I ran
this on took an average of about .5 seconds to do this.  Is that
reasonable?  5120000 bytes moved in .5 seconds = 10MB/sec, let's say, or
2.5 million 32-bit transfers, or (at 33MHz) 13 clock cycles per
transfer, 3.25 clocks per byte.  I'm certainly willing to believe that.
So dividing that down to a single buffer (1K -- see, I was wrong, I said
512 bytes above ;-), we get 1 second / 10000, or .1 ms.

And this time I'm more confident about it.  I don't know exactly what
the kernel's code to do this transfer looks like, but even if it's
horribly inefficient, I don't believe it has any real effect compared to
actual disk I/O waits.

>Bela<
Newsgroups: biz.sco.general