home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / amiga / programm / 12279 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.7 KB
  1. Path: sparky!uunet!cbmvax!andy
  2. From: andy@cbmvax.commodore.com (Andy Finkel)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Clearing a PIPE:
  5. Message-ID: <34227@cbmvax.commodore.com>
  6. Date: 13 Aug 92 18:16:40 GMT
  7. References: <34141@cbmvax.commodore.com> <1992Aug11.124616.22374@pixel.kodak.com>
  8. Reply-To: andy@cbmvax.commodore.com (Andy Finkel)
  9. Organization: Flying Cat Software
  10. Lines: 57
  11.  
  12. In article <1992Aug11.124616.22374@pixel.kodak.com> jeh@raster.kodak.com (Ed Hanway) writes:
  13. >andy@cbmvax.commodore.com (Andy Finkel) writes:
  14. >: Actually, the pipe-handler (actually queue-handler) in 2.0 was an entirely
  15. >: new implementation written by Fred Mitchell of the  C= QA department.
  16. >
  17. >Any good reason for replacing Matt Dillon's perfectly adequate pipe-handler
  18. >with an inferior(*) replacement?  It's not like C= can afford to reinvent
  19. >the wheel like this.
  20. >
  21.  
  22. Hey, the previous poster was flaming the old pipe-handler to a crisp.
  23. He hated it. :-)
  24.  
  25. But, as long as you ask:
  26.  
  27. The pipe-handler turned out to the the main culprit behind hangs 
  28. for the AS225 software.  It apparently had some serious problems when
  29. multiple processes were banging on it (over the ethernet, anyway).
  30. (It was an early one from Matt) Anyway, Fred wanted to fix it, he had access 
  31. to the old one's source, but decided its methods could be improved.  
  32. (Matt himself used entirely different methods on his next pipe-like thing)
  33.  
  34. >(*) Try pushing a megabyte through PIPE:.  On a 68000 it took 90 seconds,
  35. >and that was with a single Write() call.  Considering that's 50-100 times
  36. >slower than hard disk access, I was a little disappointed.
  37.  
  38. The new one will allocate memory for the entire megabyte, unless a queue limit
  39. is specified in the mountlist.  The old one started deferring the return
  40. of the write packets until the reader had read enough so there was
  41. enough space in the buffer again.  
  42.  
  43. If you are going to do large transfers, you might want to increase
  44. the blocksize that the handler uses, by putting a line like:
  45.  
  46. BLOCKSIZE = 16384
  47.  
  48. in your mountlist entry for queue-handler.  (It defaults to 4096)
  49.  
  50. While you can get the deferred reply effect from queue-handler as well,
  51. by specifying the number of buffers it is allowed to allocate.
  52. It defaults to 0, or allocate as many as it needs.  Limiting it
  53. to a couple will give you the speed increase.  But things are more robust
  54. if you let it allocate as many buffers as it needs.  Especially when 
  55. multiple processes over ethernet are involved :-)
  56.  
  57. >Ed Hanway --- jeh@raster.kodak.com
  58.  
  59.  
  60.             andy
  61. -- 
  62. andy finkel        {uunet|rutgers|amiga}!cbmvax!andy
  63.  
  64. "A new release is where old bad assumptions are replaced by new
  65.  bad assumptions."
  66.  
  67. Any expressed opinions are mine; but feel free to share.
  68. I disclaim all responsibilities, all shapes, all sizes, all colors.
  69.