home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / dcom / isdn / 1072 < prev    next >
Encoding:
Text File  |  1993-01-05  |  1.8 KB  |  38 lines
  1. Newsgroups: comp.dcom.isdn
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!news.u-tokyo.ac.jp!ccut!s.u-tokyo!is.s.u-tokyo!jeff
  3. From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
  4. Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
  5. References: <725842056.AA00743@cswamp.apana.org.au> <bob1.726244213@cos>
  6. Nntp-Posting-Host: chanel
  7. Message-ID: <1993Jan5.170810.13055@kei.is.s.u-tokyo.ac.jp>
  8. Reply-To: jeff@is.s.u-tokyo.ac.jp
  9. Organization: University of Tokyo / Object Technology International
  10. In-Reply-To: bob1@cos.com's message of Tue, 5 Jan 1993 14:30:13 GMT
  11. Sender: news@kei.is.s.u-tokyo.ac.jp (Usenet News System)
  12. Date: Tue, 5 Jan 1993 17:08:06 GMT
  13. X-Bytes: 1122
  14. Lines: 23
  15.  
  16. In article <bob1.726244213@cos> bob1@cos.com (Bob Blackshaw) writes:
  17.  
  18.  >In their demo at TRIP'92, France Telecom showed me a compression
  19.  >algorithm (or at least the effects of one) over ISDN. When I asked
  20.  >if it was V.42bis, they said no. According to the person I was
  21.  >speaking with, they found V.42bis too processor intensive for a
  22.  >64 kbit/s line and it actually slowed throughput. They claimed to
  23.  >be achieving throughput in excess of 110 kbit/s on a 64 kbit/s
  24.  >line. I didn't have a stopwatch with me, but it certainly looked
  25.  >impressive. Hopefully, they will submit it to CCITT.
  26.  
  27. I am not sure that I understand the compression problem.  There are
  28. several schemes available that do on the fly compression on data to
  29. disk.  The data rates are significantly higher and they actually make
  30. the disk interaction faster.  That is, the amount of time saved
  31. reading bytes is greater than the extra required to de/compress.
  32. Given that 64kbits/s is at least a couple orders of magnitude less, I
  33. would have thought that this would not be an issue.  How are the cases
  34. different?
  35.  
  36. --
  37. ato de, |m        -- Death by stereo!
  38.