HDTenEightyP/NetNews huggingface dataset:
From: litwack@dccs.upenn.edu (Mark Litwack)
Newsgroups: comp.dcom.modems
Subject: Re: SLIP+Telebit+Annex+Flow Control = Problem
Date: 15 Apr 92 21:39:22 GMT
Organization: University of Pennsylvania

In article <1992Apr10.172443.15529@westford.ccur.com>, dhb@westford.ccur.com (Don Barstow) writes:
|> 
|> I ported the PD 386 SLIP streams module to my machine (not
|> a 386, but still a STREAMS TCP/IP environment).  Between two
|> machines with a direct null-modem link at 19200, I have had no
|> problems.  But when I set it up over the phone line as seen in
|> this picture, I have a real problem.
|> 
|> ______                     ______
|> |    |   ____       ____   |    |
|> | C1 |===|M1|-------|M2|===| C2 |-/\/\Ethernet
|> |    |   ----       ----   |    |
|> ------                     ------
|> 
|> C1 is me on my machine at home.  M1 is a Telebit T2500, M2 is a T1600,
|> and C2 is really an Annex terminal server Ethernetted into all the
|> machines at work.  The connection established between the two modems
|> is V.32 with V.42 and V.42bis (I get the CONNECT 9600/LAP-M message
|> when it connects).  The M1-C1 link is locked at 19200, while the 
|> M2-C2 connection is locked at 38400.
|> 
|> I have no problem with rlogins or telnets.  My problem comes with file
|> transfers.  With hardware flow control set at both ends, after a little
|> while, I see my modem (M1) turn off CTS and leave it off forever.  This
|> is much more common if C1 is rcp'ing to C2 (really thru C2 to something on
|> the Ethernet).  Both directions seem worse with binary files than ASCII
|> files.
(additional description deleted).

We stumbled across this bug in the Annex too (at least in version
B6.2.11).  The annex does not handle hardware flow control correctly
with slip enabled.  The annex will drop RTS and leave it down if you
send it a long packet.  Your modem will eventually drop CTS after enough
data has backed up.  It is supposedly fixed in the 6.2 release, but
I haven't seen it yet.  We found that a good temporary fix is to turn
off the input flow control on the annex since the annex seems to be able
to buffer the data with no problem.

Also, you might want to be aware that running an annex at 38400 isn't
a good idea without a special hardware ECO to fix the rise and fall
times of TxD.  Xylogics purposely increased the transition times to make
the signal less susceptible to cross talk.  The problem is that they
made it a constant Volts/second at all speeds.  At low speeds this is
not a problem, but at 38400 the rise and fall times are a significant
fraction (like 30-35%) of the bit time.  This is *way* out of the
RS232 spec of 4% maximum.

I'm mentioning this because you may also have data corruption problems.
The RS232 receivers in the Telebits (at least the T3000 on which we
discovered this problem) don't like the large rise and fall times.
As a matter of fact, they weren't useable at 38400 at all with the
annex, but I can hardly blame Telebit.

Hope this helps.

-mark
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.dcom.modems
Subject: Re: PEP
Date: Sun, 12 Apr 92 09:44:54 EDT
Organization: Izot's Swamp

gerg@netcom.com (Greg Andrews) writes:

> The symbol timings for PEP are:
> 
> 	Long  - 136 ms
> 	Short -  24 ms
> 	Micro -  15 ms
> 
> If you send 136 ms symbols, your symbol rate is 7.35.  (1 / 0.136)
> If you send 24 ms symbols, your symbol rate is 41.67.  (1 / 0.024)
> If you send 15 ms symbols, your symbol rate is 66.67.  (1 / 0.015)
> 
> While transferring large volumes of data (e.g. file transfers) PEP
> uses Long symbols.  Using the term "Baud rate" in it's correct sense
> of symbols per second, the modem runs at about 7.4 baud during file
> transfers.

   This is the first I've heard of shorter symbols for PEP; under what 
circumstances are they used?  Are these the factors adjusted in Telebit's 
article on adverse noise handling?

