lyons@cdss.UUCP (Don R Lyons) (02/16/90)
I have purchased a telebit trailblazer+ to reduce my uunet phonebills .
The system I am using is a 16MHz, Acer 386 running SCO Unix 3.2.0 . I
know the TB+ is in PEP mode running the uucp proto 'cause I watched a
xfer with uucico in debug mode. I have the following entries in the
Systems and Devices file :
Systems -> uunet Any ACU 19200 9-7038765055u ogin: ...
Devices -> ACU tty2a - 300-19200 dialTBIT \T
I am seeing uucp xfers @ 300cps and news as low as 20cps.
Is there something I am missing ? How do I get the modem to only establish
a connection with uunet at 9600bps ? Finally , is it possible that my xfer
stats are misleading ? I dont know.
Any help will be appreciated.
PS : is {ames,sun,uunet}!telebit!modems alive ?rock@rancho.uucp (Rock Kent) (02/17/90)
In article <125@cdss.UUCP> lyons@cdss.UUCP (Don R Lyons) writes:
Don> I have purchased a telebit trailblazer+ to reduce my uunet phonebills .
Don> I am seeing uucp xfers @ 300cps and news as low as 20cps.
This gets asked often enough that maybe we should have it in a regular
posting somewhere. Let's see how well I remember:
1. Your duart can have a dramatic impact on your throughput. Lots of
potential problems with 8250s. I used to regularly get 700cps
with my 16450s. Now that I've replaced them with 16550As my
average runs about 850cps with frequent excursions to 1300cps. If
you're using a smart card of some sort, check your installation
and, especially, your interrupt assignments.
2. Your serial driver can also have a dramatic impact on throughput.
There have been several reported problems with the serial drivers
put out by the various V/386 vendors. I imagine yours is fixed,
but its worth checking with the vendor.
3. Make sure that you are using hardware flow control (RTS/CTS). I
prefer to also lock my modem-serialport interface at 19200 and let
the flow control work with the modem to deal with calls at lesser
speeds.
4. Make sure that you have compression turned off. You don't want to
be compressing already compressed news batches.
Don> The system I am using is a 16MHz, Acer 386 running SCO Unix 3.2.0 . I
I'm running Microport Unix V/386 on a 20mhz 386 no-name clone. I'm
also running a T2500, so some of my references to registers may not
make sense. I've found, though, that all of the articles about
'blazers have been applicable to my problems.
Don> I have the following entries in the Systems and Devices file :
Don> Systems -> uunet Any ACU 19200 9-7038765055u ogin: ...
Don> Devices -> ACU tty2a - 300-19200 dialTBIT \T
My files, with thanks to eric@snark.uu.net (Eric S. Raymond) and a
posting he made on this subject about a year ago, are as follows.
My Devices file:
#
# --- Telebit Trailblazer/T1000/T2000 devices ------
#
# Devices for access to a 'blazer on tty01
ACUTB tty01 - 19200 tbPEP
ACUTBC tty01 - 19200 tbPEPc
ACUTBAUTO tty01 - 19200 tbauto
ACUTB2400 tty01 - 19200 tb2400
ACUTB2400N tty01 - 19200 tb2400n
ACUTB1200 tty01 - 19200 tb1200
My Dialers file:
##########
# Telebit Trailblazer Plus, T1000 or T2000
#
# assumes Q6 X1 S51=4 S52=2 S53=3 S54=3 S55=3 S58=2 S66=1 S92=1 S95=2 in EEPROM
#
# The magic parts of these scripts are the delays after connection, which hold
# off handing control to uucico so it won't time out during the PEP negotiation.
#
tb1200 =W-, "" \d\K\dATE0 OK ATS92=0S50=2S95=0DT,\T CONNECT\s1200
tb2400 =W-, "" \d\K\dATE0 OK ATS92=0S50=3S95=0DT,\T CONNECT\s2400
tb2400n =W-, "" \d\K\dATE0 OK ATS92=0S50=3DT,\T CONNECT\s2400
tbauto =W-, "" \d\K\dATE0 OK ATS92=0S50=0S95=0DT,\T CONNECT\s
tbPEP =W-, "" \d\K\dATE0 OK ATS92=0S95=0S50=255S7=60S111=30DT,\T\r\n\d\d\d\d\d\d\d\d\c CONNECT\sFAST
tbPEPc =W-, "" \d\K\dATE0 OK ATS92=0S95=0S50=255S7=60S110=1S111=30DT,\T\r\n\d\d\d\d\d\d\d\d\c CONNECT\sFAST
#
My Systems file:
ncr-sd Any ACUTB 19200 nnnnnnn "" \r ogin:-\r-ogin:-\r-ogin: . . .
donner Any ACUTBAUTO 19200 nnnnnnn "" \r ogin:-\r-ogin:-\r-ogin: . . .
serene Any ACUTBC 19200 nnnnnnn ogin:-\K\r-ogin:-\K\r-ogin: . . .
uunet Any ACUTBC 19200 nnnnnnnnnnn ogin:-\r-ogin:-\r-ogin: . . .
killer Any ACUTB2400 19200 nnnnnnnnnnn ogin:-\r-ogin:-\r-ogin: . . .
Finally, my register settings, where interesting, are:
S50=000 Auto Speed Determination & Sequence.
S51:005 Interface at up to 19200
S52:002 DTR controls AutoAnswer and Causes RESET
S58:002 RTS flow control in full duplex.
S66:001 Lock Interface Speed.
S67=000 CTS on when Modem ready.
S68:002 Use CTS flow control in full Duplex.
S92=000 Answering Sequence. PEP,V22,212A,103
S96=001 MNP Compression enabled.
S110:000 PEP Compression disabled.
S111=255 Use protocol specified by remote.
S130:003 DSR on for commands or data.
S131:001 DCD on when carrier detected.
Don> a connection with uunet at 9600bps ?
Set s50=255 as is done above for the tbPEP and tbPEPc devices.
Don> PS : is {ames,sun,uunet}!telebit!modems alive ?
Yup, I received a reply sent to that address about a week ago.
***************************************************************************
*Rock Kent rock@rancho.uucp POB 8964, Rancho Sante Fe, CA. 92067*
***************************************************************************bret@codonics.COM (Bret Orsburn) (02/23/90)
In article <1990Feb17.063412.18455@rancho.uucp> rock@rancho.uucp (Rock Kent) writes: > >4. Make sure that you have compression turned off. You don't want to > be compressing already compressed news batches. > OK, I'll bite: Why not? Surely, compression will be less effective the second time, but is there any good reason to disable it? Do you have any data to demonstrate that throughput is *decreased* by enabling compression for a compressed newsfeed? -- ------------------- bret@codonics.com uunet!codonics!bret Bret Orsburn
kls@ditka.UUCP (Karl Swartz) (02/24/90)
In article <959@codonics.COM> bret@codonics.COM (Bret Orsburn) writes: >In article <1990Feb17.063412.18455@rancho.uucp> rock@rancho.uucp (Rock Kent) writes: >>4. Make sure that you have compression turned off. You don't want to >> be compressing already compressed news batches. >OK, I'll bite: Why not? >Surely, compression will be less effective the second time, but is there >any good reason to disable it? Do you have any data to demonstrate that >throughput is *decreased* by enabling compression for a compressed newsfeed? Compressing random binary data will often make a file larger since there are no patterns for the compression algorithm to eliminate, and assuming the algorithm does a good job (which it does) a file that has already been compressed will almost certainly grow since they now have the overhead of the compression tables in addition to the uncompressible data. Compress is smart enough to recognize that it's efforts were wasted and refrains from replacing the original with a larger compressed file, but this only works if it has control over input and output files. Obviously this doesn't apply for a pipeline, which is in essence what's being done in a Telebit, all it can do is emit the larger stream of bytes. Since you wanted hard data, I made up a batch consisting of the usual "#! cunbatch" header and a compressed (16 bit) copy of the first Northern California file from comp.mail.maps (u.usa.ca.2). I then compressed the file using both 12 and 16 bit compression (I believe the Telebits use 12 bit compression) with results as follows: file bytes compression time @800CPS original 35755 n.a. 44.7 compress -b12 49206 -37.61% 1:01.5 compress -b16 47053 -31.59% 58.8 Doesn't look like I'll be running off to enable compression on my TrailBlazer soon.
bret@codonics.COM (Bret Orsburn) (02/24/90)
In article <21377@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: >In article <959@codonics.COM> bret@codonics.COM (Bret Orsburn) writes: >>In article <1990Feb17.063412.18455@rancho.uucp> rock@rancho.uucp (Rock Kent) writes: >>>4. Make sure that you have compression turned off. You don't want to >>> be compressing already compressed news batches. > >>Surely, compression will be less effective the second time, but is there >>any good reason to disable it? > >Compressing random binary data will often make a file larger since >there are no patterns for the compression algorithm to eliminate, >and assuming the algorithm does a good job (which it does) a file >that has already been compressed will almost certainly grow since >they now have the overhead of the compression tables in addition >to the uncompressible data. Makes sense to me. I wasn't aware that the two compression algorithms (a) are very similar (b) are nearly optimal (c) have significant overhead [tables]. I will take your word that such is the case. It would not be necessary to transmit a table if the class of data to be compressed was agreed upon in advance by both parties. That would seem to be a sound and sensible policy for a news feed, though not for a modem. The only remaining question is: Why does the little bit of documentation available on this subject incorrectly recommend using compression? (That is a rhetorical question. ;-) Thanks to all who responded. (I thank you, my phone bill thanks you, the man who pays my phone bill thanks you,....) -- ------------------- bret@codonics.com uunet!codonics!bret Bret Orsburn