Dan Bridges wrote in a message to David Bowerman:
 DB> I'm writing an article on high-speed comms. I wrote one in the days
 DB> of v32bis and it's time for another go. Perhaps you could help me
 DB> with some info.
I'm not at home so will be doing much of this from memory -- I'll try to 
avoid screwing up but no promises.
 DB> 1. Could you describe the LAPM and MNP4 packet structure.
.  The flag bytes can be combined to 
reduce the overhead to 6 bytes from 7 however I've never seen that in actual 
use.
 DB> 2. Which is the correct term for this data structure:
 DB> Frame, Packet or Block?
I've favoured packet but would have to check the docs for the "correct" term.
 DB> 3. I seem to remember that MNP4 gives slightly higher throughput
 DB> compared to LAPM but that LAPM hangs on better in difficult
 DB> circumstances. Since the packet sizes appear to be the same I would
 DB> expect the throughput to be the same also. Comments?
The default LAPM packet size is 128 while the default MNP4 packet is 256 
bytes. The overhead for a 128 byte packet is ~6.75% while the overhead for a 
256 byte packet is ~4.25%.  Given the same (or close) packet size, the 
throughput will be virtually identical. Using the USR 244 byte LAPM packet 
gives us an overhead of 4.38% compared to an MNP4 256 byte packet, I've found 
that on a RAR solid archive of 3.4MB, the throughput is virtually identical 
-- if no errors occur.
 DB> 4. LAPM still uses 16-bit CRC, doesn't it. If you believe it hangs
 DB> on better than MNP4 do you know what increases its performance in 
 DB> this area?
I'm not sure what you mean by hangs on better.
 DB> 5. Beside 128/15 and 244/8, my Courier v34+ also uses 244/15 to
 DB> another Courier V34+. I don't know how common this is with other
 DB> v34 and v34+ modems.
Rather rare at this point in time.
 DB> 6. With reference to SREJ, the way the quote above is written it
 DB> appears that the throwaway without SREJ *is* either 8 or 15
 DB> packets but shouldn't this be up to a *maximum* of 8 or 15
 DB> packets (i.e. it depends on roundtrip delay + 2 passes through the
 DB> data pumps).
Yes, it would be a maximum.  The actual number would depend on the delay 
between the sending modem sending the packet and the time it processed the 
NAK packet.
 DB> 7. At 28,800bps, (244+7) = 9ms and (128+7) = 4.8ms. (I assume that
 DB> the 244 or 128 values are for the data octets only, not the packet
 DB> extras.)  On a intra-city connection I get 2ms roundtrip delay
 DB> reported so I presume that a short (less than 9ms) burst of noise
 DB> occuring at the beginning of a packet would produce a NAK (or
 DB> whathever LAPM uses) at my end within 41ms (9ms+2ms+30ms
 DB> double-pass through the data pumps (source for 30ms figure:
 DB> 20-50ms datapump range mentioned in "What is Selective Reject" at
 DB> http://www.geocities.com/SiliconValley/Park/2432/modem.htm)). 
At 28,800, you'll be sending 3600 bytes/second so the time for the (244+7) 
reduces to 7ms vs 3.8 ms for (128+7).  Similar to synchronous protocols, no 
start/stop bits are used so divide by 8 rather than 10.  I haven't bothered 
with the zero bit insertion here either (a 0 bit is inserted every 60 bits on 
the average).  This would make the equation change to (packet size*8*61)/(DCE 
speed*60).
 DB> This would be received during the transmission of the 5th 244 frame
 DB> (or 8th 128 frame). I presume without SREJ this 5th frame would be
 DB> aborted shortly afterwards, not at the end of the 5th frame.
The NAK packet that is sent would cause the sending modem to rewind to the 
start of the packet number given by the NAK packet and restart from there 
after the current packet has completed sending (again, I'm going by memory 
here but as I remember it, the packet in progress is not aborted).  In the 
case of SREJ, only the packet corresponding to the number in the NAK packet 
would be resent to be inserted at the correct point in the data stream by the 
receiving modem.
 DB> Without SREJ, frames 1, 2, 3, 4, 5, would be retransmitted. With
 DB> SREJ only frame 1 would be resent.
Correct.
 DB> So in an intra-city situation the difference between no SREJ and
 DB> SREJ present would be 4 244 frames or 7 128 frames, best case
 DB> (short noise burst at start of frame) or 5 244 frames or 8 128
 DB> frames, worsecase (if the short noise burst overlapped the end of
 DB> one frame and the beginning of the next). This would produce a
 DB> throughput degradation difference with/outout SREJ of 3.6% of the
 DB> normal cps, with a 244-byte frame size, for each whole-number
 DB> increment in the avg_number_of_errors/sec rate, assuming that most
 DB> noise only affected one frame at a time. (3.3% for 128-byte
 DB> frames.) Of course, a longer turnaround delay would increase the
 DB> difference further. Comments?
As far as I can tell without checking the docs, this should be correct.
 DB> 8. Have you nay idea of the fallback/fallforward times for v32,
 DB> v32bis, vfc and v34?
This I would definitely have to check the docs on.  Not the type of number I 
tend to memorize and carry around with me. ;-))  You might want to toss this 
question at Craig Ford or check the ITU-T web site (have your credit card and 
calculator ready -- all prices are quoted in Swiss francs).
Regards,
       David
--- timEd/2 1.10+
---------------