Geoffrey Welsh, 412-305 Margaret Avenue, Kitchener Ontario, N2H 6S4 Canada
geoff@zswamp.uucp, { watmath!xenitec | m2xenix }!zswamp!geoff (519)742-1228
"Show us your sig." "Seeg?  I don't need no steenking seeg!"
Newsgroups: comp.dcom.modems
From: SLENDT@athena.unomaha.edu (STEVE LENDT - C&DC NETWORK )
Subject: Compressed files and v.32bis
Organization: University of Nebraska at Omaha
Date: Sat, 11 Apr 1992 01:32:38 GMT
X-News-Reader: VMS NEWS 1.11

   A lot of the files that get transmitted over modems have been
compressed (zip, arc, etc).  What kind of effect does this have
on transfer times over a pair of v.32bis modems?  I've been told
that if you transfer an lharc compressed file using Zmodem or
simple binary Kermit that the transfer times will be close.
Is this true?  I would think there would be more to it than that.

 ____________________________________________________________________________
|  Steven Lendt, Campus Network Mgr   |   SMTP: slendt@unocdc.unomaha.edu    |
|  University of Nebraska at Omaha    |   or:   slendt@athena.unomaha.edu    |
|  Computing and Data Communications  |   bitnet (if you must) slendt@unoma1 |
|  6001 Dodge Street                  |   Voice Phone (402) 554-2523         |
|  Omaha, NE 68182-0051 USA           |   Fax (402) 554-3475                 |
|  The attention span of a computer is only as long as its electrical cord.  |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Xref: sparky comp.dcom.modems:6583 comp.sys.mac.comm:4591
From: speth@cats.ucsc.edu (James Gustave)
Newsgroups: comp.dcom.modems,comp.sys.mac.comm
Subject: HELP NEEDED! with Hayes Smartmodem!
Date: 11 Apr 92 19:45:07 GMT
Followup-To: comp.dcom.modems
Organization: University of California, Santa Cruz


  Hi, I'm in need of a little help with setting up my modem.  I have an old
Hayes V-Series Smartmodem 9600 (NOT the "ultra"), which I'm using with a
Mac IIsi.  Currently I have its higher functions disabled, and I'm using
it as a 2400 baud modem.  I was wondering if I could use it more efficiently
if I configure it differently.
  I use it mainly for connecting to my school's unix system, which has 2400
baud lines, and some USR Dual Standards.  What should I do to get the most
out of this modem??  (By the way, I am using a regular mac-modem cable,
NOT a hardware handshake cable.)

Thanks.


-- 
Jim Speth
speth@cats.ucsc.edu
Newsgroups: comp.dcom.modems
From: nolan@helios.unl.edu (Michael Nolan)
Subject: Re: Telebit Loyalty pays
Reply-To: nolan@helios.unl.edu
Organization: University of Nebraska - Lincoln
Date: 13 Apr 92 17:06:57 GMT

gerg@netcom.com (Greg Andrews) writes:

>Heck, the announcement was made the first or second week of November 1991.
>That makes it over FOUR months from the date of the announcement to the
>end of the offer.

Well, not quite.  The original Loyalty Pays campaign started on Dec 9th.

At a guess, the delay in shipment of the ROM upgrades has been some problems
that developed in beta testing.  (I'm not aware of any, nor was/am I a beta 
tester, so this is speculation on my part.)  

