summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc392.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc392.txt')
-rw-r--r--doc/rfc/rfc392.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc392.txt b/doc/rfc/rfc392.txt
new file mode 100644
index 0000000..8bec0dc
--- /dev/null
+++ b/doc/rfc/rfc392.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group G. Hicks
+Request for Comments: 392 B. Wessler
+NIC: 11584 Utah
+ 20 September 1972
+
+
+ Measurement of Host Costs for Transmitting Network Data
+
+Background for the UTAH Timing Experiments
+
+ Since October 1971 we, at the University of Utah, have had very large
+ compute bound jobs running daily. These jobs would run for many cpu
+ hours to achieve partial results and used resources that may be
+ better obtained elsewhere. We felt that since these processes were
+ being treated as batch jobs, they should be run on a batch machine.
+
+ To meet the needs of these "batch" users, in March of this year, we
+ developed a program[1] to use the Remote Job Service System (RJS) at
+ UCLA-CCN. RJS at UCLA is run on an IBM 360/91.
+
+ Some examples of these jobs were (and still are!):
+
+ (a) Algebraic simplification (using LISP and REDUCE)
+
+ (b) Applications of partial differential equation solving
+
+ (c) Waveform processing (both audio and video)
+
+ The characteristics of the jobs run on the 91 were small data decks
+ being submitted to RJS and massive print files being retrieved. With
+ one exception: The waveform processing group needed, from time to
+ time, to store large data files at UCLA for later processing. When
+ this group did their processing, they retrieved very large punch
+ files that were later displayed or listened to here.
+
+ When the program became operational in late march -- and started
+ being used as a matter of course -- users complained that the program
+ page faulted frequently. We restructured the program so that the
+ parts that were often used did not cross page boundaries.
+
+ The protocol with RJS at UCLA requires that all programs and data to
+ be transmitted on the data connection be blocked[2]. This means that
+ we simulate records and blocks with special headers. This we found
+ to be another problem because of the computation and core space
+ involved. This computation took an appreciable amount of time and
+ core space we found because of our real core size that we were being
+ charged an excessive amount due to page faulting. The page faulting
+ also reduced our real-time transmission rate to the extent that we
+
+
+
+Hicks & Wessler [Page 1]
+
+RFC 392 Measurement for Transmitting Network Data September 1972
+
+
+ felt a re-write of the transmitting and receiving portions of the
+ program was needed. In order that the program receive the best
+ service from the system, these portions optimized so that they each
+ occupied a little over half of a page. As we now had so few pages in
+ core at any one time, the TENEX scheduler could give the program
+ preference over larger working set jobs. (As an aside, because of our
+ limited core, we have written a small (one and one half pages) editor
+ in order to provide an interactive text editing service.)
+
+ The mechanism to access the network under TENEX is file oriented.
+ This means byte-in (BIN) and byte-out (BOUT) must be used to
+ communicate with another host. The basic timing of these two
+ instructions (in the fast mode) is 120 us per byte to get the data
+ onto or off of the network[3]. A distinction was made because the
+ TENEX monitor must do some "bit shuffling" to ready the users bytes
+ to be transmitted or it must put the network messages into some form
+ that is convenient for the user. This is the "slow bin, bout" and
+ occurs once per message. If the users bytes are 36 bits long then it
+ will take an average of 500 us per message. If the bytes have to be
+ unpacked from the message to be usable, then it may take up to a
+ milli-second depending on the size of the message[3].
+
+II. Measurements and Results
+
+ We found by timing various portions of the program that the RJS
+ program was using 600 to 700 us per bit byte or between 75 and 85
+ micro-seconds of chargeable cpu time per bit. (See tables 1 and 2 for
+ actual results). A short discussion of how these figures were
+ obtained is now in order. NOTE! We have not been trying to measure
+ network transmission rates; Rather, how much it costs us to take a
+ program (data) from our disk and send it to another host to be
+ executed (processed).
+
+ Column 1 is the clock time (real-time) from when the first byte was
+ brought in from the disk until the last byte had gone onto the
+ network. (Or from the time we received the first byte from the
+ network until the disk file was closed).
+
+ Column 2 is computed in the same manner as column 1 except that it is
+ the chargeable runtime for the process.
+
+ Column 3 is the actual number of bytes that went onto or came from
+ the network. The letter that follows this column indicates the
+ direction. E.G. s for sending to UCLA, r for receiving from UCLA).
+
+ Column 4 was calculated by the following formula:
+ Bits per second = (real-time)/((number of bytes)*8)
+
+
+
+
+Hicks & Wessler [Page 2]
+
+RFC 392 Measurement for Transmitting Network Data September 1972
+
+
+ Column 5 was calculated by the formula:
+ us/bit = (chargeable runtime)*1000/((number of bytes)*8)
+
+ Column 6 is the 5 minute load average. (See TENEX documentation for
+ details.)
+
+ Using these figures we can conclude that for a million bits of
+ information -- programs to be executed or data -- it would take 75 to
+ 85 cpu seconds to transmit. At a cost of $474.60 per cpu hour on
+ TENEX's[5], this millionbits would cost $9.90 to 11.20 to transfer
+ from the originating host and potentially the same for the foreign
+ host to receive. This is about 33 to 37 times higher than the
+ predicted network transmission costs[4].
+
+ It is to be noticed that, in some cases, for programs to be
+ transmitted over the network, the cost incurred by transmitting them
+ was greater than the cost of executing these programs at the foreign
+ host!
+
+III. Analysis
+
+ There may be numerous ways to reduce the cost of the network to the
+ host:
+
+ (a) Treat the network not as a file device but as an interprocess
+ communications device[6].
+
+ (b) Create an 'intelligent' network input/output device. This
+ would, of course, be customized for individual types of
+ operating systems and hardware configurations. For TENEX
+ systems this could be implemented as the ability to do mapping
+ operations from the users virtual memory 'directly' onto the
+ network. In any case, this intelligent network device would
+ be required to handle the various protocols for the host.
+ Some changes may be required in the NCP protocols.
+
+ A way to reduce the cost of the RJS program (the one measured in
+ tables 1 and 2) would be to change the RJS-UCLA protocol. One
+ possible change is to allow hosts the option of using 32 bit bytes
+ (because it may be more efficient!) instead of the 8 bit bytes now
+ required by the protocol.
+
+ Basically, it is our belief, that, in order to make the network as
+ viable economically as was anticipated by the authors of
+ reference[4], much work is needed on host machines and network
+ protocols rather than on further refinements of the communication
+ devices involved.
+
+
+
+
+Hicks & Wessler [Page 3]
+
+RFC 392 Measurement for Transmitting Network Data September 1972
+
+
+References
+
+ 1. Hicks, Gregory, "Network Remote Job Entry Program--NETRJS",
+ Network Information Center #9632, RFC #325
+
+ 2. Braden, R.T., "Interim NETRJS Specifications", Network Information
+ Center #7133, RFC #189, July 5,1971
+
+ 3. Personal correspondence with R. S. Tomlinson of Bolt, Beranek &
+ Newman during the time period of 13-SEPT-71 to 19-SEPT-72.
+
+ 4. Roberts, L.G., and B.D. Wessler, "Computer Network Development to
+ achieve resource sharing", Spring Joint Computer Conference, May
+ 7,1970 pg 543-549.
+
+ 5. Personal correspondence with Bolt, Beranek & Newman
+
+ 6. Bressler, B., D. Murphy and D. Walden, "A proposed Experiment with
+ a Message Switching Protocol", Network Information Center #9926,
+ RFC #333, May 15,1972.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hicks & Wessler [Page 4]
+
+RFC 392 Measurement for Transmitting Network Data September 1972
+
+
+Utah-10 Accounting for Network Usage
+
+ for the period 16-SEP-72 12:48:34, ending 19-SEP-72 13:56:11
+
+ Clk Tim Cpu Tim # of Bytes Bits/sec us/bit Load
+
+ 14 11.61 18930 s 10152.175 76.67 3.74
+ 02:56 37.89 59066 r 2670.857 80.20 3.51
+ 02:18 22.71 35377 r 2038.682 80.24 2.98
+ 01:31 34.37 56608 s 4966.431 75.89 3.35
+ 13 11.57 19094 s 10985.401 75.72 4.07
+ 04:03 42.03 63067 r 2069.297 83.30 4.95
+ 03 1.82 2906 s 5932.126 78.37 5.58
+ 45 23.58 35505 r 6237.976 83.00 5.37
+ 09 2.08 3243 s 2804.757 80.21 3.60
+ 03:28 39.25 58632 r 2246.727 83.69 4.86
+ 05 4.60 7470 s 10192.734 76.99 1.12
+ 23 10.83 16525 r 5565.378 81.95 1.17
+ 06 4.32 7142 s 9116.962 75.64 1.44
+ 14 8.56 13223 r 7170.338 80.95 1.29
+ 11 4.42 7142 s 4795.300 77.43 1.89
+ 01:34 13.287 19562 r 1659.819 84.86 2.50
+ 37 10.35 16183 r 3439.807 79.97 3.02
+ 02:43 34.49 56444 s 2764.170 76.38 3.74
+ 38 10.51 16196 r 3400.467 81.13 0.69
+ 45 34.12 56280 s 9820.704 75.75 2.57
+ 03:46 36.09 56280 s 1990.601 80.16 4.06
+ 11 2.75 4085 r 2774.900 84.30 4.86
+ 15 2.88 4085 r 2154.252 88.07 4.86
+ 01:54 11.40 16125 r 1124.203 88.39 5.12
+ 01:14 35.10 56280 s 6057.068 77.96 6.10
+ 01:07 10.67 16125 r 1919.986 82.70 1.89
+ 04:28 36.32 56362 s 1679.377 80.56 5.52
+ 02:12 17.71 27120 r 1634.818 81.62 1.73
+ 06:59 41.88 64333 s 1226.980 81.37 6.66
+ 37 7.63 12082 r 2552.243 78.97 0.64
+
+Utah-10 Accounting for Network Usage
+
+ for the period 13-SEP-72 2:23:12, ending 16-SEP-72 11:47:07
+
+ Clk Tim Cpu Tim # of Bytes Bits/sec us/bit Load
+
+ 10 2.09 3079 s 2343.227 84.77 3.80
+ 11:09 138.20 204596 s 2444.733 84.43 3.68
+ 06:16 34.78 49994 r 1062.961 86.96 3.95
+ 01:57 16.25 24971 r 1693.451 81.34 2.92
+ 12:07 114.70 183598 s 2019.577 78.09 6.79
+
+
+
+Hicks & Wessler [Page 5]
+
+RFC 392 Measurement for Transmitting Network Data September 1972
+
+
+ 01:13 0.92 845 r 91.683 135.80 2.12
+ 05 5.07 7373 s 10842.647 85.99 1.93
+ 03:09 42.10 62414 r 2633.655 84.31 3.86
+ 13:22 115.13 183352 s 1828.467 78.49 0.58
+ 02 0.25 233 s 907.056 134.12 6.05
+ 07:10 44.23 64869 r 1206.001 85.23 5.07
+ 04 0.33 233 s 402.679 179.18 2.24
+ 11:47 114.48 183585 s 2076.187 77.95 2.73
+ 17:45 128.25 185908 r 1395.801 86.23 5.19
+ 09:34 45.97 67158 r 935.067 85.56 0.61
+ 09:23 113.50 183270 s 2600.852 77.41 9.64
+ 12:24 51.65 74916 r 804.656 86.18 9.28
+ 13:30 117.92 183352 s 1809.320 80.39 9.08
+ 19:23 56.42 89640 s 616.586 78.67 6.77
+ 11:49 11.29 16205 r 182.767 87.08 10.17
+ 09:05 34.35 50796 s 744.325 84.53 8.47
+ 21:12 56.17 76423 r 480.512 91.88 7.53
+ 01:00 15.33 23930 r 3156.628 80.08 3.11
+ 03:04 54.60 89731 s 3892.062 76.07 3.81
+ 06 2.62 4106 r 5071.484 79.88 3.77
+ 05:15 54.79 89731 s 2277.559 76.32 3.68
+ 03 2.02 3161 s 7778.530 79.92 2.17
+ 33 9.42 14680 r 3472.810 80.19 2.31
+ 00 0.22 219 s 2646.526 127.28 1.81
+ 19:57 295.16 473489 s 3162.399 77.92 1.85
+ 10 6.62 10025 r 7841.987 82.54 2.75
+ 01 0.23 221 s 1092.032 128.96 2.74
+ 16 6.45 10032 r 1888.591 80.36 2.79
+ 04 2.06 3243 s 6020.887 79.52 2.62
+ 01:28 31.29 48532 r 4382.419 80.60 2.62
+ 07:17 196.34 316072 s 5777.687 77.65 3.86
+ 01:46 30.14 45786 r 3434.229 82.29 3.26
+ 01:30 24.73 38405 r 3399.274 80.50 1.80
+ 02:10 23.46 35633 r 2190.508 82.31 2.61
+ 44 28.80 46897 s 8441.544 76.76 3.26
+ 04:51 192.20 316318 s 8671.027 75.95 3.10
+ 40 11.51 18511 s 3633.437 77.70 2.98
+ 12 7.17 10963 r 6894.427 81.76 3.04
+ 12 11.30 18511 s 11418.614 76.32 3.14
+ 14 7.12 11122 r 6298.740 80.03 3.24
+ 02 0.92 1412 s 5120.580 81.53 3.41
+ 14 7.23 11122 r 6184.042 81.24 3.20
+
+
+ [This RFC was put into machine readable form for entry]
+ [into the online RFC archives by Helene Morin, Viagenie, 12/99]
+
+
+
+
+
+Hicks & Wessler [Page 6]
+