home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4821 < prev    next >
Encoding:
Text File  |  1992-12-23  |  3.6 KB  |  87 lines
  1. Newsgroups: biz.sco.general
  2. Path: sparky!uunet!hobbes!xenitec!news
  3. From: Bela Lubkin <belal@sco.COM>
  4. Subject: speed of high-buffers, Re: Performa[n]ce degradation under SCO
  5. Resent-From: mmdf@xenitec.on.ca
  6. Submit-To: scogen@xenitec.on.ca
  7. Organization: [resent by] The SCOGEN gateway and Propagation Society
  8. Date: Wed, 23 Dec 1992 19:06:44 GMT
  9. Message-ID:  <9212231106.aa05673@scoke.sco.COM>
  10. Sender: news@xenitec.on.ca (xenitec.on.ca News Administrator)
  11. Precedence: bulk
  12. Lines: 73
  13.  
  14. Dave Van Allen wrote:
  15.  
  16. > If you don't have the cache, then yanking the extra memory is your only 
  17. > recourse anyway. Right?  
  18.  
  19. No, actually there's a much better one.  Simply disable the external
  20. cache completely, but *leave the internal cache enabled*.  Now, I
  21. realize that not all motherboard/BIOS combinations allow this, but if
  22. yours does, do it.  Remember those performance figures: no cache=1,
  23. external only=3, internal only=8, both=11.  So with internal only, you
  24. run about 75% of full speed, which is much better than (sometimes full
  25. speed) (sometimes 1/11 speed).
  26.  
  27. (Those performance factors are from one very informal test, don't bother
  28. trying to hold me to them.  I know they're wrong for most purposes but
  29. they're right enough for purposes of making this decision).
  30.  
  31. > > ..........................................SCO UNIX 3.2v4/ODT 2.0 knows
  32. > > whether your host adapter/bus combination can DMA above 16MB.  It goes
  33. > > to a lot of effort to make sure that things that might need to be DMA'd
  34. > 
  35. > I have seen cases where it "guessed" wrong. The AST Premium 386 with the
  36. > 486 upgrade module is one. If more than 16 meg of memory is installed
  37. > when you access past the 16MB limit, the box DMA's down and find its way
  38. > not into so magical buffer pool, but onto the scsi drive. AST confirms
  39. > this as a problem.
  40.  
  41. Can you explain that with a bit more detail?  That sounds like a
  42. motherboard design bug, not anything the kernel could avoid, but I don't
  43. really understand what you're saying the problem is.
  44.  
  45. > You posted, a good explaination of the cache problem along with the
  46. > tag ram explaination a while back. Any chance you have that again?
  47.  
  48. Oh, somewhere.  Digging it up would be difficult.
  49.  
  50. > I'm not quite sure that I am ready to agree that doing DMA above 16MB
  51. > (on an ISA bus) is as quick as you suggest:
  52. > 
  53. > > Let's just suppose that you're
  54. > > running at 33MHz and that it takes 20 cycles per byte (a wildly
  55. > > pessimistic estimate) to copy memory.  So to copy a 512-byte buffer
  56. > > takes 512*20 = 10240 cycles, or 10240/33 uSec, or .31 milliseconds.
  57. > 
  58. > But, I find it hard to argue with your statement right now. AND, it's
  59. > not often that you err. :-)
  60.  
  61. Well, I'm certainly wrong in one respect or another, because I both say
  62. that and say that I think I must be wrong!  That time is so short.
  63.  
  64. So to test the theory, I wrote this program:
  65.  
  66. main(){
  67.   char bigbuf[512000], bigbuf2[512000];
  68.   int i;
  69.  
  70.   for (i=0; i<10; i++) memcpy(bigbuf,bigbuf2,512000);
  71. }
  72.  
  73. Which is to say, copy 500K of memory ten times.  The cached 486/33 I ran
  74. this on took an average of about .5 seconds to do this.  Is that
  75. reasonable?  5120000 bytes moved in .5 seconds = 10MB/sec, let's say, or
  76. 2.5 million 32-bit transfers, or (at 33MHz) 13 clock cycles per
  77. transfer, 3.25 clocks per byte.  I'm certainly willing to believe that.
  78. So dividing that down to a single buffer (1K -- see, I was wrong, I said
  79. 512 bytes above ;-), we get 1 second / 10000, or .1 ms.
  80.  
  81. And this time I'm more confident about it.  I don't know exactly what
  82. the kernel's code to do this transfer looks like, but even if it's
  83. horribly inefficient, I don't believe it has any real effect compared to
  84. actual disk I/O waits.
  85.  
  86. >Bela<
  87.