All things considered, I would rather TB be a few weeks 'late' than to receive 
a buggy ROM and have to go through the hassle of getting a second upgrade.  
(I've spent enough time on the phone with TB Tech Support, thanks anyway, just 
solving problems with my T1600's.)
---
Michael Nolan
nolan@helios.unl.edu, nolan@tssi.com
<<< dis.sigfectant Ver 1.0b1: remove the .sig virus from your .sig NOW!!
From: editor@wet.UUCP (Eric Swanson)
Newsgroups: comp.dcom.modems
Subject: Re: More serial line tidbits
Summary: come on
Keywords: let's get basic...
Date: 8 Apr 92 08:09:16 GMT
Followup-To: comp.dcom.modems
Organization: Wetware Diversions, San Francisco

wolfgang@netcom.com (Wolfgang Henke) asks:
>... Why cant we just send serial signals into the
>phone exchange? Lets transmit at -9 db ...
<lots of moot points deleted>
>Problems: We need 19 gauge wire with low loss.
>	  We need four wire circuit to reduce noise.
>	  Crosstalk between adjacent wirepairs in phone company cables is
>          significant and might not allow all pairs to run at T1.

You forgot a couple:

        We need an end-to-end copper circuit for all this to
         go through.
        We need something on the other end it can talk to.

When your subscriber line gets to your serving Central
Office, it gets hooked into one form or another of analog-
to-digital converter (probably either a channel bank or an
analog station card in a digital matrix switch).  At this
point your serial signals cease to exist -- they get
digitized away into effectively meaningless noise, if
anything.

So if you want this signal to go anywhere beyond your
serving CO, you'll need to get your local phone company to
offer to translate between your 1.5-megabit serial line and
their existing switched digital network.  In fact, this
service already exists in some places.  It's usually called
"Switched T1" or "Switched 1544", and it costs about a
godzillion bucks a year, plus usage...

>All this looks rather simple, but let me assure you it is not.

True enough.

E.
-- 
------------------------------------------------------------------------
editor@wet.UUCP   {ucsfcca,hoptoad}!wet!editor   wet!editor@cca.ucsf.edu
 make my funk the p funk; i want my funk uncut
 make my funk the p funk; i wants to get funked up
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.dcom.modems
Subject: Re: Are 16550'a pin compatible with 16450's?
Date: Tue, 07 Apr 92 20:50:20 EDT
Organization: Izot's Swamp

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

> Are you sure?  My copy of the National data sheet says on the first page
> "after reset, all registers are identical to the 16450 register set."  The
> block diagram in section 5.0 implies the FIFO's are bypassed in 16450
> mode.  The text throughout suggests the FIFO's have no effect when off.

   This is true.

> Consider their claim that the 16550A is identical to a 16450 when the
> FIFO's are off when the chip is suffering overruns.  What about code that
> hopes to clear the 16450 input buffers with a fixed sequence of reads?  The
> 16550 would not look at all identical if the FIFO's had any effect.

   Serial drivers which respond to an interrupt by reading only one byte and 
exiting (clearing the interrupt as it leaves) will not far much better with a 
16550's buffer than they would with a 16450.

Geoffrey Welsh, 412-305 Margaret Avenue, Kitchener Ontario, N2H 6S4 Canada
geoff@zswamp.uucp, { watmath!xenitec | m2xenix }!zswamp!geoff (519)742-1228
"Show us your sig." "Seeg?  I don't need no steenking seeg!"
Newsgroups: comp.dcom.modems
From: hwr@pilhuhn.ka.sub.org (Heiko W.Rupp)
Subject: Re: ZyXEL
Organization: The Home of the Pilhuhn
Date: Tue, 14 Apr 1992 10:58:17 GMT

Heribert_Otten@k2.maus.de (Heribert Otten) writes:
>In a message of Do, 09.04.92  rlcarr@animato.uucp wrote:

>r>(2) Can they initiate and respond to retrains both faster and slower?
>i can't help you on your first questions, but (2) would be interesting to know

Here the manual says:

*Q0	No response to poor signal quality
*Q1	Retain action taken if signal quality is poor
*Q2	Adaptive rate; auto fallback or fall forward (Default)
*Q3	Disconnect for poor quality signal.
-- 
Heiko W.Rupp  Gerwigstr.5  7500 Kh'e 1  hwr@pilhuhn.ka.sub.org  +49 721 693642
When I met th'POPE back in '58, I scrubbed him with a MILD SOAP
 or DETERGENT for 15 minutes.  He seemed to enjoy it..
Newsgroups: comp.dcom.modems
From: datri@convex.com (Anthony A. Datri)
Subject: Re: Telebit Loyalty pays
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Distribution: na
Date: Sat, 11 Apr 1992 20:49:17 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

>with Telebit sales staff I was told that my credit card would not be charged
>until the modem was about ready to ship (1-3 days before ship date).

As I understand it, that's required by law.
-- 


======================================================8--<
From: gerg@netcom.com (Greg Andrews)
Subject: Loyalty Pays Again, PEP Upgrade, T3000 and WorldBlazer
Date: Tue, 14 Apr 92 02:02:27 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Summary: Finally!


There's been a lot of talk about the new Loyalty Pays Again promotion, and
some people have noted that the T3000 is offered, but without the free PEP
upgrade.  Here's why.

Telebit just announced the WorldBlazer modem (finally!).  This is a separate
model from the T3000.  The T3000 is a V.32bis modem.  The WorldBlazer is
the PEP/V.32bis modem.

The WorldBlazer's PEP is an enhanced version called "Turbo PEP".  Turbo
PEP's typical uncompressed data throughput is 23,000 bps, and it supports
V.42bis data compression.  It is fully compatible with existing PEP modems.

The WorldBlazer is available under the Loyalty Pays Again offer.

*That's* why the LPA T3000 offer doesn't include any upgrade to PEP.
The PEP/V.32bis modem is also available under LPA.  If someone chooses
the T3000 instead of the WorldBlazer they must not want PEP, so an upgrade
to PEP isn't necessary.


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
From: bill.garfield@yob.sccsi.com (Bill Garfield) 
Newsgroups: comp.dcom.modems
Subject: PP and Gateway v.32bis modems
Date: 5 Apr 92 22:26:00 GMT
Distribution: world
Organization: Ye Olde Bailey BBS - Houston, TX - 713-520-1569
Reply-To: bill.garfield@yob.sccsi.com (Bill Garfield) 

TO: acct069@carroll1.cc.edu (Ron Higgins)

>Anyone have the new v.32bis/fax modem from either Gateway or Practical
>Peripherals?

>I'm looking for some reports on how good these modems are before we see
>them.  (Got a Gateway on the way, and are looking into the PP).

Cannot tell you a thing about either Ron, but I am .eta testing a pair
of the new MT1432BA/R's as well as the new MT224BAF's for MultiTech and
I can promise you they'll be worth waiting for.

Granted the M/T product line is upper echelon stuff, price wise, but it
IS quality mdse., and what's most important, Made in the USA!

They're already advertising the entire new product line in the magazines
and *shipping* the 2400 bps and 9600 bps product, albeit minus FAX for
the moment. The FAX upgrade will however be a simple (FREE) prom change
and will include (also free) their new MultiExpressFax software.  The
MT1432 14.4K unit is also nearing completion of .eta testing & tho not
shipping yet, likely will be in the near future, barring any unforseen
problems arising in late .eta.

Disclaimer: Although I am .eta testing MultiTech products, I am not a
            representative of MultiTech Systems, Inc.  I do not speak
            for MultiTech Systems.  Opinions expressed herein are my own.

---
 . OLX 2.2 . WINDOWS:  From the folks who brought us EDLIN...
   
Xref: sparky comp.dcom.modems:6397 comp.sys.mac.comm:4505
From: gsnow@clark.edu (Gary Snow)
Newsgroups: comp.dcom.modems,comp.sys.mac.comm
Subject: Re: Supra V.32bis (Disappointment)
Date: 8 Apr 92 15:38:15 GMT
Article-I.D.: clark.1992Apr8.153815.1302
Organization: Clark College, Vancouver, Wa.  USA

In article <1992Apr7.194332.13698@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu (Don Gillies) writes:
>I have noticed some trouble with the mac's communication toolbox
>(which I think has built-in ZModem).  For instance, the telecom
>program called "Termulator" uses the communication toolbox.  But
>Termulator almost always screws up a zmodem transfer, even at 2400
>baud.

The Comm Toolbox doesn't have built-in Zmodem, don't we wish.....

>If you are having problem with your supra modem, consider switching to
>a more efficient telecom program.  For instance, ZTerm 0.85 does not
>slow down tetris during a background zmodem download / upload.
>Termulator slows down tetris enough to make it useless.  Try using
>ZTerm with your new supra modem.

I recommend getting ZTerm 0.9, its the best comm program out there for the
Mac, I even like it better then Microphone II 4.0, which I also own.

Gary

-- 
-----
Gary Snow
uunet!clark!gsnow  or  gsnow@clark.edu
Xref: sparky comp.dcom.modems:6612 comp.sys.mac.comm:4603
From: nanook@eskimo.celestial.com (Robert Dinse)
Newsgroups: comp.dcom.modems,comp.sys.mac.comm
Subject: Re: Supra V.32bis (Disappointment)
Summary: Hardware Handshaking and Macs
Date: 11 Apr 92 00:00:37 GMT
Organization: <<< ESKIMO NORTH (206)-FOR-EVER >>>

In article <CKD.92Apr8000821@loiosh.eff.org>, ckd@eff.org (Christopher Davis) writes:
> 
>  Bill> == Bill Heiser <bill@unixland.natick.ma.us> 
> 
>  Bill> Isn't a so-called "handshaking cable" just a cable with all (25) lines
>  Bill> attached?  Or am I missing something here.
> 
> Yeah, you're missing about 17 pins ;-)
> 
> The Mac serial ports are mini-DIN-8 connectors.  If you've seen the
> keyboard or audio connectors on a SPARCstation, you've seen them.  (The
> IPX and IPC use them for serial ports, too, as I recall.)
> 
> There are handshaking pins available on the Mac, though you give up DTR
> and DCD to get them.  (I use a PP9600SA with hardware flow control on my
> IIci, which just replaced an SE...)

     Forgive me if this seems like a silly question.  But for hardware
