RC>That's not the whole story, and is a little misleading.  While the
RC>data on the DCE is sent without start and stop bits, _some_ of that
RC>data is header information used by the EC protocol itself, and isn't
RC>passed on to the DTE link.  A 31,200 DCE connect will result in about
RC>36,000 bps on the DTE.
Yep, you're right. I forgot about LAP-M's overhead. Using David
Bowerman's formula:
DCE/8*10 * data_bits_per_packet/(data_bits_per_packet+7) * 60/61
At 31,200 DCE with no compression (&K0) and with a LAP-M data
frame size of 128+7 bytes there should be a DTE transfer rate of
36,372 bps and with 244+7 byte frames (USR V.Everything) it
should reach 37,291 bps. This is still under the 38,400 bps DTE
rate.
Since the tramsfer rate is below the DTE speed I think there
should be no need for hardware flow control.
Of course there will be a delay introduced by the DCE->DTE
conversion but this should be a fixed offset so that the
flow rate of the imbedded data in the DCE shouldn't exceed the rate
it is transferred to the comms program (assuming no compression
in effect).
The error rate was quite low but even if it was higher, with the
same DCE, more errors means less data going to the comms program
so that is a lower effective rate on the DTE channel.
RC>db> Here are actual results. On a V.34+ connection between USR
RC>db> V.Everything Couriers. DCE 31,200 bps. Couldn't get more than
RC>db> about 2,665 cps (85% efficiency) (using Zmodem) transferring a
RC>db> 560K zipfile if the DTE is set to 38,400 bps. Once I returned
RC>db> the DTE to 57,600bps then the transfer rate returned to
RC>db> 3570-3600cps (114%-115%).
RC>I won't dispute your findings, but I'd suggest the reason is not
RC>simply the DTE speed being overwhelmed by the data rate.
I can only assume that there must be "jerkiness" in the
modem->comms program data flow as well as a straight time delay
so that 37,291 DTE effective DTE transfer rate requires more than
a fixed 38,400 bps DTE rate. (Although the DTE channel is async I
presume that "38,400 bps" would only be attainable with a
constantly flowing data stream.) Might try and put my 35MHz
oscilloscope on the data line and take a look, but it might be
hard to sync to it.
Cheers, Dan Bridges, Brisbug PCUG.
___
 X SLMR 2.1a X 
--- Maximus/2 3.01
---------------