diff options
Diffstat (limited to 'doc/rfc/rfc1030.txt')
| -rw-r--r-- | doc/rfc/rfc1030.txt | 893 |
1 files changed, 893 insertions, 0 deletions
diff --git a/doc/rfc/rfc1030.txt b/doc/rfc/rfc1030.txt new file mode 100644 index 0000000..80bfb49 --- /dev/null +++ b/doc/rfc/rfc1030.txt @@ -0,0 +1,893 @@ +Network Working Group M. Lambert +Request for Comments: 1030 M.I.T. Laboratory for Computer Science + November 1987 + + + On Testing the NETBLT Protocol over Divers Networks + + +STATUS OF THIS MEMO + + This RFC describes the results gathered from testing NETBLT over + three networks of differing bandwidths and round-trip delays. While + the results are not complete, the information gathered so far has + been very promising and supports RFC-998's assertion that that NETBLT + can provide very high throughput over networks with very different + characteristics. Distribution of this memo is unlimited. + +1. Introduction + + NETBLT (NETwork BLock Transfer) is a transport level protocol + intended for the rapid transfer of a large quantity of data between + computers. It provides a transfer that is reliable and flow + controlled, and is designed to provide maximum throughput over a wide + variety of networks. The NETBLT protocol is specified in RFC-998; + this document assumes an understanding of the specification as + described in RFC-998. + + Tests over three different networks are described in this document. + The first network, a 10 megabit-per-second Proteon Token Ring, served + as a "reference environment" to determine NETBLT's best possible + performance. The second network, a 10 megabit-per-second Ethernet, + served as an access path to the third network, the 3 megabit-per- + second Wideband satellite network. Determining NETBLT's performance + over the Ethernet allowed us to account for Ethernet-caused behaviour + in NETBLT transfers that used the Wideband network. Test results for + each network are described in separate sections. The final section + presents some conclusions and further directions of research. The + document's appendices list test results in detail. + +2. Acknowledgements + + Many thanks are due Bob Braden, Stephen Casner, and Annette DeSchon + of ISI for the time they spent analyzing and commenting on test + results gathered at the ISI end of the NETBLT Wideband network tests. + Bob Braden was also responsible for porting the IBM PC/AT NETBLT + implementation to a SUN-3 workstation running UNIX. Thanks are also + due Mike Brescia, Steven Storch, Claudio Topolcic and others at BBN + who provided much useful information about the Wideband network, and + + + +M. Lambert [Page 1] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + helped monitor it during testing. + +3. Implementations and Test Programs + + This section briefly describes the NETBLT implementations and test + programs used in the testing. Currently, NETBLT runs on three + machine types: Symbolics LISP machines, IBM PC/ATs, and SUN-3s. The + test results described in this paper were gathered using the IBM + PC/AT and SUN-3 NETBLT implementations. The IBM and SUN + implementations are very similar; most differences lie in timer and + multi-tasking library implementations. The SUN NETBLT implementation + uses UNIX's user-accessible raw IP socket; it is not implemented in + the UNIX kernel. + + The test application performs a simple memory-to-memory transfer of + an arbitrary amount of data. All data are actually allocated by the + application, given to the protocol layer, and copied into NETBLT + packets. The results are therefore fairly realistic and, with + appropriately large amounts of buffering, could be attained by disk- + based applications as well. + + The test application provides several parameters that can be varied + to alter NETBLT's performance characteristics. The most important of + these parameters are: + + + burst interval The number of milliseconds from the start of one + burst transmission to the start of the next burst + transmission. + + + burst size The number of packets transmitted per burst. + + + buffer size The number of bytes in a NETBLT buffer (all + buffers must be the same size, save the last, + which can be any size required to complete the + transfer). + + + data packet size + The number of bytes contained in a NETBLT DATA + packet's data segment. + + + number of outstanding buffers + The number of buffers which can be in + transmission/error recovery at any given moment. + + + +M. Lambert [Page 2] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + The protocol's throughput is measured in two ways. First, the "real + throughput" is throughput as viewed by the user: the number of bits + transferred divided by the time from program start to program finish. + Although this is a useful measurement from the user's point of view, + another throughput measurement is more useful for analyzing NETBLT's + performance. The "steady-state throughput" is the rate at which data + is transmitted as the transfer size approaches infinity. It does not + take into account connection setup time, and (more importantly), does + not take into account the time spent recovering from packet-loss + errors that occur after the last buffer in the transmission is sent + out. For NETBLT transfers using networks with long round-trip delays + (and consequently with large numbers of outstanding buffers), this + "late" recovery phase can add large amounts of time to the + transmission, time which does not reflect NETBLT's peak transmission + rate. The throughputs listed in the test cases that follow are all + steady-state throughputs. + +4. Implementation Performance + + This section describes the theoretical performance of the IBM PC/AT + NETBLT implementation on both the transmitting and receiving sides. + Theoretical performance was measured on two LANs: a 10 megabit-per- + second Proteon Token Ring and a 10 megabit-per-second Ethernet. + "Theoretical performance" is defined to be the performance achieved + if the sending NETBLT did nothing but transmit data packets, and the + receiving NETBLT did nothing but receive data packets. + + Measuring the send-side's theoretical performance is fairly easy, + since the sending NETBLT does very little more than transmit packets + at a predetermined rate. There are few, if any, factors which can + influence the processing speed one way or another. + + Using a Proteon P1300 interface on a Proteon Token Ring, the IBM + PC/AT NETBLT implementation can copy a maximum-sized packet (1990 + bytes excluding protocol headers) from NETBLT buffer to NETBLT data + packet, format the packet header, and transmit the packet onto the + network in about 8 milliseconds. This translates to a maximum + theoretical throughput of 1.99 megabits per second. + + Using a 3COM 3C500 interface on an Ethernet LAN, the same + implementation can transmit a maximum-sized packet (1438 bytes + excluding protocol headers) in 6.0 milliseconds, for a maximum + theoretical throughput of 1.92 megabits per second. + + Measuring the receive-side's theoretical performance is more + difficult. Since all timer management and message ACK overhead is + incurred at the receiving NETBLT's end, the processing speed can be + slightly slower than the sending NETBLT's processing speed (this does + + + +M. Lambert [Page 3] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + not even take into account the demultiplexing overhead that the + receiver incurs while matching packets with protocol handling + functions and connections). In fact, the amount by which the two + processing speeds differ is dependent on several factors, the most + important of which are: length of the NETBLT buffer list, the number + of data timers which may need to be set, and the number of control + messages which are ACKed by the data packet. Almost all of this + added overhead is directly related to the number of outstanding + buffers allowable during the transfer. The fewer the number of + outstanding buffers, the shorter the NETBLT buffer list, and the + faster a scan through the buffer list and the shorter the list of + unacknowledged control messages. + + Assuming a single-outstanding-buffer transfer, the receiving-side + NETBLT can DMA a maximum-sized data packet from the Proteon Token + Ring into its network interface, copy it from the interface into a + packet buffer and finally copy the packet into the correct NETBLT + buffer in 8 milliseconds: the same speed as the sender of data. + + Under the same conditions, the implementation can receive a maximum- + sized packet from the Ethernet in 6.1 milliseconds, for a maximum + theoretical throughput of 1.89 megabits per second. + +5. Testing on a Proteon Token Ring + + The Proteon Token Ring used for testing is a 10 megabit-per-second + LAN supporting about 40 hosts. The machines on either end of the + transfer were IBM PC/ATs using Proteon P1300 network interfaces. The + Token Ring provides high bandwidth with low round-trip delay and + negligible packet loss, a good debugging environment in situations + where packet loss, packet reordering, and long round-trip time would + hinder debugging. Also contributing to high performance is the large + (maximum 2046 bytes) network MTU. The larger packets take somewhat + longer to transmit than do smaller packets (8 milliseconds per 2046 + byte packet versus 6 milliseconds per 1500 byte packet), but the + lessened per-byte computational overhead increases throughput + somewhat. + + The fastest single-outstanding-buffer transmission rate was 1.49 + megabits per second, and was achieved using a test case with the + following parameters: + + + + + + + + + + +M. Lambert [Page 4] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + transfer size 2-5 million bytes + + + data packet size + 1990 bytes + + + buffer size 19900 bytes + + + burst size 5 packets + + + burst interval 40 milliseconds. The timer code on the IBM PC/AT + is accurate to within 1 millisecond, so a 40 + millisecond burst can be timed very accurately. + + Allowing only one outstanding buffer reduced the protocol to running + "lock-step" (the receiver of data sends a GO, the sender sends data, + the receiver sends an OK, followed by a GO for the next buffer). + Since the lock-step test incurred one round-trip-delay's worth of + overhead per buffer (between transmission of a buffer's last data + packet and receipt of an OK for that buffer/GO for the next buffer), + a test with two outstanding buffers (providing essentially constant + packet transmission) should have resulted in higher throughput. + + A second test, this time with two outstanding buffers, was performed, + with the above parameters identical save for an increased burst + interval of 43 milliseconds. The highest throughput recorded was + 1.75 megabits per second. This represents 95% efficiency (5 1990- + byte packets every 43 milliseconds gives a maximum theoretical + throughput of 1.85 megabits per second). The increase in throughput + over a single-outstanding-buffer transmission occurs because, with + two outstanding buffers, there is no round-trip-delay lag between + buffer transmissions and the sending NETBLT can transmit constantly. + Because the P1300 interface can transmit and receive concurrently, no + packets were dropped due to collision on the interface. + + As mentioned previously, the minimum transmission time for a + maximum-sized packet on the Proteon Ring is 8 milliseconds. One + would expect, therefore, that the maximum throughput for a double- + buffered transmission would occur with a burst interval of 8 + milliseconds times 5 packets per burst, or 40 milliseconds. This + would allow the sender of data to transmit bursts with no "dead time" + in between bursts. Unfortunately, the sender of data must take time + to process incoming control messages, which typically forces a 2-3 + millisecond gap between bursts, lowering the throughput. With a + burst interval of 43 milliseconds, the incoming packets are processed + + + +M. Lambert [Page 5] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + during the 3 millisecond-per-burst "dead time", making the protocol + more efficient. + +6. Testing on an Ethernet + + The network used in performing this series of tests was a 10 megabit + per second Ethernet supporting about 150 hosts. The machines at + either end of the NETBLT connection were IBM PC/ATs using 3COM 3C500 + network interfaces. As with the Proteon Token Ring, the Ethernet + provides high bandwidth with low delay. Unfortunately, the + particular Ethernet used for testing (MIT's infamous Subnet 26) is + known for being somewhat noisy. In addition, the 3COM 3C500 Ethernet + interfaces are relatively unsophisticated, with only a single + hardware packet buffer for both transmitting and receiving packets. + This gives the interface an annoying tendency to drop packets under + heavy load. The combination of these factors made protocol + performance analysis somewhat more difficult than on the Proteon + Ring. + + The fastest single-buffer transmission rate was 1.45 megabits per + second, and was achieved using a test case with the following + parameters: + + transfer size 2-5 million bytes + + + data packet size + 1438 bytes (maximum size excluding protocol + headers). + + + buffer size 14380 bytes + + + burst size 5 packets + + + burst interval 30 milliseconds (6.0 milliseconds x 5 packets). + + A second test, this one with parameters identical to the first save + for number of outstanding buffers (2 instead of 1) resulted in + substantially lower throughput (994 kilobits per second), with a + large number of packets retransmitted (10%). The retransmissions + occurred because the 3COM 3C500 network interface has only one + hardware packet buffer and cannot hold a transmitting and receiving + packet at the same time. With two outstanding buffers, the sender of + data can transmit constantly; this means that when the receiver of + data attempts to send a packet, its interface's receive hardware goes + + + +M. Lambert [Page 6] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + deaf to the network and any packets being transmitted at the time by + the sender of data are lost. A symmetrical problem occurs with + control messages sent from receiver of data to sender of data, but + the number of control messages sent is small enough and the + retransmission algorithm redundant enough that little performance + degradation occurs due to control message loss. + + When the burst interval was lengthened from 30 milliseconds per 5 + packet burst to 45 milliseconds per 5 packet burst, a third as many + packets were dropped, and throughput climbed accordingly, to 1.12 + megabits per second. Presumably, the longer burst interval allowed + more dead time between bursts and less likelihood of the receiver of + data's interface being deaf to the net while the sender of data was + sending a packet. An interesting note is that, when the same test + was conducted on a special Ethernet LAN with the only two hosts + attached being the two NETBLT machines, no packets were dropped once + the burst interval rose above 40 milliseconds/5 packet burst. The + improved performance was doubtless due to the absence of extra + network traffic. + +7. Testing on the Wideband Network + + The following section describes results gathered using the Wideband + network. The Wideband network is a satellite-based network with ten + stations competing for a raw satellite channel bandwidth of 3 + megabits per second. Since the various tests resulted in substantial + changes to the NETBLT specification and implementation, some of the + major changes are described along with the results and problems that + forced those changes. + + The Wideband network has several characteristics that make it an + excellent environment for testing NETBLT. First, it has an extremely + long round-trip delay (1.8 seconds). This provides a good test of + NETBLT's rate control and multiple-buffering capabilities. NETBLT's + rate control allows the packet transmission rate to be regulated + independently of the maximum allowable amount of outstanding data, + providing flow control as well as very large "windows". NETBLT's + multiple-buffering capability enables data to still be transmitted + while earlier data are awaiting retransmission and subsequent data + are being prepared for transmission. On a network with a long + round-trip delay, the alternative "lock-step" approach would require + a 1.8 second gap between each buffer transmission, degrading + performance. + + Another interesting characteristic of the Wideband network is its + throughput. Although its raw bandwidth is 3 megabits per second, at + the time of these tests fully 2/3 of that was consumed by low-level + network overhead and hardware limitations. (A detailed analysis of + + + +M. Lambert [Page 7] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + the overhead appears at the end of this document.) This reduces the + available bandwidth to just over 1 megabit per second. Since the + NETBLT implementation can run substantially faster than that, testing + over the Wideband net allows us to measure NETBLT's ability to + utilize very high percentages of available bandwidth. + + Finally, the Wideband net has some interesting packet reorder and + delay characteristics that provide a good test of NETBLT's ability to + deal with these problems. + + Testing progressed in several phases. The first phase involved using + source-routed packets in a path from an IBM PC/AT on MIT's Subnet 26, + through a BBN Butterfly Gateway, over a T1 link to BBN, onto the + Wideband network, back down into a BBN Voice Funnel, and onto ISI's + Ethernet to another IBM PC/AT. Testing proceeded fairly slowly, due + to gateway software and source-routing bugs. Once a connection was + finally established, we recorded a best throughput of approximately + 90K bits per second. + + Several problems contributed to the low throughput. First, the + gateways at either end were forwarding packets onto their respective + LANs faster than the IBM PC/AT's could accept them (the 3COM 3C500 + interface would not have time to re-enable input before another + packet would arrive from the gateway). Even with bursts of size 1, + spaced 6 milliseconds apart, the gateways would aggregate groups of + packets coming from the same satellite frame, and send them faster + than the PC could receive them. The obvious result was many dropped + packets, and degraded performance. Also, the half-duplex nature of + the 3COM interface caused incoming packets to be dropped when packets + were being sent. + + The number of packets dropped on the sending NETBLT side due to the + long interface re-enable time was reduced by packing as many control + messages as possible into a single control packet (rather than + placing only one message in a control packet). This reduced the + number of control packets transmitted to one per buffer transmission, + which the PC was able to handle. In particular, messages of the form + OK(n) were combined with messages of the form GO(n + 1), in order to + prevent two control packets from arriving too close together to both + be received. + + Performance degradation from dropped control packets was also + minimized by changing to a highly redundant control packet + transmission algorithm. Control messages are now stored in a single + long-lived packet, with ACKed messages continuously bumped off the + head of the packet and new messages added at the tail of the packet. + Every time a new message needs to be transmitted, any unACKed old + messages are transmitted as well. The sending NETBLT, which receives + + + +M. Lambert [Page 8] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + these control messages, is tuned to ignore duplicate messages with + almost no overhead. This transmission redundancy puts little + reliance on the NETBLT control timer, further reducing performance + degradation from lost control packets. + + Although the effect of dropped packets on the receiving NETBLT could + not be completely eliminated, it was reduced somewhat by some changes + to the implementation. Data packets from the sending NETBLT are + guaranteed to be transmitted by buffer number, lowest number first. + In some cases, this allowed the receiving NETBLT to make retransmit- + request decisions for a buffer N, if packets for N were expected but + none were received at the time packets for a buffer N+M were + received. This optimization was somewhat complicated, but improved + NETBLT's performance in the face of missing packets. Unfortunately, + the dropped-packet problem remained until the NETBLT implementation + was ported to a SUN-3 workstation. The SUN is able to handle the + incoming packets quite well, dropping only 0.5% of the data packets + (as opposed to the PC's 15 - 20%). + + Another problem with the Wideband network was its tendency to re- + order and delay packets. Dealing with these problems required + several changes in the implementation. Previously, the NETBLT + implementation was "optimized" to generate retransmit requests as + soon as possible, if possible not relying on expiration of a data + timer. For instance, when the receiving NETBLT received an LDATA + packet for a buffer N, and other packets in buffer N had not arrived, + the receiver would immediately generate a RESEND for the missing + packets. Similarly, under certain circumstances, the receiver would + generate a RESEND for a buffer N if packets for N were expected and + had not arrived before packets for a buffer N+M. Obviously, packet- + reordering made these "optimizations" generate retransmit requests + unnecessarily. In the first case, the implementation was changed to + no longer generate a retransmit request on receipt of an LDATA with + other packets missing in the buffer. In the second case, a data + timer was set with an updated (and presumably more accurate) value, + hopefully allowing any re-ordered packets to arrive before timing out + and generating a retransmit request. + + It is difficult to accommodate Wideband network packet delay in the + NETBLT implementation. Packet delays tend to occur in multiples of + 600 milliseconds, due to the Wideband network's datagram reservation + scheme. A timer value calculation algorithm that used a fixed + variance on the order of 600 milliseconds would cause performance + degradation when packets were lost. On the other hand, short fixed + variance values would not react well to the long delays possible on + the Wideband net. Our solution has been to use an adaptive data + timer value calculation algorithm. The algorithm maintains an + average inter-packet arrival value, and uses that to determine the + + + +M. Lambert [Page 9] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + data timer value. If the inter-packet arrival time increases, the + data timer value will lengthen. + + At this point, testing proceeded between NETBLT implementations on a + SUN-3 workstation and an IBM PC/AT. The arrival of a Butterfly + Gateway at ISI eliminated the need for source-routed packets; some + performance improvement was also expected because the Butterfly + Gateway is optimized for IP datagram traffic. + + In order to put the best Wideband network test results in context, a + short analysis follows, showing the best throughput expected on a + fully loaded channel. Again, a detailed analysis of the numbers that + follow appears at the end of this document. + + The best possible datagram rate over the current Wideband + configuration is 24,054 bits per channel frame, or 3006 bytes every + 21.22 milliseconds. Since the transmission route begins and ends on + an Ethernet, the largest amount of data transmissible (after + accounting for packet header overhead) is 1438 bytes per packet. + This translates to approximately 2 packets per frame. Since we want + to avoid overflowing the channel, we should transmit slightly slower + than the channel frame rate of 21.2 milliseconds. We therefore came + up with a best possible throughput of 2 1438-byte packets every 22 + milliseconds, or 1.05 megabits per second. + + Because of possible software bugs in either the Butterfly Gateway or + the BSAT (gateway-to-earth-station interface), 1438-byte packets were + fragmented before transmission over the Wideband network, causing + packet delay and poor performance. The best throughput was achieved + with the following values: + + transfer size 500,000 - 750,000 bytes + + + data packet size + 1432 bytes + + + buffer size 14320 bytes + + + burst size 5 packets + + + burst interval 55 milliseconds + + Steady-state throughputs ranged from 926 kilobits per second to 942 + kilobits per second, approximately 90% channel utilization. The + + + +M. Lambert [Page 10] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + amount of data transmitted should have been an order of magnitude + higher, in order to get a longer steady-state period; unfortunately + at the time we were testing, the Ethernet interface of ISI's + Butterfly Gateway would lock up fairly quickly (in 40-60 seconds) at + packet rates of approximately 90 per second, forcing a gateway reset. + Transmissions therefore had to take less than this amount of time. + This problem has reportedly been fixed since the tests were + conducted. + + In order to test the Wideband network under overload conditions, we + attempted several tests at rates of 5 1432-byte packets every 50 + milliseconds. At this rate, the Wideband network ground to a halt as + four of the ten network BSATs immediately crashed and reset their + channel processor nodes. Apparently, the BSATs crash because the ESI + (Earth Station Interface), which sends data from the BSAT to the + satellite, stops its transmit clock to the BSAT if it runs out of + buffer space. The BIO interface connecting BSAT and ESI does not + tolerate this clock-stopping, and typically locks up, forcing the + channel processor node to reset. A more sophisticated interface, + allowing faster transmissions, is being installed in the near future. + +8. Future Directions + + Some more testing needs to be performed over the Wideband Network in + order to get a complete analysis of NETBLT's performance. Once the + Butterfly Gateway Ethernet interface lockup problem described earlier + has been fixed, we want to perform transmissions of 10 to 50 million + bytes to get accurate steady-state throughput results. We also want + to run several NETBLT processes in parallel, each tuned to take a + fraction of the Wideband Network's available bandwidth. Hopefully, + this will demonstrate whether or not burst synchronization across + different NETBLT processes will cause network congestion or failure. + Once the BIO BSAT-ESI interface is upgraded, we will want to try for + higher throughputs, as well as greater hardware stability under + overload conditions. + + As far as future directions of research into NETBLT, one important + area needs to be explored. A series of algorithms need to be + developed to allow dynamic selection and control of NETBLT's + transmission parameters (burst size, burst interval, and number of + outstanding buffers). Ideally, this dynamic control will not require + any information from outside sources such as gateways; instead, + NETBLT processes will use end-to-end information in order to make + transmission rate decisions in the face of noisy channels and network + congestion. Some research on dynamic rate control is taking place + now, but much more work needs done before the results can be + integrated into NETBLT. + + + + +M. Lambert [Page 11] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + +I. Wideband Bandwidth Analysis + + Although the raw bandwidth of the Wideband Network is 3 megabits per + second, currently only about 1 megabit per second of it is available + to transmit data. The large amount of overhead is due to the channel + control strategy (which uses a fixed-width control subframe based on + the maximum number of stations sharing the channel) and the low- + performance BIO interface between BBN's BSAT (Butterfly Satellite + Interface) and Linkabit's ESI (Earth Station Interface). Higher- + performance BSMI interfaces are soon to be installed in all Wideband + sites, which should improve the amount of available bandwidth. + + Bandwidth on the Wideband network is divided up into frames, each of + which has multiple subframes. A frame is 32768 channel symbols, at 2 + bits per symbol. One frame is available for transmission every 21.22 + milliseconds, giving a raw bandwidth of 65536 bits / 21.22 ms, or + 3.081 megabits per second. + + Each frame contains two subframes, a control subframe and a data + subframe. The control subframe is subdivided into ten slots, one per + earth station. Control information takes up 200 symbols per station. + Because the communications interface between BSAT and ESI only runs + at 2 megabits per second, there must be a padding interval of 1263 + symbols between each slot of information, bringing the total control + subframe size up to 1463 symbols x 10 stations, or 14630 symbols. + The data subframe then has 18138 symbols available. The maximum + datagram size is currently expressed as a 14-bit quantity, further + dropping the maximum amount of data in a frame to 16384 symbols. + After header information is taken into account, this value drops to + 16,036 symbols. At 2 bits per symbol, using a 3/4 coding rate, the + actual amount of usable data in a frame is 24,054 bits, or + approximately 3006 bytes. Thus the theoretical usable bandwidth is + 24,054 bits every 21.22 milliseconds, or 1.13 megabits per second. + Since the NETBLT implementations are running on Ethernet LANs + gatewayed to the Wideband network, the 3006 bytes per channel frame + of usable bandwidth translates to two maximum-sized (1500 bytes) + Ethernet packets per channel frame, or 1.045 megabits per second. + + + + + + + + + + + + + + +M. Lambert [Page 12] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + +II. Detailed Proteon Ring LAN Test Results + + Following is a table of some of the test results gathered from + testing NETBLT between two IBM PC/ATs on a Proteon Token Ring LAN. + The table headers have the following definitions: + + + BS/BI burst size in packets and burst interval in + milliseconds + + + PSZ number of bytes in DATA/LDATA packet data segment + + + BFSZ number of bytes in NETBLT buffer + + + XFSZ number of kilobytes in transfer + + + NBUFS number of outstanding buffers + + + #LOSS number of data packets lost + + + #RXM number of data packets retransmitted + + + DTMOS number of data timeouts on receiving end + + + SPEED steady-state throughput in megabits per second + + + + + + + + + + + + + + + + + + +M. Lambert [Page 13] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + + BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM DTMOS SPEED + + 5/25 1438 14380 1438 1 0 0 0 1.45 + 5/25 1438 14380 1438 1 0 0 0 1.45 + 5/30 1438 14380 1438 1 0 0 0 1.45 + 5/30 1438 14380 1438 1 0 0 0 1.45 + 5/35 1438 14380 1438 1 0 0 0 1.40 + 5/35 1438 14380 1438 1 0 0 0 1.41 + 5/40 1438 14380 1438 1 0 0 0 1.33 + 5/40 1438 14380 1438 1 0 0 0 1.33 + + 5/25 1438 14380 1438 2 0 0 0 1.62 + + 5/25 1438 14380 1438 2 0 0 0 1.61 + 5/30 1438 14380 1438 2 0 0 0 1.60 + 5/30 1438 14380 1438 2 0 0 0 1.61 + 5/34 1438 14380 1438 2 0 0 0 1.59 + 5/35 1438 14380 1438 2 0 0 0 1.58 + + 5/25 1990 19900 1990 1 0 0 0 1.48 + 5/25 1990 19900 1990 1 0 0 0 1.49 + 5/30 1990 19900 1990 1 0 0 0 1.48 + 5/30 1990 19900 1990 1 0 0 0 1.48 + 5/35 1990 19900 1990 1 0 0 0 1.49 + 5/35 1990 19900 1990 1 0 0 0 1.48 + 5/40 1990 19900 1990 1 0 0 0 1.49 + 5/40 1990 19900 1990 1 0 0 0 1.49 + 5/45 1990 19900 1990 1 0 0 0 1.45 + 5/45 1990 19900 1990 1 0 0 0 1.46 + + 5/25 1990 19900 1990 2 0 0 0 1.75 + 5/25 1990 19900 1990 2 0 0 0 1.75 + 5/30 1990 19900 1990 2 0 0 0 1.74 + 5/30 1990 19900 1990 2 0 0 0 1.75 + 5/35 1990 19900 1990 2 0 0 0 1.74 + 5/35 1990 19900 1990 2 0 0 0 1.74 + 5/40 1990 19900 1990 2 0 0 0 1.75 + 5/40 1990 19900 1990 2 0 0 0 1.74 + 5/43 1990 19900 1990 2 0 0 0 1.75 + 5/43 1990 19900 1990 2 0 0 0 1.74 + 5/43 1990 19900 1990 2 0 0 0 1.75 + 5/44 1990 19900 1990 2 0 0 0 1.73 + 5/44 1990 19900 1990 2 0 0 0 1.72 + 5/45 1990 19900 1990 2 0 0 0 1.70 + 5/45 1990 19900 1990 2 0 0 0 1.72 + + + + + + +M. Lambert [Page 14] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + +III. Detailed Ethernet LAN Testing Results + + Following is a table of some of the test results gathered from + testing NETBLT between two IBM PC/ATs on an Ethernet LAN. See + previous appendix for table header definitions. + + + BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM DTMOS SPEED + + 5/30 1438 14380 1438 1 9 9 6 1.42 + 5/30 1438 14380 1438 1 2 2 2 1.45 + 5/30 1438 14380 1438 1 5 5 4 1.44 + 5/35 1438 14380 1438 1 7 7 7 1.38 + 5/35 1438 14380 1438 1 6 6 5 1.38 + 5/40 1438 14380 1438 1 48 48 44 1.15 + 5/40 1438 14380 1438 1 50 50 38 1.17 + 5/40 1438 14380 1438 1 13 13 11 1.28 + 5/40 1438 14380 1438 1 7 7 5 1.30 + + 5/30 1438 14380 1438 2 206 206 198 0.995 + 5/30 1438 14380 1438 2 213 213 198 0.994 + 5/40 1438 14380 1438 2 117 121 129 1.05 + 5/40 1438 14380 1438 2 178 181 166 0.892 + 5/40 1438 14380 1438 2 135 138 130 1.03 + 5/45 1438 14380 1438 2 57 57 52 1.12 + 5/45 1438 14380 1438 2 97 97 99 1.02 + 5/45 1438 14380 1438 2 62 62 51 1.09 + + 5/15 512 10240 2048 1 6 6 4 0.909 + 5/15 512 10240 2048 1 10 11 7 0.907 + 5/18 512 10240 2048 1 11 11 8 0.891 + 5/18 512 10240 2048 1 5 5 9 0.906 + 5/19 512 10240 2048 1 3 3 3 0.905 + 5/19 512 10240 2048 1 8 8 7 0.898 + 5/20 512 10240 2048 1 7 7 4 0.876 + 5/20 512 10240 2048 1 11 12 5 0.871 + 5/20 512 10240 2048 1 8 9 5 0.874 + 5/30 512 10240 2048 2 113 116 84 0.599 + 5/30 512 10240 2048 2 20 20 14 0.661 + 5/30 512 10240 2048 2 49 50 40 0.638 + + + + + + + + + + + +M. Lambert [Page 15] + +RFC 1030 Testing the NETBLT Protocol November 1987 + + +IV. Detailed Wideband Network Testing Results + + Following is a table of some of the test results gathered from + testing NETBLT between an IBM PC/AT and a SUN-3 using the Wideband + satellite network. See previous appendix for table header + definitions. + + BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM SPEED + + 5/90 1400 14000 500 22 9 10 0.584 + 5/90 1400 14000 500 22 12 12 0.576 + 5/90 1400 14000 500 22 3 3 0.591 + 5/90 1420 14200 500 22 12 12 0.591 + 5/90 1420 14200 500 22 6 6 0.600 + 5/90 1430 14300 500 22 9 10 0.600 + 5/90 1430 14300 500 22 15 15 0.591 + 5/90 1430 14300 500 22 12 12 0.590 + 5/90 1432 14320 716 22 13 16 0.591 + 5/90 1434 14340 717 22 33 147 0.483 + 5/90 1436 14360 718 22 25 122 0.500 + 5/90 1436 14360 718 22 25 109 0.512 + 5/90 1436 14360 718 22 28 153 0.476 + 5/90 1438 14380 719 22 6 109 0.533 + + 5/80 1432 14320 716 22 56 68 0.673 + 5/80 1432 14320 716 22 14 14 0.666 + 5/80 1432 14320 716 22 15 16 0.661 + 5/60 1432 14320 716 22 19 22 0.856 + 5/60 1432 14320 716 22 84 95 0.699 + 5/60 1432 14320 716 22 18 21 0.871 + 5/60 1432 14320 716 30 38 40 0.837 + 5/60 1432 14320 716 30 25 26 0.869 + 5/55 1432 14320 716 22 13 13 0.935 + 5/55 1432 14320 716 22 25 25 0.926 + 5/55 1432 14320 716 22 25 25 0.926 + 5/55 1432 14320 716 22 20 20 0.932 + 5/55 1432 14320 716 22 17 19 0.934 + 5/55 1432 14320 716 22 13 14 0.942 + + + + + + + + + + + + + +M. Lambert [Page 16] + |