throbber
http://groups.google.com/d/topic/comp.dcom.modems/gA5a9ugoWcM/discussion
`comp.dcom.modems ›
`Telebit registers
`9 posts by 9 authors
`Ed Wells
`5/21/89
` After calling another Telebit modem in PEP mode, have you ever gone
`back to local mode and checked out the S60's and S70's registers while
`the connection was connected? I did and found what appears to be
`several line/carrier condition tables with the grade of each of the 511
`carriers.
` I tried making a local call several times to the same number and noticed
`that each time I found small differences in these numbers (I assume the
`line sampled slightly differently each time).
` For those hacker types, you may want to try to obtain exactly what type
`of connection you have on your long distance calls. I don't know, but
`Telebit themselves may actually be interested in this information for
`modem evaluation.
` No matter what these numbers come up with, I'm very happy with my
`Telebit modem. This still appears to the the Cadillac of the 19,200
`baud modems.
`--
`=========================================================================
`Edward E. Wells Jr., President Voice: (215)-943-6061
`Wells Computer Systems Corp., Box 343, Levittown, Pa. 19058
`{dsinc,francis,hotps,lgnp1,mdi386,pebco}!wells!edw
`Click here to Reply
`Russell Lawrence
`5/24/89
`In article <49@wells.UUCP>, edw@wells.UUCP (Ed Wells) writes:
`> After calling another Telebit modem in PEP mode, have you ever gone
`> back to local mode and checked out the S60's and S70's registers while
`> the connection was connected? I did and found what appears to be
`> several line/carrier condition tables with the grade of each of the 511
`> carriers. ^^^^
`Could someone please post how-to info on interpreting the table? I've
`tried checking the contents of register 76, but what I get is a listing
`that varies from eight numbers to about a hundred... *not* 511.
`BTW, Ed mentioned in a previous article that he was unable to get his
`TB+ to work faster than 9600 on outgoing calls. My uucico supports
`19.2 kbs calls, but I've never (ever) been able to get a throughput
`of more than 700 bytes per second. One of my net neighbors thinks
`the problem might be line noise, but I'm beginning to suspect that something
`else is wrong. If anyone else has encountered a similar problem, how
`about sharing the solutions?
`--
`Russell Lawrence, WP Group, New Orleans (504) 443-5000
`uunet!wpg!russ
`George Robbins
`5/25/89
`In article <1182@wpg.UUCP> russ@wpg.UUCP (Russell Lawrence) writes:
`> In article <49@wells.UUCP>, edw@wells.UUCP (Ed Wells) writes:
`
` BTW, Ed mentioned in a previous article that he was unable to get his
`> TB+ to work faster than 9600 on outgoing calls. My uucico supports
`> 19.2 kbs calls, but I've never (ever) been able to get a throughput
`> of more than 700 bytes per second. One of my net neighbors thinks
`> the problem might be line noise, but I'm beginning to suspect that something
`> else is wrong. If anyone else has encountered a similar problem, how
`
`>>
`
`Page 1 of 4
`
`

`
`> about sharing the solutions?
`Are you sure your neighbor isn't running with an interface rate set to
`9600 baud, either via "fixing" the baud rate with the S-registers or
`letting the "incoming" baud rate default to the speed at which he last
`talked to the modem?
`This is a "problem" I've seen a couple of times, it's really not obvious
`what the TB's are up to, since they will automatically do baud rate
`adaption. The numbers are a clue though, since 700 char/sec is in the
`ball park thruput you get at a 9600 baud interface rate.
`--
`George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr
`but no way officially representing arpa: cbmvax!g...@uunet.uu.net
`Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
`Henry Spencer
`5/25/89
`In article <1182@wpg.UUCP> russ@wpg.UUCP (Russell Lawrence) writes:
`>Could someone please post how-to info on interpreting the table? I've
`>tried checking the contents of register 76, but what I get is a listing
`>that varies from eight numbers to about a hundred... *not* 511.
`Sure you aren't losing some of them because of lack of flow control on
`the line between modem and host? It's really easy to drop a chunk of
`stuff when you ask a TB for something like a register listing and your
`host can't keep up with full-blast input.
`--
`Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology
`deadly hazards to spaceflight. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
`Bill Mayhew
`5/26/89
`The line status registers (S70 .. S78) are indeed documented as
`follows in the manual. In case of misplaced manuals, they are:
`S70 Instantaneous Transmit Rate. Outbound raw bit rate, not
` necessarily the actual throughput.
`S71 Transmit Bits Per Channel. Reports number of bits
` currently in use for all 511 carriers. Read only.
`S72 Istantaneous Receiver Rate. Inbound raw bit rate, not
` necessarily the actual throughput.
`S73 Receive Bits Per Channel. Reports number of bits
` currently in use ofr all 511 carriers. Read only.
`S74 Received Packets Retrasmitted. Number of received packets
` requiring retransmission since start of this call.
` Read only.
`S75 Packets Accepted. Number of good packets received since
` current call began. Read only.
`S76 Equivalent Line Noise Profile. CNR to the nearest 1/10th
` dBm at all 511 frequency points. Read only. Now this is
` definitely a cool register!
`S77 Frequncy Offset. Observed frequency offset of the communi-
` cations channel in Hz. to the nearest 1/16 for the current
` connection. Valid for either PEP or regualr connection.
`S78 Slow Mode Line Quality. Merit figure 0 .. 100. 50 or
` or higher menas that the line will support acceptable
` communication. Redialing is recommended if you have a
` merit of less than 30.
`Bill
`wtm@impulse.UUCP
`Jean-Pierre Radley
`6/1/89
`
`Page 2 of 4
`
`

`
`High Speed transfers (was: Telebit registers)
`In article <1182@wpg.UUCP> russ@wpg.UUCP (Russell Lawrence) writes:
`>In article <49@wells.UUCP>, edw@wells.UUCP (Ed Wells) writes:
`>BTW, Ed mentioned in a previous article that he was unable to get his
`>TB+ to work faster than 9600 on outgoing calls. My uucico supports
`>19.2 kbs calls, but I've never (ever) been able to get a throughput
`>of more than 700 bytes per second. One of my net neighbors thinks
`>the problem might be line noise, but I'm beginning to suspect that something
`>else is wrong. If anyone else has encountered a similar problem, how
`>about sharing the solutions?
`The calling computer must be running at 19200, and also the receiving
`computer.
`On the dial-out port, stty should reveal a speed of 19200. On the
`receiving computer, the gettydefs for the receiving port should also be at
`19200.
`CPU <-@19200-> TB <-@9600-> telephone lines <-@9600-> TB <-@19200-> CPU
`Each computer talks with its trailblazer at 19200.
`Each trailblazer talks with the telephone line at 9600.
`The faster throughputs, up to 1700 or 1800 bytes/sec, occur on ASCII files,
`or data files with lots of blocks of nulls or spaces. The trailblazers can
`compress such files while in PEP mode.
`Files which are already compressed, or most binary files, will not transfer
`at such a rate.
`--
`Jean-Pierre Radley CIS: 72160,1341 jpr@jpradley.UUCP
`Chris Lakewood
`6/2/89
`High Speed transfers (was: Telebit registers)
`In article <9858@dasys1.UUCP> jpr@dasys1.UUCP (Jean-Pierre Radley) writes:
`>CPU <-@19200-> TB <-@9600-> telephone lines <-@9600-> TB <-@19200-> CPU
` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
`>Each computer talks with its trailblazer at 19200.
`>Each trailblazer talks with the telephone line at 9600.
`>The faster throughputs, up to 1700 or 1800 bytes/sec, occur on ASCII files,
`>or data files with lots of blocks of nulls or spaces. The trailblazers can
`>compress such files while in PEP mode.
`>Files which are already compressed, or most binary files, will not transfer
`>at such a rate.
`>--
`>Jean-Pierre Radley CIS: 72160,1341 jpr@jpradley.UUCP
`Wrong. The two modems communicate using PEP at varying speeds up to
`18,000 bps. The content of the data (i.e. binary vs. ASCII) has
`NOTHING to do with the speed at which the modems communicate.
`An extension to PEP called PEP2 supports data compression and can
`achieve speeds of 19,200 bps on compressible data.
`It is not uncommon to see speeds of 1400 characters/sec or more on
`data that is ALREADY compressed. This is where Telebit is way ahead
`of the other "high-speed" modem makers. Their claims of 9600, 19200, or
`38,400 are based on sending data which is highly compressible. If the
`data is already compressed, their thoughput goes WAY down.
`Please check you facts.
`hami...@osiris.cso.uiuc.edu
`6/4/89
`High Speed transfers (was: Tele
`chris@netcom.UUCP says:
`> It is not uncommon to see speeds of 1400 characters/sec or more on
`> data that is ALREADY compressed. This is where Telebit is way ahead
`> of the other "high-speed" modem makers. Their claims of 9600, 19200, or
`
`Page 3 of 4
`
`

`
`> 38,400 are based on sending data which is highly compressible. If the
`> data is already compressed, their thoughput goes WAY down.
` Please check you facts.
`i can't speak for all high-speed modems, but my old HSTs routinely got
`~1100 c/s on already compressed files, and my new HSTs (50% faster) get
`over 1600.
`Daniel A. Graifer
`6/6/89
`High Speed transfers (was: Tele
`I have a pair of Prime EXLs that were running ATT SysV 3.0 hdb uucp over
`TB+ long distance (VA to CA) and routinely achieving 1400cps. Recently,
`the VA machine was upgraded to 3.1, and uucico at 19,200 stopped working. I
`can only get garbage unless I slow down to 9600. This is true when I call
`uunet as well. Prime says they are aware of this, but cannot tell me why.
`Anybody have any ideas what they broke in this release? FYI, 3.1 was the
`release of "Network Support Utilities" and the routing of everything thru
`STREAMS.
`Thanks in advance.
`Dan
`(Note, use address below, "Reply" may not work.)
`------
`Daniel A. Graifer Franklin Capital Investments
`uunet!fciva!dag 7900 Westpark Drive, Suite A130
`(703)821-3244 McLean, VA 22102
`
`>>
`
`Page 4 of 4

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket