- USR chars and octets
- Posted by Franc Zabkar on July 7th, 2003
What is the meaning of "chars" and "octets" as reported by USR's link
diagnostics? I notice that the numbers are often of the same order of
magnitude, but can also be wildly different. I would have thought that
octets were groupings of 8 bits sent from DCE to DCE, and that chars
were 8 bit bytes sent between DCE and DTE, but this explanation is
contrary to observations.
- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
- Posted by David L. Holiman on July 8th, 2003
Franc Zabkar wrote:
I think they are related to the compression used by the modems. That's
what I have heard on here before (but can't quote an article at the
moment). The reason the values vary so much sometimes is that sometimes
you transmit/recieve highly compressible data; sometimes you don't.
Someone please correct me if I'm wrong...
--
David L. Holiman
KD5YDU - amateur radio
A+ certified
Network and Systems Administrator
- Posted by Hooda Gest on July 8th, 2003
"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:u8pjgv4hi420ulge4g5j5vk3sjlqm7m0pj@4ax.com...
According to the old Courier manual:
"Octets:
Compressed data units. If the number of octets is greater than
the number of characters sent, the modems probably used MNP5
compression on an already compressed file, and the result was
expanded data."
--
Hooda Gest
"The only thing I do immediately is procrastinate."
- Posted by Franc Zabkar on July 8th, 2003
On Tue, 08 Jul 2003 04:15:14 GMT, "David L. Holiman"
<root@localhost.localdomain> put finger to keyboard and composed:
I thought the same as you until a recent post from a USR winmodem user
reported 86973 Octets Received but only 225 Chars Received. This
strange statistic is what prompted my question.
A search of Google Groups produced the data below. As I expected,
blocks and octets are the result of EC. Therefore no EC means no
blocks or octets. In the case of EC without compression, the numbers
of octets and characters are identical. Based on these data I can only
conclude that certain Winmodem driver software has bugs.
(1) Winmodem, LAPM, V42BIS
http://groups.google.com/groups?selm...u tput=gplain
Chars sent 1415 Chars Received 2808
Octets sent 453681 Octets Received 880869
Blocks sent 14618 Blocks Received 10585
Blocks resent 349
Retrains Requested 1 Retrains Granted 39
REJs Received 72 Blers 9
Link Timeouts 37 Link Naks 72
(2) Winmodem, LAPM, V42BIS
http://groups.google.com/groups?selm...&output=gplain
Chars sent 2249 Chars Received 3192
Octets sent 16376 Octets Received 110191
Blocks sent 872 Blocks Received 1147
Blocks resent 0
Retrains Requested 0 Retrains Granted 0
REJs Received 0 Blers 1
Link Timeouts 0 Link Naks 0
(3) Winmodem, MNP EC, no data compression
http://groups.google.com/groups?selm...&output=gplain
Chars sent 26313 Chars Received 777747
Octets sent 26313 Octets Received 777747
Blocks sent 3057 Blocks Received 3239
Blocks resent 17
Retrains Requested 0 Retrains Granted 0
REJs Received 0 Blers 1
Link Timeouts 0 Link Naks 0
(4) Winmodem, LAPM, V42BIS
http://groups.google.com/groups?selm...ut put=gplain
Chars sent 60900 Chars Received 368444
Octets sent 28342 Octets Received 301468
Blocks sent 1602 Blocks Received 1574
Blocks resent 10
Retrains Requested 0 Retrains Granted 0
REJs Received 2 Blers 4
Link Timeouts 0 Link Naks 2
(5) Courier V.Everything, V42BIS, LAPM SREJ 128/5
http://groups.google.com/groups?selm...&output=gplain
Chars sent 321007 Chars Received 6505804
Octets sent 197217 Octets Received 6452756
Blocks sent 29530 Blocks Received 56045
Blocks resent 5
Retrains Requested 0 Retrains Granted 0
Line Reversals 0 Blers 70
Link Timeouts 0 Link Naks 0
(6) Courier V.Everything, V42BIS, LAPM SREJ 128/5
http://groups.google.com/groups?selm...&output=gplain
Chars sent 116043 Chars Received 1735148
Octets sent 65701 Octets Received 1004825
Blocks sent 8035 Blocks Received 13184
Blocks resent 0
Retrains Requested 0 Retrains Granted 1
Line Reversals 0 Blers 28
Link Timeouts 0 Link Naks 0
(7) no EC, no compression
http://groups.google.com/groups?q=g:...ptusnet.com.au
Chars sent 28570 Chars Received 331381
Octets sent 0 Octets Received 0
Blocks sent 0 Blocks Received 0
Blocks resent 0
Retrains Requested 0 Retrains Granted 0
Line Reversals 0 Blers 0
Link Timeouts 0 Link Naks 0
- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
- Posted by Franc Zabkar on July 8th, 2003
On Tue, 08 Jul 2003 13:36:03 GMT, "Hooda Gest" <Be@One_With.Calm> put
finger to keyboard and composed:
If you compare the post-call reports of winmodems in two recent posts,
both using LAPM V42bis, then the first contains expected statistics
....
http://groups.google.com/groups?selm... utput=gplain
.... while the second ("Hanging mode, part duex", not archived) shows
86973 Octets Received but only 225 Chars Received. Is the latter a
bug, or am I misunderstanding something?
- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
- Posted by Franc Zabkar on July 9th, 2003
On Tue, 08 Jul 2003 22:50:57 GMT, "Hooda Gest" <Be@One_With.Calm> put
finger to keyboard and composed:
You are using software compression which means that all your received
data are incompressible as far as your modem is concerned. Therefore
your character count should always (?) be less than your octet count.
I'm guessing that the relationship would be ...
chars = octets - EC overhead
My other post in this thread has examples of compressible downloads.
In these examples chars outnumber octets by as much as 2:1, which is
typical for text based data.
That was my original thought, but my guess is that it is a bug.
- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
