RFC64 Getting rid of marking

0064 Getting rid of marking. M. Elie. July 1970. (Format: TXT=7556 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

Network Working Group                                  M. Elie
Request for Comments #64                               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 we receive a message from an 18 bit machine (figure 1.1)
coded in 8 bit ASCII characters which will eventually become standard on
the network.  In order to translate this message into our EBCDIC
internal code, for instance.

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

                            figure 1.1






                                                                [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 from adding
unnecessary bits to the message, especially if it turns out that one
character messages are used. Figure 1.2 shows the example of a 1
character text sent by the sigma 7, which results in transmitting 112
bits to carry 8 bits of information, thus leading to an efficiency
factor of 0.07. Supression of marking would

                            -----------------------------------
   Sigma 7                  |           leader                |
                            -----------------------------------
   Message                  |00000000000000000000000000000001 |
                            -----------------------------------
                            | text | 000000000000000000000000 |
                            -----------------------------------
   16 bits of padding       | 1000000000000000 |
   added by sending IMP     --------------------

                                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 a counter to 32. When 32 bits
have entered the shift register form the Imp at the beginning of a new
message, the counter allows the register to be shifted up to the point
to be full (which is detected by the word length counter) without
entering any new bit from the Imp.








                                                                [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  Contents of receiving Host memory (35
bits)

0                        15      0                                   35
------------------------------   --------------------------------------
|                            |   |                                    |
|       leader               |   |     leader                  | 0000 |
------------------------------   --------------------------------------
|                            |   |                                    |
| message                    |   | message                            |
|                            |   |                                    |
|                            |   |                                    |

                               figure 2.2

Though the accumulated cost of useless marking bits sent over the
network plus computation to reshape received texts makes this
modification probably whorkwhile being considered, this decision is not
of our competence and we merely wanted to suggest a better solution then
marking.


            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]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

OR演算子 論理和

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る