home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sun / admin / 4883 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.1 KB
  1. Path: sparky!uunet!paladin.american.edu!europa.asd.contel.com!darwin.sura.net!mips!sdd.hp.com!hp-cv!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!news
  2. From: fitz@frc2.frc.ri.cmu.edu (Kerien Fitzpatrick)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Custom ethernet mediums
  5. Keywords: ethernet, fiberoptics
  6. Message-ID: <1992Jul22.222716.84612@cs.cmu.edu>
  7. Date: 22 Jul 92 22:27:16 GMT
  8. Article-I.D.: cs.1992Jul22.222716.84612
  9. Reply-To: fitz@frc2.frc.ri.cmu.edu
  10. Organization: Field Robotics Center, Carnegie Mellon University
  11. Lines: 31
  12. Nntp-Posting-Host: dirt.frc.ri.cmu.edu
  13.  
  14. One of our robotics projects has special requirements for data transmission
  15. over a tether between a transporter and a walking robot.  Issues of power,
  16. size, weight are severe.  What was decided was to multiplex signals over
  17. a pair of fibers at various freqs.  Everything seems to work okay, but actual ethernet
  18. communications between the Sun(s) on the walking robot and the Sun(s) on
  19. the transporter are having a bit of trouble.  It seems that when the Sun
  20. transmits a packet that the receive buffer is filled with that packet - this
  21. is something we cannot easily do with our system (one fiber dedicated to 
  22. transmit and one fiber dedicated to receive).  What happens is that the
  23. data is sent and it is correct, but the Sun decides that an error occurred
  24. because nothing was written into its receive buffer immediately.  We know
  25. the packets are okay, because the remote systems (one is a real-time system
  26. which eventually boots from files transferred from the transporter)
  27. can function (the effective baud rate is around 400....really bad).
  28.  
  29. Does anyone know how we can disable the Sun from checking its receive buffer
  30. to read back what it just sent?  Our only other alternative is to use PPP
  31. or SLIP, but we would prefer not to do this for various reasons.  Any
  32. insights or assistance is appreciated because our timeframe is very, very
  33. tight.
  34.  
  35. Thanks,
  36. Kerien Fitzpatrick
  37.  
  38.  
  39.  
  40. ---
  41. Kerien Fitzpatrick            Pittsburgh, PA 15213
  42. Field Robotics Center            (412)268-6564
  43. The Robotics Institute            Internet: fitz@frc.ri.cmu.edu
  44. Carnegie Mellon University
  45.