home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sgi / 13170 < prev    next >
Encoding:
Text File  |  1992-09-01  |  2.8 KB  |  58 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!rpi!utcsri!geac!alias!chk
  3. From: chk@alias.com (C. Harald Koch)
  4. Subject: Incoming UUCP flow control problem?
  5. Message-ID: <1992Sep1.152548.19218@alias.com>
  6. Sender: news@alias.com (News Owner)
  7. Organization: Alias Research, Inc., Toronto ON Canada
  8. Date: Tue, 1 Sep 1992 15:25:48 GMT
  9. Lines: 47
  10.  
  11. We have a SGI IRIS-4D/80S running IRIX 4.0.1 with a 6-port serial board.
  12. There are two modems used exclusively for UUCP connected to the on-board
  13. modem ports, and four more modems connected to the 6-port board. All modems
  14. are Telebits; the two UUCP modems and two of the others are TB+; the
  15. remaining two are T2500s.
  16.  
  17. We have several PEP UUCP links to various local and LD sites. We have a
  18. couple of V.32 links also, using the T2500s.
  19.  
  20. The modems are all connected with "proper" cables; the two on-board ports
  21. use the standard flow-control cable described in the owners manual, and the
  22. CDSIO modems use a cable described to me by the TAC (pins 1 and 6
  23. disconnected). I'm using the ttyf device for all modems. The modems are all
  24. configured to use RTS/CTS full duplex handshaking, by the fix-telebit script.
  25.  
  26. Problem:
  27.  
  28. I've been seeing lousy throughput on all incoming UUCP connections, much
  29. worse than would be expected from even a busy 4D/80. (My 8MHz 68000 based
  30. Amiga can keep up with a TB+; I'd expect a 16MHz R2000 to have no problems).
  31. Throughputs have been 100-250 cps incoming, v.s. 1300+ outgoing on the PEP
  32. links; 100+ incoming v.s. 850+ outgoing on the V.32 links.
  33.  
  34. I decided to turn UUCP debugging on, to see what's going on. I discovered
  35. the following: incoming UUCP data is being trashed and/or dropped on a
  36. regular basis. I'll see a normal incoming packet stream, and then something
  37. like ..., 1, 2, 3, 4, 6. Packet 4 is usually trashed, and packet 5 is
  38. missing altogether. A UUCP retry always fixes this, but the error eventually
  39. happens again. On large file transfers, the remote UUCP usually decides it's
  40. seen too many errors and hangs up.
  41.  
  42. This looks suspiciously like a flow-control problem. It goes away altogether
  43. at 2400bps. It's worse on the on-board ports than it is on the 6-port board.
  44.  
  45. I've also tried the same configuration files and cables on a 4D/35S running
  46. 4.0.5A. There were 0 errors in the transmission of a 940K file, and the
  47. throughput was 1401 cps.
  48.  
  49. Help! I can't guess why this would be happening; to the best of my
  50. knowledge, everything is hooked up and configured correctly. Any suggestions
  51. from Out There would be greatly appreciated!
  52.  
  53. --
  54. "You are at wit's end.      | C. Harald Koch  Alias Research, Inc. Toronto, ON
  55. Passages lead off in all    | chk@alias.com                (work-related mail)
  56. directions..."  -related by | chk@gpu.utcs.utoronto.ca     (permanent address)
  57.     Bryan Manske, 13-Aug-92 | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)
  58.