Hi Bill,

 BG> > Two USR Couriers with a 33k6bps connect, probably due to
 BG> > their unique 256 byte LAPM frames and SREJ (Rockwells only
 BG> > use 128 byte LAPM frames, but similar cps rates may be
 BG> > possible with MNP4, which also uses 256 byte frames).

IS> Nope, even MNP4 won't take you past about 118% (1700 cps at
IS> 14400, 3400 at 28800, so about 3967 cps at 33600).

 BG> That still doesn't explain the 4000cps which was physically
 BG> seen here on one particular 1.5Mb file transfer between
 BG> David's Courier and mine (and which was witnessed by
 BG> Russell Brooks at the time).

Using Binkley?  With LAPM?  With what file transfer protocol?  Terminate
with ymodem-g, now I could believe it saying that .. :)

IS> No modem that complies with V.34 does anything 'unique' with frame
IS> sizes, and most modern modems will respond to a request for
IS> larger than default frames.

 BG> Dunno, when I call Rockwells, most aftecall stats show the
 BG> frame size as being 128 bytes, and only a handful indicate
 BG> 256 byte frames or SREJ, so I'm not convinced that this
 BG> applies to "most" modems just yet.

The Courier probably requests, but doesn't demand it.  I'm not quite sure
of the intricacies of the request/acknowledgement of these (optional)
parameters.
I seem to recall you could fiddle with options on some Rockwells - you
certainly can with V.42bis dictionaries etc.  Tell me, do the calls you
refer to above have compression enabled or not?  (Sometimes V.42bis will
negotiate the larger 256 byte frames, I understand).

[later .. I put this aside till I had time to look V.42 up ..]

"9.2.3  Maximum number of octets in an information field (N401)

N401 governs the maximum number of octets that can be carried in the
information field of an I frame, an XID frame, a UI frame, or a TEST frame
transmitted by an error-correcting entity.  The default value of N401 shall
be 128 octets for both directions of data transmission.  If the default is
not satisfactory to the negotiation initiator, then a different value may
be negotiated separately for each direction by use of the XID frame.  The
initiator of the negotiation shall indicate the N401 value it wishes to use
for each direction (absence of a value indicates use of the default).  The
responder to the negotiation indicates the N401 value it wishes to use for
each direction.  The value chosen by the responder shall be between the
value chosen by the initiator and the default value, inclusive, and shall
be the value used during the operation of the error-corrected connection
(unless overridden by a subsequent negotiation)."

Phew.  It's all like that .. very precise, but very verbose.  It's also all
like that, in terms of asking nicely, but being able to knock back requests
for various options, like SREJ, 32-bit FCS, etc.

IS> LAPM with 256 byte frames is still a percent or so slower than MNP4.

 BG> Is this due to 32-bit CRC checking?

That and a generally slightly shorter MNP block header, as I recall.

Even 32-bit CRC is optional, while 'customary'.  They're difficult to
compare exactly, because the header layouts are different, plus LAPM uses
zero-bit insertion for flag transparency, while MNP may use uses DLE escape
codes in "start-stop, octet oriented framing mode" or zero-bit
insertion in its "bit-oriented framing mode".  The MNP4 spec
(annex A) is as think as a brick to read, compared even to V.42 proper ..
but I'll have a go ..

.. half an hour later .. sorry, more research will be needed to make head
or tails of the possible header sizes for MNP .. there are just so many
options .. LAPM is a lot easier to follow.

If you've access to a postscript printer, and ink and paper for 74 pages,
freq V42-PS.ZIP (270K) and try figuring it out yourself :)  BTW, if you do,
make sure V.42bis is enabled, so you might tell me if we get 256-byte
frames?

IS> SREJ isn't relevant to error-free throughput.

 BG> True.

:)  Hard to quantify its effects in operation, too, by definition, but
obviously helpful with certain specific types of line impairment patterns.

IS> A 48K file will give you about a +/-8% error in recording
IS> (ie, +/-300cps!) at one second resolution, at 33600.  Even
IS> 480K is too small for really definitive throughput figures
IS> at that rate (still approx +/-30cps).  Quoting transfers of
IS> 1Mb or greater starts to make timing artifacts look
IS> relatively insignificant.

 BG> Agreed.  In fact, several smaller log entries here (say
 BG> 50Kb or so) show speeds in excess of 4000cps, but these are
 BG> obviously inaccurate. Not so with 1500Kb though, where a
 BG> second or two either way is not likely to make much
 BG> difference at all to the calculated overall cps rate.

Still wondering the name of the program reporting these figures?  I did
some FTP transfers tonight, of about 250K and 530K files, that reported
bytes and times to 1/100 sec .. but when calculated from those times gave
1711 and 1805cps respectively - at 14400/Lapm/Compression!  I don't believe
it.  I zipped up those two zips, squeezing 5% out of the larger, but still
..

IS> So close to seeing those (some say) 'magic' extra zeroes, but so far :)

 BG> Still reckon the 4000cps I saw with Russ was genuine...  :)

Show me a Binkley log segment - it should be repeatable, no? :)

Seriously, you'll recall discussions from V.32bis and then V.fc/V.34 28800
days.  Noone ever reported better than 1700/3400cps, not with Zmodem and
MNP4, with any accurate recording program.  Recall that the maximum
_theoretical_ throughput was 1728cps, with NO file transfer protocol
overheads (i.e raw continuous transmission with NO transfer protocol
blocking / crcs at all).

1728cps at 14400 = 4032cps at 33600.  4000cps at 33600 = 1714cps at 14400. 
Believe it when I see it ..

Cheers, Ian

--- MaltEd 1.0.b5