handshaking with carrier detect and data terminal ready you need:

     RCV
     XMT
     RTS
     CTS
     GND
     CD
     DTR

     That's SEVEN pins, why can't Mac's do both hardware handshaking and
still have CD/DTR with an 8-pin connector?  IPX's use the 8-PIN and they
can do it, our patch panel uses RJ-45's (8-pin modular), and they can do
it, so why can't Macs?
Newsgroups: comp.dcom.modems
From: mjkobb@media-lab.media.mit.edu (Michael J Kobb)
Subject: Re: Supra transfer speeds
Organization: M.I.T. Media Laboratory
Date: Thu, 16 Apr 1992 02:32:44 GMT

In article <9835.29EBE960@ofa123.fidonet.org> Jeff.Lindstrom@ofa123.fidonet.org (Jeff Lindstrom) writes:

>    MJK>  Specifically, plain typing is fine.  Large transfers (100's of K)
>    MJK>are quite good (~1450cps -- I don't know what's limiting this), but
>    MJK>medium-sized things (like displaying a full page of text with more
>    MJK>or emacs) incurs a dead stop in transmission about ten lines down, a
>    MJK>pause for over a second, and then the rest of the page.
>
>      I have noticed that opening the capture buffer and dumping text
> can be slowed by 8-color screens.  On my system (25 MHz 68030
> Amiga), a 57,600 bps transfer is faster than my screen can update
> unless I am running a 2-color screen.

Well, that's a suggestion, but I'm running in black&white on the
monitor that I'm using.  It seems to be something either in the
remote modem, or in this one, rather than a display problem.  My
display scrolls very quickly when data is actually coming in...

Thanks,
--Mike
From: jim@n5ial.chi.il.us (Jim Graham)
Newsgroups: comp.dcom.modems
Subject: Modem an Telekom-Nebenstellenanlage? 
Distribution: world
Date: Sat, 04 Apr 92 16:42:50 GMT
Organization: Me? Organized? Hah! :-)

