Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!celit!billd
From: billd@fps.com (Bill Davidson)
Newsgroups: comp.dcom.modems
Subject: Re: Help: Why MNP5?
Message-ID: <15126@celit.fps.com>
Date: 27 Jan 91 21:44:07 GMT
References: <1991Jan18.194613.13435@watserv1.waterloo.edu> <0cD8V3w163w@ozonebbs.UUCP> <1991Jan27.160653.7104@nstar.rn.com>
Organization: FPS Computing Inc., San Diego CA
Lines: 26

In article <1991Jan27.160653.7104@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes:
>Sorry - but incorrect with MNP5.  MNP5 over a 2400 baud connection
>if properly installed will produce transfer rates of 280 cps even
>sending GIFs and ZIPs

I find this *VERY* difficult to believe.  GIF's are already LZW
compressed and so in general cannot be further compressed by *ANY* one
dimmensional digital compression method I am aware of without data
loss.  If the MNP modems are really running a 2400 baud link, 280cps
seems impossible.  The theoretical max for 2400 baud is something like
266cps (8 data + 1 stop) and anything higher would require compression
and as I said, I don't believe you can compress a GIF => 280cps
impossible.  My theory tends to agree with my experience with MNP
modems as well; in fact they tend to do only slightly better for me
than normal old Hayes 2400's on ascii transfers.  The protocol does
seem to adversly affect turnaround time during interactive work for
some strange reason (my guess is it's due to sampling for
compression).  Also, when one MNP modem connects to another MNP modem
and one has MNP turned on and the other has it off, it's been my
experience that you get only garbage.  Both can talk to non-MNP modems
fine.  They can only talk to each other if they both have MNP off or
both on (this experience has been with Microcom's; the inventors of
MNP).  The only thing good I have to say about MNP is that it does tend
to allow less line noise through.

--Bill Davidson