As per Relevance of the word throughput, we have this rfc below:
Network Working Group M.
Request for Comments: 1030 M.I.T. Laboratory for Computer
November 1987
On Testing the NETBLT Protocol over Divers
STATUS OF THIS
This RFC describes the results gathered from testing NETBLT
three networks of differing bandwidths and round-trip delays.
the results are not complete, the information gathered so far
been very promising and supports RFC-998's assertion that that
can provide very high throughput over networks with very
characteristics. Distribution of this memo is unlimited
1.
NETBLT (NETwork BLock Transfer) is a transport level
intended for the rapid transfer of a large quantity of data
computers. It provides a transfer that is reliable and
controlled, and is designed to provide maximum throughput over a
variety of networks. The NETBLT protocol is specified in RFC-998;
this document assumes an understanding of the specification
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,
as a "reference environment" to determine NETBLT's best
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
over the Ethernet allowed us to account for Ethernet-caused
in NETBLT transfers that used the Wideband network. Test results
each network are described in separate sections. The final
presents some conclusions and further directions of research.
document's appendices list test results in detail
2.
Many thanks are due Bob Braden, Stephen Casner, and Annette
of ISI for the time they spent analyzing and commenting on
results gathered at the ISI end of the NETBLT Wideband network tests
Bob Braden was also responsible for porting the IBM PC/AT
implementation to a SUN-3 workstation running UNIX. Thanks are
due Mike Brescia, Steven Storch, Claudio Topolcic and others at
who provided much useful information about the Wideband network,
M. Lambert [Page 1]
RFC 1030 Testing the NETBLT Protocol November 1987
helped monitor it during testing
3. Implementations and Test
This section briefly describes the NETBLT implementations and
programs used in the testing. Currently, NETBLT runs on
machine types: Symbolics LISP machines, IBM PC/ATs, and SUN-3s.
test results described in this paper were gathered using the
PC/AT and SUN-3 NETBLT implementations. The IBM and
implementations are very similar; most differences lie in timer
multi-tasking library implementations. The SUN NETBLT
uses UNIX's user-accessible raw IP socket; it is not implemented
the UNIX kernel
The test application performs a simple memory-to-memory transfer
an arbitrary amount of data. All data are actually allocated by
application, given to the protocol layer, and copied into
packets. The results are therefore fairly realistic and,
appropriately large amounts of buffering, could be attained by disk
based applications as well
The test application provides several parameters that can be
to alter NETBLT's performance characteristics. The most important
these parameters are
burst interval The number of milliseconds from the start of
burst transmission to the start of the next
transmission
burst size The number of packets transmitted per burst
buffer size The number of bytes in a NETBLT buffer (
buffers must be the same size, save the last
which can be any size required to complete
transfer).
data packet
The number of bytes contained in a NETBLT
packet's data segment
number of outstanding
The number of buffers which can be
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 "
throughput" is throughput as viewed by the user: the number of
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'
performance. The "steady-state throughput" is the rate at which
is transmitted as the transfer size approaches infinity. It does
take into account connection setup time, and (more importantly),
not take into account the time spent recovering from packet-
errors that occur after the last buffer in the transmission is
out. For NETBLT transfers using networks with long round-trip
(and consequently with large numbers of outstanding buffers),
"late" recovery phase can add large amounts of time to
transmission, time which does not reflect NETBLT's peak
rate. The throughputs listed in the test cases that follow are
steady-state throughputs
4. Implementation
This section describes the theoretical performance of the IBM PC/
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
if the sending NETBLT did nothing but transmit data packets, and
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
at a predetermined rate. There are few, if any, factors which
influence the processing speed one way or another
Using a Proteon P1300 interface on a Proteon Token Ring, the
PC/AT NETBLT implementation can copy a maximum-sized packet (1990
bytes excluding protocol headers) from NETBLT buffer to NETBLT
packet, format the packet header, and transmit the packet onto
network in about 8 milliseconds. This translates to a
theoretical throughput of 1.99 megabits per second
Using a 3COM 3C500 interface on an Ethernet LAN, the
implementation can transmit a maximum-sized packet (1438
excluding protocol headers) in 6.0 milliseconds, for a
theoretical throughput of 1.92 megabits per second
Measuring the receive-side's theoretical performance is
difficult. Since all timer management and message ACK overhead
incurred at the receiving NETBLT's end, the processing speed can
slightly slower than the sending NETBLT's processing speed (this
M. Lambert [Page 3]
RFC 1030 Testing the NETBLT Protocol November 1987
not even take into account the demultiplexing overhead that
receiver incurs while matching packets with protocol
functions and connections). In fact, the amount by which the
processing speeds differ is dependent on several factors, the
important of which are: length of the NETBLT buffer list, the
of data timers which may need to be set, and the number of
messages which are ACKed by the data packet. Almost all of
added overhead is directly related to the number of
buffers allowable during the transfer. The fewer the number
outstanding buffers, the shorter the NETBLT buffer list, and
faster a scan through the buffer list and the shorter the list
unacknowledged control messages
Assuming a single-outstanding-buffer transfer, the receiving-
NETBLT can DMA a maximum-sized data packet from the Proteon
Ring into its network interface, copy it from the interface into
packet buffer and finally copy the packet into the correct
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
theoretical throughput of 1.89 megabits per second
5. Testing on a Proteon Token
The Proteon Token Ring used for testing is a 10 megabit-per-
LAN supporting about 40 hosts. The machines on either end of
transfer were IBM PC/ATs using Proteon P1300 network interfaces.
Token Ring provides high bandwidth with low round-trip delay
negligible packet loss, a good debugging environment in
where packet loss, packet reordering, and long round-trip time
hinder debugging. Also contributing to high performance is the
(maximum 2046 bytes) network MTU. The larger packets take
longer to transmit than do smaller packets (8 milliseconds per 2046
byte packet versus 6 milliseconds per 1500 byte packet), but
lessened per-byte computational overhead increases
somewhat
The fastest single-outstanding-buffer transmission rate was 1.49
megabits per second, and was achieved using a test case with
following parameters
M. Lambert [Page 4]
RFC 1030 Testing the NETBLT Protocol November 1987
transfer size 2-5 million
data packet
1990
buffer size 19900
burst size 5
burst interval 40 milliseconds. The timer code on the IBM PC/
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
"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
overhead per buffer (between transmission of a buffer's last
packet and receipt of an OK for that buffer/GO for the next buffer),
a test with two outstanding buffers (providing essentially
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
interval of 43 milliseconds. The highest throughput recorded
1.75 megabits per second. This represents 95% efficiency (5 1990-
byte packets every 43 milliseconds gives a maximum
throughput of 1.85 megabits per second). The increase in
over a single-outstanding-buffer transmission occurs because,
two outstanding buffers, there is no round-trip-delay lag
buffer transmissions and the sending NETBLT can transmit constantly
Because the P1300 interface can transmit and receive concurrently,
packets were dropped due to collision on the interface
As mentioned previously, the minimum transmission time for
maximum-sized packet on the Proteon Ring is 8 milliseconds.
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.
would allow the sender of data to transmit bursts with no "dead time
in between bursts. Unfortunately, the sender of data must take
to process incoming control messages, which typically forces a 2-3
millisecond gap between bursts, lowering the throughput. With
burst interval of 43 milliseconds, the incoming packets are
M. Lambert [Page 5]
RFC 1030 Testing the NETBLT Protocol November 1987
during the 3 millisecond-per-burst "dead time", making the
more efficient
6. Testing on an
The network used in performing this series of tests was a 10
per second Ethernet supporting about 150 hosts. The machines
either end of the NETBLT connection were IBM PC/ATs using 3COM 3C500
network interfaces. As with the Proteon Token Ring, the
provides high bandwidth with low delay. Unfortunately,
particular Ethernet used for testing (MIT's infamous Subnet 26)
known for being somewhat noisy. In addition, the 3COM 3C500
interfaces are relatively unsophisticated, with only a
hardware packet buffer for both transmitting and receiving packets
This gives the interface an annoying tendency to drop packets
heavy load. The combination of these factors made
performance analysis somewhat more difficult than on the
Ring
The fastest single-buffer transmission rate was 1.45 megabits
second, and was achieved using a test case with the
parameters
transfer size 2-5 million
data packet
1438 bytes (maximum size excluding
headers).
buffer size 14380
burst size 5
burst interval 30 milliseconds (6.0 milliseconds x 5 packets).
A second test, this one with parameters identical to the first
for number of outstanding buffers (2 instead of 1) resulted
substantially lower throughput (994 kilobits per second), with
large number of packets retransmitted (10%). The
occurred because the 3COM 3C500 network interface has only
hardware packet buffer and cannot hold a transmitting and
packet at the same time. With two outstanding buffers, the sender
data can transmit constantly; this means that when the receiver
data attempts to send a packet, its interface's receive hardware
M. Lambert [Page 6]
RFC 1030 Testing the NETBLT Protocol November 1987
deaf to the network and any packets being transmitted at the time
the sender of data are lost. A symmetrical problem occurs
control messages sent from receiver of data to sender of data,
the number of control messages sent is small enough and
retransmission algorithm redundant enough that little
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
packets were dropped, and throughput climbed accordingly, to 1.12
megabits per second. Presumably, the longer burst interval
more dead time between bursts and less likelihood of the receiver
data's interface being deaf to the net while the sender of data
sending a packet. An interesting note is that, when the same
was conducted on a special Ethernet LAN with the only two
attached being the two NETBLT machines, no packets were dropped
the burst interval rose above 40 milliseconds/5 packet burst.
improved performance was doubtless due to the absence of
network traffic
7. Testing on the Wideband
The following section describes results gathered using the
network. The Wideband network is a satellite-based network with
stations competing for a raw satellite channel bandwidth of 3
megabits per second. Since the various tests resulted in
changes to the NETBLT specification and implementation, some of
major changes are described along with the results and problems
forced those changes
The Wideband network has several characteristics that make it
excellent environment for testing NETBLT. First, it has an
long round-trip delay (1.8 seconds). This provides a good test
NETBLT's rate control and multiple-buffering capabilities. NETBLT'
rate control allows the packet transmission rate to be
independently of the maximum allowable amount of outstanding data
providing flow control as well as very large "windows". NETBLT'
multiple-buffering capability enables data to still be
while earlier data are awaiting retransmission and subsequent
are being prepared for transmission. On a network with a
round-trip delay, the alternative "lock-step" approach would
a 1.8 second gap between each buffer transmission,
performance
Another interesting characteristic of the Wideband network is
throughput. Although its raw bandwidth is 3 megabits per second,
the time of these tests fully 2/3 of that was consumed by low-
network overhead and hardware limitations. (A detailed analysis
M. Lambert [Page 7]
RFC 1030 Testing the NETBLT Protocol November 1987
the overhead appears at the end of this document.) This reduces
available bandwidth to just over 1 megabit per second. Since
NETBLT implementation can run substantially faster than that,
over the Wideband net allows us to measure NETBLT's ability
utilize very high percentages of available bandwidth
Finally, the Wideband net has some interesting packet reorder
delay characteristics that provide a good test of NETBLT's ability
deal with these problems
Testing progressed in several phases. The first phase involved
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
Wideband network, back down into a BBN Voice Funnel, and onto ISI'
Ethernet to another IBM PC/AT. Testing proceeded fairly slowly,
to gateway software and source-routing bugs. Once a connection
finally established, we recorded a best throughput of
90K bits per second
Several problems contributed to the low throughput. First,
gateways at either end were forwarding packets onto their
LANs faster than the IBM PC/AT's could accept them (the 3COM 3C500
interface would not have time to re-enable input before
packet would arrive from the gateway). Even with bursts of size 1,
spaced 6 milliseconds apart, the gateways would aggregate groups
packets coming from the same satellite frame, and send them
than the PC could receive them. The obvious result was many
packets, and degraded performance. Also, the half-duplex nature
the 3COM interface caused incoming packets to be dropped when
were being sent
The number of packets dropped on the sending NETBLT side due to
long interface re-enable time was reduced by packing as many
messages as possible into a single control packet (rather
placing only one message in a control packet). This reduced
number of control packets transmitted to one per buffer transmission
which the PC was able to handle. In particular, messages of the
OK(n) were combined with messages of the form GO(n + 1), in order
prevent two control packets from arriving too close together to
be received
Performance degradation from dropped control packets was
minimized by changing to a highly redundant control
transmission algorithm. Control messages are now stored in a
long-lived packet, with ACKed messages continuously bumped off
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
messages are transmitted as well. The sending NETBLT, which
M. Lambert [Page 8]
RFC 1030 Testing the NETBLT Protocol November 1987
these control messages, is tuned to ignore duplicate messages
almost no overhead. This transmission redundancy puts
reliance on the NETBLT control timer, further reducing
degradation from lost control packets
Although the effect of dropped packets on the receiving NETBLT
not be completely eliminated, it was reduced somewhat by some
to the implementation. Data packets from the sending NETBLT
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
none were received at the time packets for a buffer N+M
received. This optimization was somewhat complicated, but
NETBLT's performance in the face of missing packets. Unfortunately
the dropped-packet problem remained until the NETBLT
was ported to a SUN-3 workstation. The SUN is able to handle
incoming packets quite well, dropping only 0.5% of the data
(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
several changes in the implementation. Previously, the
implementation was "optimized" to generate retransmit requests
soon as possible, if possible not relying on expiration of a
timer. For instance, when the receiving NETBLT received an
packet for a buffer N, and other packets in buffer N had not arrived
the receiver would immediately generate a RESEND for the
packets. Similarly, under certain circumstances, the receiver
generate a RESEND for a buffer N if packets for N were expected
had not arrived before packets for a buffer N+M. Obviously, packet
reordering made these "optimizations" generate retransmit
unnecessarily. In the first case, the implementation was changed
no longer generate a retransmit request on receipt of an LDATA
other packets missing in the buffer. In the second case, a
timer was set with an updated (and presumably more accurate) value
hopefully allowing any re-ordered packets to arrive before timing
and generating a retransmit request
It is difficult to accommodate Wideband network packet delay in
NETBLT implementation. Packet delays tend to occur in multiples
600 milliseconds, due to the Wideband network's datagram
scheme. A timer value calculation algorithm that used a
variance on the order of 600 milliseconds would cause
degradation when packets were lost. On the other hand, short
variance values would not react well to the long delays possible
the Wideband net. Our solution has been to use an adaptive
timer value calculation algorithm. The algorithm maintains
average inter-packet arrival value, and uses that to determine
M. Lambert [Page 9]
RFC 1030 Testing the NETBLT Protocol November 1987
data timer value. If the inter-packet arrival time increases,
data timer value will lengthen
At this point, testing proceeded between NETBLT implementations on
SUN-3 workstation and an IBM PC/AT. The arrival of a
Gateway at ISI eliminated the need for source-routed packets;
performance improvement was also expected because the
Gateway is optimized for IP datagram traffic
In order to put the best Wideband network test results in context,
short analysis follows, showing the best throughput expected on
fully loaded channel. Again, a detailed analysis of the numbers
follow appears at the end of this document
The best possible datagram rate over the current
configuration is 24,054 bits per channel frame, or 3006 bytes
21.22 milliseconds. Since the transmission route begins and ends
an Ethernet, the largest amount of data transmissible (
accounting for packet header overhead) is 1438 bytes per packet
This translates to approximately 2 packets per frame. Since we
to avoid overflowing the channel, we should transmit slightly
than the channel frame rate of 21.2 milliseconds. We therefore
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
the BSAT (gateway-to-earth-station interface), 1438-byte packets
fragmented before transmission over the Wideband network,
packet delay and poor performance. The best throughput was
with the following values
transfer size 500,000 - 750,000
data packet
1432
buffer size 14320
burst size 5
burst interval 55
Steady-state throughputs ranged from 926 kilobits per second to 942
kilobits per second, approximately 90% channel utilization.
M. Lambert [Page 10]
RFC 1030 Testing the NETBLT Protocol November 1987
amount of data transmitted should have been an order of
higher, in order to get a longer steady-state period;
at the time we were testing, the Ethernet interface of ISI'
Butterfly Gateway would lock up fairly quickly (in 40-60 seconds)
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
conducted
In order to test the Wideband network under overload conditions,
attempted several tests at rates of 5 1432-byte packets every 50
milliseconds. At this rate, the Wideband network ground to a halt
four of the ten network BSATs immediately crashed and reset
channel processor nodes. Apparently, the BSATs crash because the
(Earth Station Interface), which sends data from the BSAT to
satellite, stops its transmit clock to the BSAT if it runs out
buffer space. The BIO interface connecting BSAT and ESI does
tolerate this clock-stopping, and typically locks up, forcing
channel processor node to reset. A more sophisticated interface
allowing faster transmissions, is being installed in the near future
8. Future
Some more testing needs to be performed over the Wideband Network
order to get a complete analysis of NETBLT's performance. Once
Butterfly Gateway Ethernet interface lockup problem described
has been fixed, we want to perform transmissions of 10 to 50
bytes to get accurate steady-state throughput results. We also
to run several NETBLT processes in parallel, each tuned to take
fraction of the Wideband Network's available bandwidth. Hopefully
this will demonstrate whether or not burst synchronization
different NETBLT processes will cause network congestion or failure
Once the BIO BSAT-ESI interface is upgraded, we will want to try
higher throughputs, as well as greater hardware stability
overload conditions
As far as future directions of research into NETBLT, one
area needs to be explored. A series of algorithms need to
developed to allow dynamic selection and control of NETBLT'
transmission parameters (burst size, burst interval, and number
outstanding buffers). Ideally, this dynamic control will not
any information from outside sources such as gateways; instead
NETBLT processes will use end-to-end information in order to
transmission rate decisions in the face of noisy channels and
congestion. Some research on dynamic rate control is taking
now, but much more work needs done before the results can
integrated into NETBLT
M. Lambert [Page 11]
RFC 1030 Testing the NETBLT Protocol November 1987
I. Wideband Bandwidth
Although the raw bandwidth of the Wideband Network is 3 megabits
second, currently only about 1 megabit per second of it is
to transmit data. The large amount of overhead is due to the
control strategy (which uses a fixed-width control subframe based
the maximum number of stations sharing the channel) and the low
performance BIO interface between BBN's BSAT (Butterfly
Interface) and Linkabit's ESI (Earth Station Interface). Higher
performance BSMI interfaces are soon to be installed in all
sites, which should improve the amount of available bandwidth
Bandwidth on the Wideband network is divided up into frames, each
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,
3.081 megabits per second
Each frame contains two subframes, a control subframe and a
subframe. The control subframe is subdivided into ten slots, one
earth station. Control information takes up 200 symbols per station
Because the communications interface between BSAT and ESI only
at 2 megabits per second, there must be a padding interval of 1263
symbols between each slot of information, bringing the total
subframe size up to 1463 symbols x 10 stations, or 14630 symbols
The data subframe then has 18138 symbols available. The
datagram size is currently expressed as a 14-bit quantity,
dropping the maximum amount of data in a frame to 16384 symbols
After header information is taken into account, this value drops
16,036 symbols. At 2 bits per symbol, using a 3/4 coding rate,
actual amount of usable data in a frame is 24,054 bits,
approximately 3006 bytes. Thus the theoretical usable bandwidth
24,054 bits every 21.22 milliseconds, or 1.13 megabits per second
Since the NETBLT implementations are running on Ethernet
gatewayed to the Wideband network, the 3006 bytes per channel
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
Following is a table of some of the test results gathered
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
PSZ number of bytes in DATA/LDATA packet data
BFSZ number of bytes in NETBLT
XFSZ number of kilobytes in
NBUFS number of outstanding
#LOSS number of data packets
#RXM number of data packets
DTMOS number of data timeouts on receiving
SPEED steady-state throughput in megabits per
M. Lambert [Page 13]
RFC 1030 Testing the NETBLT Protocol November 1987
BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM DTMOS
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
Following is a table of some of the test results gathered
testing NETBLT between two IBM PC/ATs on an Ethernet LAN.
previous appendix for table header definitions
BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM DTMOS
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
Following is a table of some of the test results gathered
testing NETBLT between an IBM PC/AT and a SUN-3 using the
satellite network. See previous appendix for table
definitions
BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM
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]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