In article <1992Apr1.210353.12569@ukw.uucp> lupe@ukw.uucp writes:

> --- Would you care to speak English in an international newsgroups ?
> --- Your BBS being gatewayed means you have to adhere to the standards.

hmmm, I wasn't aware that there WAS such a rule, myself.  while it's true
that English is the most common language in Usenet groups I've seen, is
there any restriction that says that someone whose native language isn't
English (and may not even speak English?) should be forced to post in
English?

granted, you may be more likely to get an answer (although even that may
not be true, depending on the question), but.....

btw, looking through the replies, it seems he did get one reply....in
German.  of course, I never got very far in trying to learn German, and
that was a long time ago, so I didn't get far in reading it.  :-)

sorry for those who were bored to death by this one.....but English isn't
exactly the only language in the world....
   --jim

--
Standard disclaimer....Ever since my cat learned to type, there's no telling
whose thoughts these really are....         73 DE N5IAL (/9)
------------------------------------------------------------------------------
"If winning is not important, then commander, why keep score?"  --Worf

INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO: n5ial@n9hsi (Chicago.IL.US.Earth)
------------------------------------------------------------------------------
From: fenner@jazz.psu.edu (Bill Fenner)
Newsgroups: comp.dcom.modems
Subject: Re: Supra V.32bis FAXmodem
Keywords: Generic UNIX fax software?
Date: 8 Apr 92 03:52:46 GMT
Organization: Penn State University Mechanical Engineering

