home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / m68k / 1457 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.2 KB  |  45 lines
  1. Newsgroups: comp.sys.m68k
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!torn!nott!bnrgate!bcars267!news
  3. From: mascot@bnr.ca (Scott Mason)
  4. Subject: Re: Busperformance of the 68030?
  5. Message-ID: <1992Dec14.222224.4156@bnr.ca>
  6. Sender: news@bnr.ca (usenet)
  7. Nntp-Posting-Host: bcara204
  8. Organization: Bell-Northern Research, Ottawa, Ontario, Canada
  9. References: <H.Qg_VCBlXLZo@fredrik.atari.no>
  10. Date: Mon, 14 Dec 1992 22:22:24 GMT
  11. Lines: 32
  12.  
  13. In article <H.Qg_VCBlXLZo@fredrik.atari.no> jornmoe@fredrik.atari.no writes:
  14. >The 68030 have a synchronous mode in which it does bus accesses in 2 clock
  15. >cycles. Does this mode have overcapacity? I.e.: Can it fetch instructions 
  16. >and red/write data faster from/to the bus faster than the CPU can process
  17. >them? (I know this will depend on the instructions but 'in general')?
  18.  
  19. A previous designer in our product area performed an experiment to
  20. determine this. His system ran 5-clock accesses with the I-cache
  21. enabled and the D-cache disabled. Don't know his instruction mix.  He
  22. reported 60% bus utilization under these circumstances.
  23.  
  24. Note - the bus utilization will be sensitive to the instruction mix as
  25. well as the cache hit rate.
  26.  
  27. >Now to the main question: Is there some 'rule' or 'expirienced factor' by 
  28. >which one can reduce bandwith by, and still gain ~100% CPU performance.
  29.  
  30. No. There are at least two factors here. One is bandwidth; the other is
  31. latency. Although the bus may be inactive some or even much of the time
  32. (more bandwidth than required), when the processor asks for
  33. instructions/data it must receive them as soon as possible (latency
  34. must be low) in order for performance not to be impacted. Any scheme
  35. that you use that reduces the bandwidth (slow memory, unsophisticated
  36. bus architecture, shared memory, etc) would negatively impact latency
  37. and thus would negatively impact performance. Some of the latency
  38. problem could be solved by including a secondary cache between the
  39. processor and your high bandwidth, high latency bus.
  40.  
  41. ------------------------------------------------------------------------
  42. #include <disclaimer.h>                          Bell-Northern Research
  43. Scott Mason                                      P.O. Box 3511 Station C
  44. Internet: mascot@bnr.ca                          Ottawa, Canada, K1Y 4H7
  45.