🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: cle.config
Article #77

Re: Configuring Waffle for higher throughput with Boca 14.4

#77
From: Robert Henney
Date: Fri, 24 Sep 1993 05:51
68 lines
4166 bytes
>Date: Thu, 23 Sep 93 23:48 EDT
>From: anton@uunorth.north.net (Anton J Aylward)
>
>In article <8e940B5w165w@linear.mv.com> you posted to comp.mail.uucp:
>
>: One thing I wouldn't mind knowing is why on other systems when I connect
>: at 14.4k/V.42BIS/LAP-M, file transfers of precompressed (ie.ZIP) go at
>: around 1700cps, yet the same connection (14.4k/V.42BIS/LAP-M) using
>: UUCICO.EXE results in an average of 600cps.  Error correction is not
>: having any (or very little) effect on tranfers under a normal terminal
>: program.  Why should they be so greatly affected under UUCICO.EXE.
>
>	Think about what you're saying.
>	You have a 14k4 modem
>	You are sending a precompressed file.
>	You are getting more than 14k4 bps throughput.
>
>	Do you see the disparity?

On most systems, I get 1600-1800cps when transfering precompressed
(usually ZIPed) files.  My modem is connecting at 14.4k with v.42BIS
compression and LAP-M error correction enabled.  With compression
on, I have noticed even precompressed files will gain by a good
percentage in cps with v.42BIS on.  The only reason I can guess at
why some people lose cps with compression enabled durring transfer
of precompressed files is that their v.42BIS implementation is not
of high quality, like found in some cheap modems.  The strange thing
is that my modem IS cheap... a lame Viva14.4k.

>	Either the file isn't compressed or the way your throughput is
>	being calculated is wrong.

No, the files I send are compressed either with ARJ, PKZIP, OR LZH.
Every term program I have used states the same...  somewhere between
1600 and 1800 cps.  Since I started using FX_UUCICO I am getting
around 1550 avarage.  This lower cps is due to the fact that I'm using
the g proto at 64 byte blocks and alot of overhead is dropping the cps.

>	I suggest you try the same test with and without v42bis,
>	and with and without compression on the same file, a little 2x2
>	matrix.

On uncompressed files the cps is much higher, as v.42BIS can find alot
more places where to apply compaction.  Without v.42BIS, the cps with
precompressed files is much much lower, as *I* would expect.  I am no
expert, but I do recall hearing that v.42BIS (in full-implementations)
uses compression technieks that can't be applied from on-system
compressors by using somethings of the modem hardware when transmitting.
Don't ask me to elaborate as I am not expert.  It would be nice if
someone knowledgeable in v.42BIS would speak up now though.

>	You also didn't say of the file transmitted at high speed was
>	reveived correctly ;-)

Heh, of course they are received correctly.  My transfers (even long
ones) normally run with 0 errors detected by the protocal.  Errors
corrected by LAP-M I can't detect, but considering the high cps I would
doubt many exist.  And the files?  Yes, they CRC correct and are
received in perfect condition every time.

>--
>Anton J Aylward		| "The body politic is swerving from left to
>anton@uunorth.north.net	| right and right to left looking for quick
>			| fixes for systemic problems." - Paul Palango,
>			|             Journalist, ex The Globe and Mail

--
|  Robert Henney  (NHTI)  Concord, NH   EMAIL:linear@linear.mv.com  |
Technical Details
Message-ID: <640cac4w165w@linear.mv.com>
Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!spool.mu.edu!bloom-beacon.mit.edu!world!mv!linear

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10beba,1ea7d3ccca03afff
X-Google-Attributes: gid10beba,public
X-Google-Thread: 10d370,1ea7d3ccca03afff
X-Google-Attributes: gid10d370,public
X-Google-Thread: 103394,1ea7d3ccca03afff
X-Google-Attributes: gid103394,public
X-Google-Thread: 10d3b3,1ea7d3ccca03afff
X-Google-Attributes: gid10d3b3,public
X-Google-ArrivalTime: 1993-09-24 02:30:02 PST
Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!spool.mu.edu!bloom-beacon.mit.edu!world!mv!linear
From: linear@linear.mv.com (Robert Henney)
Newsgroups: cle.config,comp.bbs.waffle,comp.mail.uucp,comp.dcom.modems
Subject: Re: Configuring Waffle for higher throughput with Boca 14.4
Message-ID: <640cac4w165w@linear.mv.com>
Date: Fri, 24 Sep 93 01:51:16 EDT
Organization: New Hampshire Technical Institute -- Student Operated System
Lines: 68