info-kermit@ucbvax.ARPA (07/24/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Tue, 23 Jul 1985 Volume 3 : Number 8
Departments:
PROPOSAL FEEDBACK -
Sliding Window Proposal, Cont'd
Sliding Window Proposal Q & A
MISCELLANY -
Conversion Tables, Liberalized Requirements
More about IBM Professional Graphics Controller (several msgs)
Using Kermit with Ungermann-Bass Net One?
----------------------------------------------------------------------
Date: Tue 23 Jul 85 13:12:23-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Sliding Window Proposal, Cont'd
The proposal in Info-Kermit V3 #7 should have been dated July 19, not June
12, and the formatting of the state table at the end appears to have been
messed up -- apologies.
The next message (about 10K long) gives some informal information about
the proposal in the form of questions and answers. Comments, reactions,
suggestions on both the long-packets and the windowing proposals encouraged.
------------------------------
Date: Mon 22 Jul 85 09:30:00-EDT
From: Leslie Spira <OC.SOURCE@CU20B>
Subject: Sliding Window Proposal Q & A
KERMIT WINDOWING PROTOCOL
DRAFT PROPOSED DEFINITION DATED JULY 19, 1985
QUESTIONS AND ANSWERS
John Mulligan, The SOURCE Telecomputing
July 19, 1985
Q. What is the purpose of the "windowing" extension?
A. The object is to speed up file transfers using KERMIT. The increase
will be especially noticeable over the data networks (such as Telenet
and Tymnet) and over connections using satellite links. This is
because there are long communications delays over these connections.
Q. How does it work?
A. Basically, it allows you to send several packets out in a row before
getting the first acknowledgment back. The number of packets that can
be sent out is set by the "window size", hence the name windowing.
Q. Could you explain in more detail?
A. Right now, a system sending a file transmits one packet of data, then
does nothing more until it gets back an acknowledgment that the packet
has been received. Once it gets an acknowledgment, it sends the next
packet of data. Over standard direct-dial land-based phone lines, the
transmission delays are relatively small. However, the public data
networks or satellite links can introduce delays of up to several
seconds round trip. As a result, the sending system ends up spending
much more time waiting than actually sending data.
With the new windowing enhancement, the sending system will be able to
keep sending data continuously, getting the acknowledgments back
later. It only has to stop sending data if it reaches the end of the
current "window" without getting an acknowledgment for the first
packet in the current "window".
Q. What size is the "window"?
A. The window size can vary depending on what the two ends of the
connection agree on. The suggested standard window size will be 8
packets. The maximum is 31 packets.
The KERMIT sequence numbering is modulo 64 (it "wraps" back to the 1st
sequence number after the 64th sequence number). It is helpful to
limit the maximum window size to 31 to avoid problems (ambiguous
sequence numbers) under certain error conditions.
Q. Is windowing in effect throughout a KERMIT session?
A. No, it is only in effect during the actual data transfer (data
packets) portion of a file transfer. Windowing begins with the first
data packet (D packet type), and stops when you get an End-of-File
packet (Z packet type).
Q. Why does it stop when you get to the End-of-File packet?
A. This is done primarily to avoid having more than one file open at
once.
Q. Why will windowing be especially helpful at higher baud rates over
communications paths that have delays?
A. As you increase the baud rate, the transmission speed of the data
increases, but you do not change the delay caused by the
communications path. As a result, the delay becomes more and more
significant.
Assume, for example, that your communications path introduces a delay
of 1 second each way for packets, for a total delay of 2 seconds round
trip. Assume also that your packets have 900 bits in them so it takes
you 3 seconds to send a packet at 300 baud (this is roughly equivalent
to a typical KERMIT packet).
WITHOUT windowing, here is what happens:
If at 300 baud you transmitted data for 3 seconds (sending 900 bits),
then waited 2 seconds for each acknowledgment, your throughput would
be roughly 180 baud. (Total time for each transmission = 5 seconds.
900/5 = 180).
Howver, if you went to 2400 baud, you would transmit data for 3/8
second, then wait 2 seconds for an acknowledgment. (Total time for
each transmission = 2 and 3/8 seconds). The throughput would increase
only to about 378 baud. (900 / 2.375 = 378).
The delay becomes the limiting factor; in this case, with this packet
size, the delay sets an outside limit of 450 baud (900 / 2 second
delay = 450), no matter how fast the modem speed.
WITH windowing, the throughput should be close to the actual
transmission speed. It should be possible to send data nearly
continuously. The exact speed will depend on the window size, length
of transmission delays, and error rate.
Q. Are there any new packet types introduced by this extension?
A. No, the only change is to the contents of the Send-Init packet, to
arrange for windowing if both sides can do it. If either side cannot,
KERMIT will work as it does now. Adding an extension such as this was
provided for in the original KERMIT definition. See section 3 of the
windowing definition for details.
Q: On the receive side, in section 4.2, why does the definition say that
writing to disk is done when the Receive-Table becomes full rather
than as soon as you get a good packet?
A: The definition was phrased this way because it makes the logic of the
receive side clearer and simpler to implement.
Actually, you could also write a packet to disk when it is a good
packet and it is the earliest entry in the receive table. This
approach has the disadvantage that you don't know at this point that
the sender has received your ACK, so you have to be prepared to handle
the same packet later on if the sender never gets the ACK, times out,
and sends the same packet again. Thus you have to be prepared to deal
with packets previous to the current window; you will have to ACK such
a packet if it has been received properly before.
By writing packets to disk only when the receive table becomes full,
(the oldest packet) you know that the sender has received your ACK
(otherwise the sender could not have rotated the window to the n+1
position to send the current packet, where n is the window size).
This makes it very easy to stay in synch with the sender. The
disadvantage of this approach is that when you receive the End-of-File
packet, you have to take the time to write all the remaining packets
in the Receive-Table to disk.
Q. Could you briefly explain what happens if a single packet gets
corrupted?
A. In essence, the receiver will ignore the bad packet. When it gets the
next good packet, it will realize (because packets are numbered) that
one or more packets were lost, and NAK those packets. The receiver
continues to accept good data.
As long as the sender's window does not become "blocked", the only
loss of throughput will be the time it takes to transmit the NAKed
packets.
For a full description, see section 4.2 of the windowing definition.
Q. There are currently two proposals for KERMIT extensions: the Windowing
extension and a proposal for extended packet lengths. What are the
relative advantages and disadvantages of sliding windows and extended
packet lengths?
A. What is best depends on the exact conditions and systems involved in a
particular file transfer. There are some general rules however.
Windowing helps more and more as the communications path delays get
longer.
Windowing is also more and more helpful as the baud rate goes up.
Increased packet length is most helpful on circuits with low error
rates. If the error rate is high, it is difficult for a long packet
to get through uncorrupted. Also, it then takes longer to re-transmit
the corrupted packet.
On some machines, the CPU time to process a packet is relatively
constant no matter what the packet length, so longer packets can
reduce CPU time.
Q. Are extended packet lengths and sliding windows mutually exlusive?
A. No, there is no real reason that they would have to be. As a
practical matter, it is slightly easier to implement windowing if you
know the maximum packet size ahead of time, since you can then just
use an array to store your data. In standard KERMIT, you know
automactically that your maximum packet length is 94, so you can just
go ahead and dimension an array at 94 by Window-size.
If you are going to use both extended packet length and windowing, you
need to select the maximum packet length and window-size so that the
combination does not exceed the available memory for each side of the
transfer.
In addition, it is possible to see the desired relationship between
packet size and windowing for various baud rates and communications
delays. For the common case of an error corrected by one
retransmission of the corrupted packet, the minimum window size needed
for continuous throughput (the window never gets "blocked") can be
calculated by:
4 x delay x baud rate
WS > 1 + ------------------------
packet-size x 10 ;(this is the # of bits)
Windowing always helps (the minimal continuous throughput window size
is always greater than 1).
In the above equation, the "4" derives from the fact that a corrupted
packet has 4 transit times involved:
Original (bad checksum) packet
NAK for the packet
Retransmission of packet
ACK for retransmission.
All of this must happen before the window becomes blocked.
The "delay" is the effective maximum one-way communications path
delay, which includes any CPU delays.
Strictly speaking, the "packet-size" should have the length of the ACK
packets added to it.
As an example, if you assume a 2-second (one-way) delay, at 1200 baud,
with a packet size of 94, the minimum window size for continuous
throughput would be:
4 x 2 x 1200
WS > ------------ = 10.2
94 x 10
Under these circumstances, a window size of at least 11 should be
chosen, if possible.
------------------------------
Date: Sat, 20 Jul 85 10:47:19 PDT
From: VSS7853@UCLAVM
Subject: Conversion Tables, Liberalized Requirements
Regarding the message I sent the other day with the programs for
constructing and analyzing ATOE and ETOA tables, I think I could have
expressed my thesis a bit more clearly.
Kermit-TSO and Kermit-CMS require that the TCAM (or whatever) tables
be, loosely speaking, inverses of one another. I claim that this
requirement is too restrictive and prevents Kermit from working on
systems where it otherwise might.
On Ebcdic machines, Kermit performs the following four translations:
1. (e to a) predict the Ascii form of an outgoing message so that a packet
can be constructed in Ascii.
2. (a to e) map the packet back to Ebcdic for outputting and final
reconversion by TCAM.
3. (e to a) reconstruct the Ascii form of an incoming packet already
converted by TCAM, so that the packet can be analyzed in Ascii.
4. (a to e) map the incoming message back into its final Ebcdic form.
Presently these four internal transformations are done with only two tables,
each identical to the corresponding TCAM table. Whence the requirement that
the two TCAM tables be inverses of one another.
I claim that by constructing four tables, one for each of the above numbered
functions, two benefits would accrue:
1. The requirements on the TCAM tables would be weakened. Each table would
have to be invertable separately, but they would no longer have to be
inverses of each other.
2. Kermit could guarantee a standard correspondance between the two character
codes for messages transmitted from Ascii machines to Ebcdic and vice
versa, instead of accepting the correspondance imposed by the local TCAM
tables.
In the other message I attempted to give precise weakened mathematical
requirements for the TCAM tables so that this method would work.
Also tools would have to be developed to construct the necessary translation
tables to be used by Kermit. These tools ought to be included in the
distribution.
What do you think?
Glenn Thobe
EE dept., UCLA
818-888-8434
p. s. Please address replies to both IVA3GET@UCLAMVS and VSS7853@UCLAVM
(BITNET).
------------------------------
Date: Mon 22 Jul 85 16:55:26-EDT
From: Charlie C Kim <US.CCK@CU20B>
Subject: IBM Professional Graphics Controller
It's called a Professional Graphics Controller (not Adapter). Waiting for
the vertical retrace on the EGA isn't a bad thing to do--it's just
unnecessary in the enhanced mode. It isn't so clear that it's the wrong
thing to do when it is emulating the CGA.
The problem with losing characters above 1200 baud on the PGC is well known.
The following message from the IBM-PC bulletin board should clarify the
issue:
Date: Thu, 4 Jul 85 13:54 EDT
From: "Roger C. King" <RCKing@MIT-MULTICS.ARPA>
Subject: Professional Graphics Controller Fix
We have had IBM replace more than a dozen Professional Graphics controllers
with corrected units which work correctly with previous communications
packages at 9600 baud. The old unit did not work correctly at all, but sort
of worked on an AT at 2400 baud (sort of means some dropped characters) and
sort of worked on an XT at 1200 baud. It takes an individual, case by case,
interface with IBM to get this resolved, but it is possible for a field
office to get someone at Boca to send out corrected boards for a swap. A
good controller can be recognized as follows:
Looking at a controller with the output on the right, the top left
corner of the board has a 'REV' number, probably 6323698, whited out
with white paint or something similar. A bad board(s), does not have
this number modified.
As an aside, we have found the Professional Graphics Controller to be an
almost perfect emulator of the old Color Graphics controller. Even
low-res software seems to work correctly.
Roger King
------------------------------
From: Herm Fischer <hermix!fischer@RAND-UNIX>
Subject: Professional Graphics Controller
Date: Mon Jul 22 16:02:42 1985
Carl Houseman reports problems over 1200 baud with this display. He should
be aware that the async ports dont work over 1200 at all unless he gets
replacement PGA cards from IBM. The original cards had hardware/firmware
problems which interfered with comm activity; IBM has "recalled" those
cards.
I am using the EGA on Xenix and on MSDOS with kermit. So far no problems,
but have not tried EGA with MSDOS above 1200...
------------------------------
Date: 23 July 1985 1350-PDT (Tuesday)
From: germar@nprdc.arpa (Marcelo Germar)
Subject: Using Kermit with Ungermann-Bass Net One?
Does anybody have experience using ibm pc kermit with ungermann-bass net one
to transfer files between a vax with 4.2bsd unix and an ibm pc?
What should be the configuration of the ungermann-bass hardware/software
to enable a successful file transfer?
All your help will be sincerely much appreciated.
thanks,
marcelo
------------------------------
End of Info-Kermit Digest
*************************
-------