home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / sysv386 / 16350 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.6 KB
  1. Xref: sparky comp.unix.sysv386:16350 comp.unix.sys5.r4:478
  2. Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
  3. Path: sparky!uunet!think.com!ames!decwrl!csus.edu!netcom.com!gerg
  4. From: gerg@netcom.com (Greg Andrews)
  5. Subject: Re: Performance of UUCP under DELL Unix (SVR4 issue 2.2)
  6. Message-ID: <1992Nov10.000907.20363@netcom.com>
  7. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  8. References: <1992Nov8.235526.1476@jeck.amherst.nh.us>
  9. Date: Tue, 10 Nov 1992 00:09:07 GMT
  10. Lines: 42
  11.  
  12. In article <1992Nov8.235526.1476@jeck.amherst.nh.us> coffler@jeck.amherst.nh.us (Jeff Coffler) writes:
  13. >
  14. >At work, I have a DECstation 5000/200 that talks UUCP to my home system.  The
  15. >modem at work is a T-2500.  The modem at home is a Worldblazer.
  16. >
  17. >At work, during a transfer, the CTS modem indicator goes on and off (as one
  18. >would expect); the system transfers as much data as possible to the modem, and
  19. >then the modem uses flow control to moderate it.
  20. >
  21. >At home, while I'm transferring to another site, CTS *NEVER* flickers.  That
  22. >is, I have CTS/RTS always on solid.  One would think that I wasn't feeding data
  23. >to the modem fast enough, but this isn't the case (the Worldblazer serial rate
  24. >is 115k bps, fed by a Digiboard EPC/X).  Given this, it seems that the modem is
  25. >most likely not transferring at it's maximum capacity ...
  26. >
  27.  
  28. Looking just at the CTS light can be a red herring.  These are two
  29. different model modems you're looking at.  Different modem, different
  30. CTS light behavior.
  31.  
  32. The WorldBlazer's spoofing simply doesn't let the buffer fill up enough
  33. to trigger flow control.  The T2500's spoofing does.  That doesn't mean
  34. you're not giving the modem enough data to transfer efficiently.  You're
  35. giving the modem as much as it wants.  If it wanted another packet, it
  36. would return an ACK.
  37.  
  38. There is one and only one gauge of whether your transfers are moving at
  39. maximum capacity:  Measure them (preferably with a stopwatch) and compare
  40. the results with the expected throughput from the modem link.  Over a
  41. Turbo-PEP connection on good lines (S70/S72 read 25000 or higher),
  42. you should get uucp throughputs in the 1900-2100 cps range.  Higher,
  43. if your data can be compressed.  Remember that data errors in the
  44. receiving system can slow throughput down, and make you think it's
  45. the modem's fault.  Make sure you measure transfers that don't register
  46. any errors on the receiving system.
  47.  
  48.  
  49. -- 
  50.  .------------------------------------------------------------------.
  51.  |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
  52.  |                 |   Internet: gerg@netcom.COM                    |
  53.  `------------------------------------------------------------------'
  54.