home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / apple2 / 23970 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.8 KB
  1. Path: sparky!uunet!ogicse!emory!wupost!sdd.hp.com!ncr-sd!crash!mdavis
  2. From: mdavis@crash.cts.com (Morgan Davis)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: CTS Stuff...
  5. Message-ID: <mdavis.721868254@crash.cts.com>
  6. Date: 15 Nov 92 22:57:34 GMT
  7. Article-I.D.: crash.mdavis.721868254
  8. References: <9211131547.AA14279@pwtc.tc.pw.com>
  9. Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
  10. Lines: 50
  11.  
  12. In <9211131547.AA14279@pwtc.tc.pw.com> Brendan_Hoar@notes.pw.com writes:
  13.  
  14. >>ModemWorks uses the Extended Firmware
  15. >>routines in the Apple IIGS's serial interface.
  16. >>I've not heard of any
  17. >>ModemWorks-based systems having any trouble with hardware flow control.
  18.  
  19. >Interesting.  How often is hardware flow control exercised with MW3.0?
  20.  
  21. This is transparent to ModemWorks because the IIGS serial port firmware
  22. takes care of it.  The answer to your question is: as often as is
  23. necessary. Since ModemWorks operates using the IIGS's default 2K
  24. interrupt buffer, flow control would be asserted when it became
  25. approximately 3/4 full.
  26.  
  27. >To cause it to occur would require a situation like this: ProLine's port rate 
  28. >at a higher rate  than the caller has his/her port rate set to or higher than 
  29. >the modem can move the data, & a Zmodem download to a system that can't 
  30. >handle the speed.
  31.  
  32. That's one scenario.  And, yes, ModemWorks wants to run with the port
  33. set to a high fixed speed (to get the most out of high speed modems with
  34. data compression).  You can say the same thing for a caller who is
  35. connected at 300bps and is getting a file with 1K XMODEM.  The protocol
  36. isn't the factor.  Flow control would also come into play if the caller
  37. was simply bulk-reading messages in the conference system non-stop (raw
  38. ASCII stream).
  39.  
  40. The only time I've ever heard of ModemWorks/ProLine systems having
  41. trouble with flow control is when they've not been using a properly
  42. wired HWFC cable.
  43.  
  44. >Does ModemWork's Zmodem stream (keep sending until naks appear -
  45. >regardless of lack of acks) or does it have a relatively  small window
  46. >size?  If the latter, then flow control might almost never be 
  47. >exercised...
  48.  
  49. When sending, it waits for ACKs if the receiving end requires them. 
  50. When receiving, the buffer size varies depending on available memory,
  51. but 12K is average.  Receiving 12K could easily overflow the IIGS's 2K
  52. serial buffer and/or the modem's internal buffer, so flow control would
  53. be asserted.
  54.  
  55. Again, we've had no problems except with systems that aren't set up
  56. properly to handle high speed communications (e.g. anemic cables).  Most
  57. Mac and PC users of ProLine have had success in uploading and
  58. downloading with ZMODEM.  ProLine/ProLine and ProLine/UNIX systems have
  59. not had trouble exchanging large packet transfers at high speed.  But
  60. the majority of users experiencing difficulty are Apple II users using
  61. ProTERM.
  62.