In article <1992Apr7.175119.9791@clark.edu> gsnow@clark.edu (Gary Snow) writes:
|>Can I run UUCP and incoming fax off the same modem?
|
|No, these type of modems are not intended for BBS/Dial-Up Computer
|Systems to send and receive FAXes, thats only something intended for a
|Stand-alone computer system to do.

Hm.  I guess then that my BBS line can't really receive FAXes, I'm just
imagining it.

Seriously, a smart getty that listens to modem result codes and can spawn
a different program based on them will handle FAX receiving under UNIX
just fine.

  Bill
--
Bill Fenner	fenner@jazz.psu.edu	..psuvax1!hogbbs!wcfpc!wcf
		wcf@hogbbs.scol.pa.us   (+1 814 238-9633 v.32bis)
From: fritz@scipp.UCSC.EDU (Frederick Staats)
Newsgroups: comp.dcom.modems
Subject: Re: how to make call waiting tone hang up modem ??
Date: 6 Apr 92 17:46:15 GMT
Article-I.D.: darkstar.32158
Organization: Santa Cruz Institute for Particle Physics

In article <1992Apr3.225507.3277@wam.umd.edu> harold@wam.umd.edu (James B. Harold) writes:
>In article <11766@tamsun.tamu.edu> dkf8117@tamsun.tamu.edu (Duane) writes:
>>I want the call-waiting tones too cause my modem to drop carrier.  If I
>>set the s10 register (length of no carrier before dropping) to a really
>>small value, will that work? what's too small?
>
>Mmmm.  Some of us Zoom owners had a brief thread on this earlier.
>I have been completely unable to configure my V.32 Turbo to
>do this, despite some calls to tech support.  In my old 2400
>modem, setting the S10 register did the job.

Error correction and compression (V42/V42.bis) will mask the tone and
try to do a retrain.  If you reduce the drop carrier time to be to
short you will will loose some of you noise immunity (long bursts of
line noise as well as call waiting will hang you up.)  I turn on
V42/V42.bis to keep call waiting from hanging up my modem.


-- 
Frederick Staats
fritz@scipp.UCSC.EDU -- (408) 459-3575
Santa Cruz Institute for Particle Physics
University of California at Santa Cruz
From: Jay.Ashworth@f160.n3603.z1.FIDONET.ORG (Jay Ashworth)
Newsgroups: comp.dcom.modems
Subject: Re: Loyalty Pays Again and PEP upgrade?
Date: Sun, 12 Apr 92 15:50:00 EDT
Organization: FidoNet node 1:3603/160 - Hacker's Haven, Clearwater FL

In a msg of <Sunday April 12 1992>, Ryan Miller wrote to All:

 RM> The good news in regards to the length of time Telebit is taking on the
 RM> PEP upgrade, is that it will be a new FASTER PEP. I think it's called
 RM> Turbo PEP. If you're getting the upgrade for the T3000, expect this gem
 RM> when you get the upgrade. Just to give you a comparison, old PEP might
 RM> get about 1200cps on a compressed file on a long distance call. The new
 RM> TurboPEP gets about 2000-2100cps on a compressed file long distance. It
 RM> is still in testing stages, but I can't WAIT until it comes out. This
 RM> blows away v32bis. The connect rate is something like 25k or 28k instead
 RM> of 19.2k.

Um, nifty.  I _know_ Telebit's gotta have someone in here...  Can we have official word on this?

Cheers,
-- jra

--  
Internet: Jay.Ashworth@f160.n3603.z1.FIDONET.ORG
UUCP: ...!uunet!ndcc!tct!psycho!160!Jay.Ashworth
Note:psycho is a free gateway between Usenet & Fidonet. For info write to
     root@psycho.fidonet.org.
Xref: sparky comp.dcom.modems:6332 comp.sys.mac.comm:4472