home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4811 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.7 KB
  1. Path: sparky!uunet!poietics!cng
  2. From: cng@poietics.UUCP (Chris Gayler)
  3. Newsgroups: biz.sco.general
  4. Subject: Re: Performance issues revisited
  5. Message-ID: <460@poietics.UUCP>
  6. Date: 23 Dec 92 13:10:26 GMT
  7. References: <sheldon.725038896@pv141b.vincent.iastate.edu> <Duw8VB10w165w@zswamp.UUCP>
  8. Reply-To: cng@poietics.UUCP (Chris Gayler)
  9. Organization: POIETICS
  10. Lines: 56
  11.  
  12. In article <Duw8VB10w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
  13. >sheldon@iastate.edu (Steve Sheldon) writes:
  14. >
  15. >>   time dd if=/dev/rhd0a of=/dev/null bs=131072 count=128
  16. >
  17. >   I know that the DMA controllers on PC-compatibles can't do a transfer of 
  18. >more than 64K in a go.  In theory, the Adaptec (models 154x, 164x, 174x) need 
  19. >not be limited by this, thanks to bus master DMA.  Does anyone know the size 
  20. >limit for a single DMA burst from these devices?
  21. >
  22. >>  I'm curious if perhaps the configuration you have just doesn't like the
  23. >> smaller block size.  I suppose it might be possible...
  24. >
  25. >   In my own experiments while constructing a count-oriented (for maximum 
  26. >performance) yet time-regulated disk benchmark, I found that throughput 
  27. >increases logarithmically with block size. (note: not exponentially; I mean 
  28. >approaching the maximum, with each increment in block size having less effect 
  29. >than the last.)  I ended up using 60K blocks, because they gave pretty much 
  30. >the same figures as 63K blocks.  Some systems gave very low figures when 64K 
  31. >block sizes are used, but others did not; I do not understand that 
  32. >observation. 
  33. >
  34.  
  35.  
  36. Just to add more datapoints, I ran these tests against various controllers:
  37.  
  38.   time dd if=/dev/rhd0a of=/dev/null bs=2048 count=8196
  39.   time dd if=/dev/rhd0a of=/dev/null bs=65536 count=256
  40.  
  41. Results (real times in seconds)
  42. 2048  65536 (Block sizes)
  43.  
  44. 20    --        486/50 with Mylex DCE376 SCSI caching controller, SCO 3.2.4
  45.                        Newer Maxtor disks.
  46.  
  47. 33    10.6      486/50 with Adaptec 1740 SCSI, SCO 3.2.4, older Maxtors
  48.  
  49. 34    33.9      386/25 with WD1007 ESDI controller, SCO 3.2.2
  50.  
  51. 37    10.1      486/33 with Adaptec 1542 SCSI, fast Fujitsu disks, SCO 3.2.4
  52.  
  53. 39    23.9      386/25 with UltraStor 12F ESDI controller, SCO 3.2.2
  54.  
  55. 39    13.3      386/33 with Adaptec 1542 SCSI, fast Fujitsu disks, SCO 3.2.4
  56.  
  57.  
  58. To summarize, SCSI and ESDI controllers have comparable performance on small
  59. block sizes, but SCSI steps way out on larger block sizes. The exception is
  60. the Mylex, which likely has the best performance on both ends (I didn't have 
  61. access to the Mylex to run the large block test.) For the 1542, the mem=/L
  62. boot option yielded about an 8% improvement on the 2048 test.
  63.  
  64. The downside is that the Mylex will bite you on installation time.  :-E 
  65.  
  66. Chris
  67.  
  68.