TIP: Click on subject to list as thread! ANSI
echo: hs_modems
to: DAN BRIDGES
from: DAVID BOWERMAN
date: 1997-04-29 14:44:00
subject: Lapm & Srej (2/2)

Dan Bridges wrote in a message to David Bowerman:
 DB> Could you tell me more about the zero-bit insertions. I haven't
 DB> heard about this before. In your equation above shouldn't 61 be the
 DB> denominator (the one on the bottom) and 60 would be the
 DB> numinator (the one on top) since the presence of an occasional
 DB> extra non-data bit would reduce the throughput?
Part of the inheritance of MNP4/LAPM from the SDLC/HDLC synchronous 
protocols.  As the book says, they are inserted for transparency.  In the 
case above, where I was looking at the increase in time due to the bit 
stuffing, 61/60 would be correct.
 DB> Assuming that there was an extra 1 in every 60 bits in the data
 DB> flow, the max cps figures at 28,800bps would be 3,442cps (244+7)
 DB> and 3,357cps (128+7). I used:  DCE_rate/8/(244+7)*(244)/61*60. 
 DB> This would lead to max. theoretical efficiency rates of 119.5%
 DB> (244+7) and 116.6% (128+7). I used: cps*10/DCE_rate.
Pretty much the numbers that I come up with.
 DB> Do you know at what the additional overheads are for Zmodem16,
 DB> Zmodem32 and Ymodem-G. I seem to remember someone saying that
 DB> Ymodem-G's overhead was 0.5%.
Sorry, I can't help you there.  Going by my memories of XModem-CRC, your .5% 
for YModem would be close to correct.
 DB> I think the highest overall efficiency I've ever seen (at
 DB> 14,400bps) was with a 4MB file using MNP4 and Ymodem-G where I saw
 DB> 1705cps, or was it 1710cps? (118.4%|118.75%)
That would be pushing the limit of what's possible at that speed but doable.
DAN> This would be received during the transmission of the 5th
DAN> 244 frame or 8th 128 frame.
 DB> Using the new timing figures, assuming an intra-city roundtrip
 DB> delay of 2ms, 30ms for a double-pass through the data pumps,
 DB> near-instantaneous error-detection and transmission of the NAK from
 DB> the remote modem, the NAK would arrive at the tranmitter either
 DB> 100ms (244+7) or 70ms (128+7) after the start of
 DB> pre-transmission processing of the affected frame. I used:
 DB> frame_time + roundtrip_delay + data-pump_double-pass_time.
 DB> This arrival would occur during the transmission of the second
 DB> frame. So the only difference with/without SREJ would be the
 DB> retranmission of frame 1 vs frames 1 & 2. This would lead to a
 DB> with/without SREJ throughput degeneration of 7%/14% (244+7) or
 DB> 3.75%/7.5% (128+7) for every whole-number increment in the
 DB> errors/sec rate. This analysis assumes: short round_trip delays
 DB> (i.e. not long distance); errors affecting only one frame at a time
 DB> (i.e. no overlap); quick NAK response after the data has cleared
 DB> the remote data-pump.
Regards,
       David
--- timEd/2 1.10+
---------------
* Origin: Frog Hollow -- a scenic backroad off the Infobahn (1:153/290)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.