TIP: Click on subject to list as thread! ANSI
echo: hs_modems
to: ALL
from: DAN BRIDGES
date: 1997-05-21 16:07:00
subject: LAP-M Figures

ATI6
USRobotics Courier HST Dual Standard V.34+ Fax Link Diagnostics...
Chars sent           136212      Chars Received      2251810
Chars lost                0
Octets sent           72453      Octets Received     1003742
Blocks sent            9569      Blocks Received       10912
Blocks resent          1253
Retrains Requested        0      Retrains Granted          0
Line Reversals            0      Blers                   344
Link Timeouts            51      Link Naks               206
Data Compression       V42BIS 2048/32
Equalization           Long
Fallback               Enabled
Protocol               LAPM 128/15
Speed                  31200/21600
Last Call              04:16:56
Disconnect Reason is DISC Received
OK
I think with the help of the docs in USRST419.xxx I understand
this display better. Observations:
1. Transmission compression ratio is 1.9:1
2. Reception compression ratio is 2.2:1
3. BLers is 344 indicating that reception errors were detected in
344 50-ms periods. This does not indicate how many errors occured
within any particlar 50ms time-slice, only the count of affected
periods. At 31,200bps DCE, using 128+7 LAP-M data frames, frame
transfer takes 4.3ms, so theoretically, a up to a maximum of 11
corruptly received frames could be counted as 1 Bler. Since there
were over 300,000 50-ms periods in this long session, the Bler
rate was (344/308,320) i.e. 1 in every 896 50-ms time periods
was blighted. This is an average of 1 received BLer every 44.8
secs. Since the DCE link operates synchronously, the Bler error
count can increment even when there appears to be no user/remote
activity occuring on the link.
4. 206 times the remote modem was not happy with the data I sent
it and requested a resend. This resulted in a total of 1,253
blocks being resent by my modem. Since the remote modem did not
have selective reject (SREJ), all blocks received after the
corrupt one, and before the corrupt one was successfully
re-received, were discarded. The ratio of Blocks resent:Link NAKS
(1253/206) = 6.1:1 which suggests that if, only 1 block was
affected at a time, that it took another 5 frames' transfer time
(21.5ms) for processing. Since the roundtrip delay to my ISP is
2ms, this suggests that a double-pass through the modems' data
pumps is taking about 20ms. If an average of two frames were
affected per error burst then this would reduce the processing
time to only 17ms. It will take a lot of further stats of long
sessions to see if the 6:1 ratio is typical for my situation.
5. 51 times the remote modem did not return an acknowlegment
within the specified time of 64.5ms (4.3ms * 15).
6. The ratio of octets received to blocks received is a bit
mystifying. First off, I'll use a simple example. I've just
received 2,882,207 octets (a 2.8M zipfile) at 28,800 bps and did
a file search, using LAP-M 244/8. The number of octets reported
was 11,965 with only 6 Blers (no other errors). The file itself
would have took 11,812 244+7 data frames + about 24 other frames
for the retransmissions required for the 6 Blers (assuming a
total of 4 frames are lost per Bler (244+7 at 28,200bps DCE =
8.9ms. With a 21.5ms error reply delay, there would be 1 (initial
error) + 3 extra frames sent/lost)). This leaves 119 frames
unaccounted for. I presume this was for the establishment of the
V.42 session and for the file search.
However if you apply this to the displayed figures above, then
1,003,3742 octets / 128 = 7,842 128+7 data frames. Assigning 100
frames for the connection leaves 2,970 frames unaccounted for.
344 Blers at 6 frames affected/sent/lost per Bler = 2,064 frames.
Still leaves about 900 frames unaccounted for. Any ideas?
7. The reception/sending speed differential is astounding. In two, long
Internet sessions I've ended up with a 21,600bps sending speed (the
2nd session's reception speed was 28,800bps). I don't know whether
the Blocks Sent:Link NAK ratio (9,569/206) of 46:1 indicates that
sending difficulties were encountered and that the sending speed was
consequently lowered. Comments?
Cheers, Dan Bridges, Brisbug PCUG.
___
 X SLMR 2.1a X 
--- Maximus/2 3.01
---------------
* Origin: madHouse Inc (3:640/820)

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™.