chet@arc.UUCP (Chet Wood) (01/16/90)
I recently purchased a Micom model "M3124EH type s1" modem, a 2400
baud number which supposedly supports MNP4. I get lower throughput
connecting in RELIABLE mode than in normal mode, as reported by kermit
when connecting to a Trailblazer Plus on a Sun, or connecting to an
Everex 2400 baud MNP5 modem on another mac.
To their credit, Micom sent me another modem to try by Federal Express
(pretty good service for a $129 modem ). The head of technical support
says that MNP4 "should" be faster than normal mode, but I got the
feeling that neither he nor the repair tech he asked actually knew
from experience that their modems work this way.
The new modem he sent has the same problem-- here are the effective
baud rate numbers I get when connected to the everex running the
latest version of Mac Kermit, 900 byte packets, a 10KB compressed file
in binary mode:
non-MNP 1653
reliable 1550
By the way, i have used the everex and telebit together in the past
and realized a very significant speed improvement in MNP5 mode.
I would not expect MNP4 to be as fast as MNP5, but then, with a
compressed file, maybe it should be?
Any thoughts on what's happening?
Thanks...
Chet.
--
Chet Wood ~ (408)727-3357
arc!chet@apple.COM . Advansoft Research Corporation
chet@arc.UUCP . 4301 Great America Parkway
apple!arc!chet . Santa Clara, CA 95054, USArvdp@cs.vu.nl (Ronald vd Pol) (01/16/90)
In article <CHET.90Jan15111149@sparcy.arc.UUCP>, chet@arc.UUCP (Chet Wood) writes: > The new modem he sent has the same problem-- here are the effective > baud rate numbers I get when connected to the everex running the > latest version of Mac Kermit, 900 byte packets, a 10KB compressed file > in binary mode: > > non-MNP 1653 > reliable 1550 > As far as I know MNP 4 offers an efficiency of at most 120%, MNP 5 offers an efficiency of at most 200%. Both offer a 100% reliable connection. (So with MNP modems you don't need Kermit, just cat the file). If you already have a compressed file, the compression techniques of MNP won't help much (on the contrary, as you have shown!). Try sending a file with all the same characters in it, you should get a throughput of approximately 1.2*2400=2880 bps. (Of course your computer should be connected to the modem at a speed of 4800 bps or more). BTW I am still looking for a description of the MNP 5 protocol. If anyone knows where I can get it, please followup, reply, shout, give smoke signals, ... -- -------------------------------------------------------------------------- Ronald van der Pol <rvdp@cs.vu.nl> These are the days of miracle and wonder, this is a long distance call....
news@bbn.COM (News system owner ID) (01/16/90)
chet@arc.UUCP (Chet Wood) writes:
< The new modem he sent has the same problem-- here are the effective
< baud rate numbers I get when connected to the everex running the
< latest version of Mac Kermit, 900 byte packets, a 10KB compressed file
< in binary mode:
This is a good setup in general for MacKermit. Get a copy of 0.98
from watsun.cc.columbia.edu if you havn't yet (in the kermit/test
directory, but it's more stable than 0.9 and _much_ more stable than
0.97).
< non-MNP 1653
< reliable 1550
As I recall, MNP-4 is sync over the phone-wire, with longer MNP
packets and a slightly smarter when-to-transmit heuristic. All other
things being equal, this _should_ give you faster data transmision...
However, trying to layer a non-windowing packet based protocol on top
of this is probably causing havoc with MNP -- the underlying packet
protocol (MNP) may be delaying the transmition of the final parts of
the upper protocol (Kermit) packets. In other words, you are seeing
latency between packets. The best thing to avoid this for the moment
is to use big packets, which you are allready doing...
Latency wouldn't be much of a problem if you were running something
real (TCP on IP on PPP) or quazi-real (TCP on IP on SLIP or Zmodem),
but you need not to be running through anything wierd to make the
quazi-real things work right. It's a trade-off: Kermit works right
almost all the time without twiddling it, and is very resistant to bad
conditions. Zmodem works faster, but only on computer -> modem ->
modem -> computer connections, and you may have to dink with flow
control to make it work right. Your choice...
Making Kermit better behaved for this (read: adding the sliding
windows protocol extention) is currently at the top of my To Do list,
but that won't happen real soon (looks like about 3 months until the
first beta-test versions, but no promises).
-- Paul Placeway <pplaceway@bbn.com>
MacKermit Coordinator/Programmerwb8foz@mthvax.cs.miami.edu (David Lesher) (01/16/90)
(Not to say this applies in this case)
One thing to watch out for:
How do you know what level {2,3,4,5,6,999} MNP
connection you have running?
Most of the modem give only a CONNECT 2400 MNP or similar
message. Nary a word of the level. And that does make a
difference.
--
A host is a host & from coast to coast...wb8foz@mthvax.cs.miami.edu
no one will talk to a host that's close..............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335casey@gauss.llnl.gov (Casey Leedom) (01/16/90)
| From: rvdp@cs.vu.nl (Ronald vd Pol) | | Both [MNP4 and MNP5] offer a 100% reliable connection. (So with MNP | modems you don't need Kermit, just cat the file). This is only true if flow control is working at every link point (i.e. remote computer/modem and local computer/modem.) For instance, our T2500 modem pool is hooked up to a Vax running 4.3BSD via older Able DMZ32s (DMF emulators). Right now we're screwed because 4.3BSD doesn't do hardware flow control and neither do the DMZ32s. I'm working on the software problem and need to call Able again and bug them about an upgrade to the DMZs which gives me RTS/CTS ... (For obvious reasons in band XON/XOFF is out of the question.) Thus, even with a reliable link between the two modems, you may still need to use a reliable end-to-end file transfer protocol because the link between the two modems isn't the only link in the data transfer path. I'll also mention the ongoing argument between ISO and TCP/IP networking types: ISO type tend to feel that if you have a data communications path where every link is reliable, then you don't need an end-to-end reliable protocol. TCP/IP types have always predicated their protocols on the fundamental assumption that the individual links in the communication paths are definitely *NOT* reliable and so have always designed end-to-end reliable protocols. But more, TCP/IP types tend to feel that it is the height of folly to depend on every communication link in a data path performing reliably, thus they tend to continue to advocate end-to-end reliable protocols. Unfortunately (in my view) many TCP/IP types then turn the above implication around (logically incorrectly) and infer that reliable links are in themselves not good. (i.e. They take A -> B and then say B -> A which is incorrect. The inverse is really ~B -> ~A. In this case A == ``reliable links aren't'' and B == ``thus we need reliable end-to-end protocols''.) In any case, this has strayed totally from the original point. I now return you to your regular programming ... Casey
rvdp@cs.vu.nl (Ronald vd Pol) (01/16/90)
In article <44596@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: > Thus, even with a reliable link between the two modems, you may still > need to use a reliable end-to-end file transfer protocol because the link > between the two modems isn't the only link in the data transfer path. > You're completely right (of course 8-). It is amusing to think about the way this message comes to you: my home, terminal, modem, telephone line, modem, port selector (computer centre), ethernet, telephone line, ethernet (university), host computer, ethernet, telephone line, ethernet (computer centre), satellite link, Internet, .... -- -------------------------------------------------------------------------- Ronald van der Pol <rvdp@cs.vu.nl> These are the days of miracle and wonder, this is a long distance call....
wtm@neoucom.UUCP (Bill Mayhew) (01/17/90)
I use an AT&T CEO 2224 MNP modem (level 4) in my office to tallk to a Trailblazer Plus on our vax and a TB Plus on my 3B1 at home. It has been discussed here that the TB Plus 4.0 firmware is not fully MNP 4 compliant, so this could affect my results. I have noticed that when I cat a file to the screen of the terminal in my office that characters arrive at what seems to be a normal 2400 baud rate, followed by about a 1 second pause, then a steady issue of characters follows at 2400 baud or perhaps slightly faster. The effect is not limited to the CEO 2224 modem. I also see the pause behavior when using the software based MNP that is available for use with Softklone's Mirror III package that I use on my protable computer. There are no explanations of MNP levels, etc in the Trailblazer or the Softklone manuals and only a few small teases in the AT&T manual. One of the things that can be set in the AT&T manual is an S register to select MNP packet size, though in pactice setting different size packets hasn't been either beneficial or damaging for me; the pause always seems to be the same, and seemingly is not some soft of flow control mechanism -- it only happens once at the beginning of catting a file. I don't see the behavior when I disable MNP, so the pause is some sort of MNP artifact. In both cases, the trailblazer is talking to the host at 19200 with flow control on that end, and the CEO 2224 is talking to the terminal at 4800. On the portable, the only choice of modem interface is 2400 due to a limitation of the modem. Bill
roe@sobmips.UUCP (r.peterson) (01/18/90)
From article <5110@loper.cs.vu.nl>, by rvdp@cs.vu.nl (Ronald vd Pol): > As far as I know MNP 4 offers an efficiency of at most 120%, MNP 5 offers > an efficiency of at most 200%. Both offer a 100% reliable connection. > (So with MNP modems you don't need Kermit, just cat the file). Except that MNP modems don't necessarily guarantee flow control, whereas kermit (and x-y-zmodem, uucp, etc.etc.) do. Even spoofing kermit protocol, a telebit will still eventually wait for the sender to ack (or nak) a packet. -- One makes strong assumptions delving Roe Peterson into the beginning of the universe... {uunet,mcgill-vision}!sobeco!roe - Stephen Hawking, Cambridge