home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / bit / listserv / ibmmain / 2851 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  1.6 KB
  1. Path: sparky!uunet!noc.near.net!hri.com!ukma!psuvax1!psuvm!pmw1
  2. From: PMW1@psuvm.psu.edu (Peter M. Weiss)
  3. Newsgroups: bit.listserv.ibm-main
  4. Subject: Re: Help with NRZ vs NRZI on SYS/36 ...
  5. Message-ID: <92351.092433PMW1@psuvm.psu.edu>
  6. Date: 16 Dec 92 14:24:33 GMT
  7. References: <IBM-MAIN%92121512464474@RICEVM1.RICE.EDU>
  8. Organization: Penn State University
  9. Lines: 25
  10.  
  11. In article <IBM-MAIN%92121512464474@RICEVM1.RICE.EDU>, Mark Bandak
  12. <MARK@MONTCOLA.BITNET> says:
  13.  
  14. In my limited experience with NRZ, it is related to the sensitivity
  15. of the DCE (modem, DSU/CSU) to bit patterns.  In some circumstances,
  16. because of carrier facilities, it will only support NRZI=NO e.g.,
  17. certain multiplexors.
  18.  
  19. It sounds like you have timing problems.  If you are using a carrier
  20. digital facilities, it seems to me that your DTEs (S/36 and 5294)
  21. should be deviving their clocking signals from the DCE i.e., External
  22. Clocking (from the DTE point-of-view).  Now the next question is where
  23. do the DCEs derive their clocks?  My guess is this is where your
  24. problem resides.  Note that one DCE need be symmmetrically configured
  25. to the other DCE i.e., one could provide clocking, whereas the other
  26. could _derive_ clocking from the other.
  27.  
  28. Or you could have a carrier synchronization problem.  You will want
  29. to get your local telecom folks involved, no doubt.
  30.  
  31. /Pete (pmw1@psuvm.psu.edu)
  32. --
  33. Peter M. Weiss                     | not affiliated with psuvm.psu.edu|psuvm
  34. 31 Shields Bldg -- Penn State Univ.| "Connectivity is more than a Connection"
  35. University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92
  36.