From: ziegast@uunet.uu.net (Eric Ziegast)
Subject: Re: Compuserve 9600 baud modems
Reply-To: uucp-request@uunet.uu.net
Organization: UUNET Technologies - Falls Church, VA
Date: Fri, 4 Sep 1992 14:08:40 GMT

|> 	I suspect, that along with the number changes, thay have changed
|> 	there settings for 9600 baud modems, as a result, our telebit 
|> 	modem T1600 does not communicate with their modem.
|> 
|> 	I would like to know if someone has the settings for CompuServes
|> 	Hayes compatible 9600 baud modem settings or settings for T1600
|> 	which communicates with CompuServe.

I called CIS and they were not aware of any problems or changes with the
line.   While I was on hold, I tried calling with my T2500...

	ats50=6s111=0dt9,17136505143
	RRING
	
	CONNECT 9600/LAPM
	
	...etc...  (you know what I don't put here)

	UUNET Communications Services (uunet)
	
	login: 

The person on the other end said they had USR96e modems installed on that
line (pretty generic V.32 modem).

Make sure you have set:

	S50=6	Use V.32
	S94=0	Don't allow fallback to lower speeds
	S111=0	Turn off spoofing

Also make sure you're using an interface speed (see S51) of 9600bps or
higher (preferrably 19200).  If the two modems are talking 9600 and your
computer is talking to the modem at 1200 or 2400, you're going to have
problems.

If all else fails, call 1-800-TELEBIT.



While we're talking Compuserve, let's talk throughput.  Alot of people who
use the 9600 Conmuserve numbers have seen lousy throughput, like 350 to 500
cps.  Some time ago, a modem witch-doctor told me...

> If you want to copy the action of the efficient Compuserve B+ protocol,
> you'd have to send 2048 bytes before pausing for an ack.  That adds up
> to 4 512-byte packets.  7 256-byte packets are in that gray area where
> it "ought to" work.  That sends 1792 data bytes (1834 bytes including
> the packet header overhead) before pausing - probably enough to keep
> the protocol efficient.  At the very least, it will make the protocol
> much more efficient than the standard parameters.

One of our subscribers was using a V.32/V.42/V.42bis connection at g(64,3)
(that is, a packet segment size of 64 and a window size of 3) and seeing
lousy throughput.  I asked him to try g(256,7) to g(1024,7).  He says that
g(512,7) worked best.  Here are his stats for file transfers 8K and over
for the past few days...

	 Date-Time    (Sent+Recv)      Amount           Time        Avg Rate
	---------------------------------------------------------------------
	08/28-22:09   (   6+    )     1154247 bytes  1251.61 sec    922 cps
	08/29-05:07   (   4+    )      506719 bytes   531.55 sec    953 cps
	08/29-11:03   (   3+    )      185686 bytes   198.88 sec    933 cps
	08/29-14:17   (   1+    )       97965 bytes   105.70 sec    926 cps
	08/29-17:03   (   2+    )      153502 bytes   163.84 sec    936 cps
	08/30-00:19   (   1+    )     1045712 bytes  1107.31 sec    944 cps
	08/30-00:42   (   1+    )     1045712 bytes  1142.82 sec    915 cps
	08/30-16:54   (   1+    )       18220 bytes    17.88 sec   1019 cps
	08/30-18:07   (   2+    )      271854 bytes   346.72 sec    784 cps
	08/30-18:51   (   1+    )       42454 bytes    58.04 sec    731 cps
	08/30-21:28   (   3+    )      443635 bytes   486.98 sec    910 cps
	08/31-01:20   (   3+    )      407653 bytes   432.76 sec    941 cps
	08/31-05:02   (  15+    )      656011 bytes   696.09 sec    942 cps
	08/31-11:03   (   1+    )       19410 bytes    26.44 sec    734 cps
	08/31-23:06   (   7+    )     1301900 bytes  1385.17 sec    939 cps
	09/01-05:07   (   6+    )      817513 bytes   878.01 sec    931 cps
	09/01-23:07   (   8+    )     1678814 bytes  1830.68 sec    917 cps
	09/02-05:06   (   5+    )      546887 bytes   673.86 sec    811 cps
	09/02-23:05   (   8+    )     1439804 bytes  1509.72 sec    953 cps
	09/03-05:06   (   4+    )      541214 bytes   605.74 sec    893 cps
	09/03-23:06   (   8+    )     1557084 bytes  1648.31 sec    944 cps
	09/04-05:10   (   5+    )      748093 bytes   795.35 sec    940 cps
	Total:        (  95+    )    14680089 bytes 15893.46 sec    923 cps


	 Date-Time    (Sent+Recv)      Amount           Time        Avg Rate
	---------------------------------------------------------------------
	08/30-21:19   (    +   1)      120391 bytes   298.34 sec    403 cps
	09/02-05:03   (    +   1)       10844 bytes    21.57 sec    502 cps
	09/03-11:06   (    +   1)      121327 bytes   268.65 sec    451 cps
	09/04-05:05   (    +   1)       26524 bytes    53.36 sec    497 cps
	Total:        (    +   4)      279086 bytes   641.92 sec    434 cps

I don't know about the receive rate, but the sent rate looks awfully nice
(especially since he downloads lot's of news from us).  It probably could
be a little bit better though; I just realized I was still using level 7
debugging on his line.  (Just turned it off.)

So, if you use Compuserve's 9600 connection and receive alot of files from
uunet,
	- Try a higher packet segment and window sizes (like 512 and 7).
	- Turn on V.42 and V.42bis if you want.  Don't use MNP.
	- AND send mail to uunet!postmaster asking us to change the packet
	  settings on our end to match yours.

If your UUCP does not support larger packet sizes, consider using a newer
UUCP implementation (like Taylor's).

Disclaimer: You milage will vary. ;^)
--
Eric Ziegast
Xref: sparky houston.general:944 tx.general:640 tx.politics:4511