home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / tcpip / 5585 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  1.5 KB
  1. Path: sparky!uunet!stanford.edu!unix!updike!ric
  2. From: ric@updike..sri.com (Richard Steinberger)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Multiport repeaters and collision propagation
  5. Message-ID: <ric.724092787@updike>
  6. Date: 11 Dec 92 16:53:07 GMT
  7. Sender: news@unix.SRI.COM
  8. Lines: 30
  9.  
  10.  
  11.     I am working with a hardware networking engineer who is helping
  12. me figure out why packets appear to be dropped when they are
  13. transmitted between a SUN fileserver in one building and a client
  14. SUN in another.  Between the buildings are a 2-port Xerox repeater,
  15. a Codenoll multiport fiber optic star and a TCL multiport repeater.
  16. Both Suns are connected to Thicknet on ports of a multiport
  17. transceiver.
  18.  
  19.     He claims that it is not uncommon for multiport repeaters
  20. and even transceivers to NOT propagate collision signals to
  21. nodes on the repeater where the collision did not occur.  In other
  22. words,  he says that some multiport devices isolate collision signals
  23. to the branch where they occur.  Can anyone confirm such behavior?
  24. If this is indeed happening, can it not cause problems if a computer
  25. a node or more away is unaware of a lost packet(s) it transmitted.  A 
  26. timeout would need to occur and a retransmission request sent?
  27.  
  28.     The symptoms we have seen are very long file transfer times
  29. (via NFS) and slow interactive response on X terminals on machines
  30. in a different building from the fileserver (and X client machine).
  31.  
  32.     Any comments, suggestions or recommendations would be 
  33. appreciated.  Thank you.
  34.  
  35. regards,
  36.  
  37.     ric steinberger
  38.     ric@updike.sri.com
  39.  
  40.