bob@ns.UUCP (Bob Mathias) (02/25/91)
I have noticed that with my new USR DS modem, that HST mode seems to outperform v.32bis when doing file transfers using YMODEM-G on a PC-based BBS. I run both with v.42 and v.42bis is disabled. The speed difference is about 30cps. I'm not really concerned about this speed differential since it is not that great and I'd rather use a non-proprietary protocol. I am just curious as to why this might be. I have come up with some scenarios: 1) USR has done HST for years, thus they have fully optimize this protocol while v.32bis is new and thus not optimized. 2) HST might have an inherent advantage when doing a one-way type file transfer that depends upon the error correction protocol. 3) Operator error (mine!). I don't think this is the case, but one never does! I've looked at the ati 6 screen after each connection, and this indicates that I am running in the modes I requested. (The basic difference I do between running the two protocols is changed the Bx parameter: B0 = v.32bis and B1 = HST. And yes, the BBS I am connecting to is another USR DS (w/ v.32bis). Anyone else with an explanation? -- Bob Mathias uucp: ...!uunet!ccicpg!uis-oc!ns.UUCP!bob Unisys Corporation CServ: 70340,165 A and V Series Systems Engineering voice: (714) 727-0323 Irvine, California
tnixon@hayes.uucp (02/26/91)
In article <139@ns.UUCP>, bob@ns.UUCP (Bob Mathias) writes: > I have noticed that with my new USR DS modem, that HST mode seems to > outperform v.32bis when doing file transfers using YMODEM-G on a PC-based > BBS. I run both with v.42 and v.42bis is disabled. The speed difference > is about 30cps. > > I'm not really concerned about this speed differential since it is not that > great and I'd rather use a non-proprietary protocol. I am just curious as > to why this might be. There should be NO difference, if you're using MNP4 in both HST and V.32bis mode. Normally, the reason people see a difference in performance is because the maxmimum frame size in MNP4 is 256 bytes, and the _default_ maximum frame size in V.42 LAPM is 128 bytes. The LAPM default can be negotiated higher, but the HST doesn't because of memory limitations. The resulting smaller frame size increases protocol overhead and causes throughput to be about 2% less. I can't think of any other reason why asymmetrical modulation would provide higher throughput than V.32bis, except, as you note, perhaps some difference in USR's implementation that unnecessarily cripples their V.32bis (although fortunately not by much). -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
bob@ns.UUCP (Bob Mathias) (03/05/91)
In article <3811.27ca371e@hayes.uucp> tnixon@hayes.uucp writes: >There should be NO difference, if you're using MNP4 in both HST and >V.32bis mode. Normally, the reason people see a difference in >performance is because the maxmimum frame size in MNP4 is 256 bytes, >and the _default_ maximum frame size in V.42 LAPM is 128 bytes. The >LAPM default can be negotiated higher, but the HST doesn't because >of memory limitations. The resulting smaller frame size increases >protocol overhead and causes throughput to be about 2% less. I >can't think of any other reason why asymmetrical modulation would >provide higher throughput than V.32bis, except, as you note, perhaps >some difference in USR's implementation that unnecessarily cripples >their V.32bis (although fortunately not by much). I was using V.42 LAPM during my performance tests for both protocols (V32.bis and HST). I wasn't aware of the difference in frame size between V.42 LAPM & MNP4 so I decided to do the tests using MNP4 instead. This improved my performance for both protocols. I now get 1732 cps for HST and 1723 for V32.bis (less than a 1/2 % difference). MNP4 improved by HST performance by about 17 cps and my V32.bis by about 42 cps. Since I'm seeing such a difference, is there any why I shouldn't disable LAPM and use MNP4. What are the benefits of LAPM over MNP4? -- Bob Mathias uucp: ...!uunet!ccicpg!uis-oc!ns.UUCP!bob Unisys Corporation CServ: 70340,165 A and V Series Systems Engineering voice: (714) 727-0323 Irvine, California
tnixon@hayes.uucp (03/11/91)
In article <141@ns.UUCP>, bob@ns.UUCP (Bob Mathias) writes: > Since I'm seeing such a difference, is there any why I shouldn't > disable LAPM and use MNP4. What are the benefits of LAPM over MNP4? LAPM has superior error detection and recovery mechanisms, including (optional) 32-bit FCS and Selective Reject, separate REJ, RR, and RNR frames to avoid protocol confusion, etc. The smaller default frame size also allows you to recover from errors faster, at the expense of a couple of percent throughput on clean lines. Admittedly, these benefits are ALL meaningless if you have a perfectly clean line, but if we all had perfect lines we wouldn't need error control at all (except for the fact that we can improve throughput by stripping start and stop bits and implementing data compression). I'm quite certain that the differences you're seeing in the HST are directly related to their implementation, and are not inherent in the protocol itself. But if that's what you're seeing, you might as well go with what works best. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
wallach@motcid.UUCP (Cliff H. Wallach) (03/12/91)
In article <141@ns.UUCP> bob@ns.UUCP (Bob Mathias) writes:
-
-I was using V.42 LAPM during my performance tests for both protocols
-(V32.bis and HST). I wasn't aware of the difference in frame size
-between V.42 LAPM & MNP4 so I decided to do the tests using MNP4 instead.
-This improved my performance for both protocols. I now get 1732 cps
-for HST and 1723 for V32.bis (less than a 1/2 % difference).
-
In HST mode an extended form of MNP3 is active. In addition to
extensions for line reversals are some protocol enhancements that
were intended to reduce the round trip delay of the backchannel.
These enhancements were designed before MNP4 was released.
The standard MNP3 data frame is formatted as:
1 open flag byte
7 header bytes
64 data bytes
2 crc bytes
HST mode reduced the header to 2 bytes.
Level 4 provided 2 independent modifications to the MNP protocol. The
header size was reduced to 3 bytes, and the frame size was increased
to 256. HST mode retained the original streamlined header, but used
the increased frame size.
The different overhead size (5 vs 6) results in a throughput
improvement of about 0.4%. Another 0.15% improvement results because
every 2 seconds MNP must send an ack frame, while HST mode has a
combined data/ack frame. Also remember about measurement and roundoff
errors.
When V42bis and HST modulation is negotiated, then the BTLZ data
compression is run with HST mode protocol.
Cliff Wallach ...uunet!motcid!wallachwallach@motcid.UUCP (Cliff H. Wallach) (03/12/91)
In article <4695@cocoa61.UUCP> wallach@motcid.UUCP (Cliff H. Wallach) writes: - -The standard MNP3 data frame is formatted as: - 1 open flag byte - 7 header bytes oops! that should be 5 header bytes formatted as ------------------------------------ | len | type | par1 | len1 | seq# | ------------------------------------ Cliff Wallach ...uunet!motcid!wallach