Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a780
From: Mike_Benna@mindlink.UUCP (Mike Benna)
Newsgroups: comp.dcom.modems
Subject: Re: Modem info for PC users
Message-ID: <4739@mindlink.UUCP>
Date: 8 Feb 91 22:22:33 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 84

In article <3767.27ad95b3@hayes.uucp>, tnixon@hayes.uucp (Toby Nixon)
writes:
> Mike Benna writes:
>> Your argument may be technically correct however in a situation such as
>> this there is no substitute for actual testing.  I've since gone and
>> captured a whole bunch of 'typical' BBS menus (again) and done some
>> testing on how well they compress.  The results: MNP5: 638cps, V.42bis:
>> 813cps.  It seems I was out a little bit in the first place but not in
>> the direction you thought I was.
>
> It seems from your comment that you're using a file compression
> program rather than actual modem implementations.  Is that true?
> I'm very interested in your actual testing method, particularly
> since it would seem to be difficult to get an "average" compression
> ratio for BBS menus while actually logged on.

My test procedure:

1) Call a local BBS with my capture buffer open.
2) Go through almost all of the menus on the system.
3) Log off.
4) Edit my capture buffer to remove all the stuff in between the menus,
   leaving only the menus themselves.
5) Remove any duplicate menus.
6) Transfer the resulting file (52K) from one machine to another using
   MNP5 compression and V.42bis compression at 2400bps.
7) Multiply the results by (240/238) to compensate for Z-modem overhead.

Potential problems in my method:

1) ANSI codes are not recorded by my term program.  This could change
the results either way depending on the repetitiveness of the codes.
Typically codes are similar for an entire menu (e.g. the color setting
codes will be repeated several times).

2) When calling a BBS you will often go through the same menu several
times.  Depending on how long the compression algorythm 'remembers'
things, this can improve throughput even more.

3) I am only testing the compression capabilities of one modem.  Some
modems may be more efficient, others may be less.  The modem in question
(the sending modem) is a USR Courier V.32.

Also, I'll try to anticipate your next question:  Here's a typical
sample of the BBS menus I used in the test.  Note that I've converted
the IBM graphics characters to regular ASCII characters to avoid any 8th
bit problems on the net.

+---------------------------------------------------------------------- -+
| A Local Vanouver BBS                MAIN MENU |
+---------------------------------------------------------------------- -+
| <C>-CHAT MODE                       <E>-Exit System |
| <B>-Bulletins Section               <F>-File Transfer Areas |
| <M>-Message Base Areas              <O>-Online Callers |
| <P>-Page the SysOp                  <R>-Recent Callers to System |
| <S>-System Configuration            <V>-Voting Booth Area |
| <#>-System and User Statistics      <!>-Special Conference Topics |
| <D>-Database Area                   <*>-Menu Help File |
+---------------------------------------------------------------------- -+

Note that there is a large amount of white space and other repeated
characters sequences.

>> In a quick survey of the BBSes around Vancouver I've found that the
>> ratio of HST to V.32 support is about 4:1 and _all_ of the ones with
>> V.32 also have HST.  In fact the multi-line BBSes which support both
>> usually have a ratio of 2 HST lines for every V.32 line.
>
> I think the actual ratio all around North America might be quite
> different from just Vancouver.  HSTs are sometimes concentrated in
> pockets, since people want to be able to communicate in high speed
> with other modems; a move to convert to V.32 usually is done
> gradually.

I've gotten several pieces of email from around North America which
would indicate that indeed Vancouver seems like a 'pocket' of HST's. In
any case things are changing here as well; there are more V.32 BBSes
popping up all the time.

        ---> Mike
--
   ---> Mike Benna, Vancouver, B.C., Canada
        MindSpan Technologies Corp - Video Game Design and Development
  UUCP: Mike_Benna@mindlink.UUCP  or  uunet!van-bc!rsoft!mindlink!Mike_Benna