home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / modems / 13077 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.7 KB  |  58 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!sun-barr!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Optimizing Telebits.
  5. Message-ID: <piennvg@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Sep6.135028.22661@homecare.com> <1992Sep7.182013.7094@ntg.com>
  8. Date: Mon, 7 Sep 1992 19:37:19 GMT
  9. Lines: 47
  10.  
  11. In article <1992Sep7.182013.7094@ntg.com>, dplatt@ntg.com (Dave Platt) writes:
  12. > ...
  13. > >4)  And last - this is just a little pet peeve.  For some reason these
  14. > >WorldBlazers think they need to retrain when they lose the modem on
  15. > >the other side.  The other end will cut off the connection and the
  16. > >WB's CD light starts blinking like it is retraining.  How can I stop
  17. > >this from happening?  I wan't the damn thing to hang up and not wait
  18. > >10 seconds while it figures out the line has been dropped.  I've seen
  19. > >no other Telebits do this and it is aggravating to have this one do
  20. > >it.
  21. > 
  22. > That's pretty much in the nature of V.32, I believe.  V.32 uses a single
  23. > carrier frequency, with adaptive echo cancellation.  It's not terribly
  24. > easy for a V.32 modem to tell (quickly) that its peer at the other end
  25. > has disconnected, since it continues to "hear" the carrier signal come
  26. > back (its own carrier, delayed and mixed).  If the modem is more quick
  27. > to hang up when carrier is actually dropped, it will probably also be
  28. > more prone to disconnect prematurely if there's a burst of noise on the
  29. > line.
  30.  
  31.  
  32. There may be more to it than that.
  33.  
  34. I don't pretend to know the real mathematics about what is going on
  35. while stuffing nearly the Shannon limit of bits down a pair of wires.
  36. (tho I do know enough to suspect that many who have written on that
  37. subject in this newsgroup are at best as ignorant as I am.)
  38.  
  39. Still, consider the number of possible states of the wire as seen by
  40. the local modem.  As you approach the Shannon limit, how many of those
  41. are nonsense and how many are valid states signifying that the other
  42. end wants to send you a particular set of bits?  It seems to me that as
  43. you increase the number of bits, it should get more and more difficult
  44. and take more and more time for the local modem to decide that the
  45. other end has disappeared.  At the limit, every possible state or
  46. sequence of states of the wire (whether specified in time or frequency)
  47. must correspond to a valid set of data bits with a permitted addition
  48. of some noise.  At the limit, with no reduncancy at all (either in the
  49. lowest layer of modulation or in the higher layers of stuff like v.42),
  50. the receiving modem can never and will never decide the other end has
  51. gone away.
  52.  
  53. Is 14.4Kb/s FDX close enough to the Shannon limit for this effect to be
  54. significant?
  55.  
  56.  
  57. Vernon Schryver,  vjs@sgi.com
  58.