Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc64.txt.pdf
Дата изменения: Wed Mar 27 23:48:36 2002
Дата индексирования: Tue Oct 2 14:37:25 2012
Кодировка:
Network Working Group Request for Comments #64

M. Elie UCLA

Getting Rid of Marking

Though we realize that this improvement is perhaps somewhat late to be implemented, we believe that there exist better solutions than marking and suggest a simple modification to the IMP-HOST interface which would avoid it. 1. The harm. Marking was introduced to suit the sending Host because it permits the text of a message to start on a word boundary, however, it does not suit the receiving Host with a different word length. Moreover,it introduces in the message useless bits. Let us illustrate this by the example of our Sigma 7, a 32 bit machine. 1.1 Inefficiency in Computation Suppose coded in 8 bit the network. internal code, we receive a message from an 18 bit machine (figure 1.1) ASCII characters which will eventually become standard on In order to translate this message into our EBCDIC for instance. 0 31 -----------------------------| leader | -----------------------------|0001| | ----------| | | | | | | | message | | | | | | | | | | | | | figure 1.1

0 17 -------------------------| leader | -------------------------| | 0 0 0 1| -------------------------| | | | | | | message | | | | | | | | | | | | |

[Page 1]


RFC 64

Getting Rid of Marking

we first have to shift the whole message. We must detect the firsl 1 following the leader, and from this determine that we must shift the message 4 bits to the left. This takes approximately 12 µsec per double word, which makes 1,5 msec per full regular message. This is not huge, but still it is about one-third of the time it will take to translate the message in internal code. 1.2 Inefficiency in transmission More important is the inefficiency resulting unnecessary bits to the message, especially if it character messages are used. Figure 1.2 shows the character text sent by the sigma 7, which results bits to carry 8 bits of information, thus leading factor of 0.07. Supression of marking would from adding turns out that one example of a 1 in transmitting 112 to an efficiency

Sigma 7 Message

16 bits of padding added by sending IMP

----------------------------------| leader | ----------------------------------|00000000000000000000000000000001 | ----------------------------------| text | 000000000000000000000000 | ----------------------------------| 1000000000000000 | -------------------figure 1.2

increase this efficiency to 0.10. For a 32 bit text (length of some control commands), it would increase the efficiency form 0.28 to 0.4. For one packet messages, the efficiency would still be increased by 3%. 2. A remedy. This is a suggested modification of the Host-Imp users interface which has been tentatively sketched on diagrams extracted form BBN 1822 report.

[Page 2]


RFC 64

Getting Rid of Marking

2.1 Host to Imp The modification consists of adding a counter to 32, enabled as the beginning of a message, and incremented at each bit passed to the IMP; when it reaches 32 it forces a "word complete" signal asking for a new word in the shift register and resetting the word length counter; thus the unused bits in the last word of the leader are not transmitted and the message starts with the next word (see figure 2.1) 0 23 -----------------------------------------| leader | | ---------------------| | XXXXXXXXXXXXXXXX | <- contents of |----------------------------------------sending Host memory | | (24 bits) | Message | | | Corresponding message in the sending IMP memory

0 15 -------------------------------| | | | | leader | | | -------------------------------| | | message | | |

figure 2.1 2.2 Imp to Host The modification consists of adding have entered the shift register form the message, the counter allows the register to be full (which is detected by the word entering any new bit from the Imp. a counter to 32. When 32 bits Imp at the beginning of a new to be shifted up to the point length counter) without

[Page 3]


RFC 64

Getting Rid of Marking

Thus, the next bit of the message which is the first bit of text will be entered as the first bit of the next word (see figure 2.2). Message in receiving IMP memory bits) 0 15 -----------------------------| | | leader | -----------------------------| | | message | | | | | Contents of receiving Host memory (35

0 35 -------------------------------------| | | leader | 0000 | -------------------------------------| | | message | | | | | figure 2.2

Though the accumulated cost of useless marking bits network plus computation to reshape received texts modification probably whorkwhile being considered, of our competence and we merely wanted to suggest a marking.

sent over the makes this this decision is not better solution then

Pages 5 and 6 contain a wire Diagram of a "IMP to Host" "Host's special Interface"

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gottfried Janik 2/98 ]

[Page 4]