rfc2544.txt

<VC++网络游戏建摸与实现>源代码

   This model is useful when the test input and output are homogenous
   (e.g., 64-byte IP, 802.3 frames into the DUT; 64 byte IP, 802.3
   frames out), or the method of test can distinguish between dissimilar
   input/output. (E.g., 1518 byte IP, 802.3 frames in; 576 byte,
   fragmented IP, X.25 frames out.)

   By extending the single DUT test model, reasonable benchmarks
   regarding multiple DUTs or heterogeneous environments may be
   collected. In this extension, the single DUT is replaced by a system
   of interconnected network DUTs. This test methodology would support
   the benchmarking of a variety of device/media/service/protocol
   combinations. For example, a configuration for a LAN-to-WAN-to-LAN
   test might be:

   (1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3

   Or a mixed LAN configuration might be:

   (2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3

   In both examples 1 and 2, end-to-end benchmarks of each system could
   be empirically ascertained. Other behavior may be characterized
   through the use of intermediate devices. In example 2, the
   configuration may be used to give an indication of the FDDI to FDDI
   capability exhibited by DUT 2.

   Because multiple DUTs are treated as a single system, there are
   limitations to this methodology. For instance, this methodology may
   yield an aggregate benchmark for a tested system. That benchmark
   alone, however, may not necessarily reflect asymmetries in behavior
   between the DUTs, latencies introduce by other apparatus (e.g.,
   CSUs/DSUs, switches), etc.

   Further, care must be used when comparing benchmarks of different
   systems by ensuring that the DUTs' features/configuration of the
   tested systems have the appropriate common denominators to allow
   comparison.

20. Maximum frame rate

   The maximum frame rates that should be used when testing LAN
   connections SHOULD be the listed theoretical maximum rate for the
   frame size on the media.








Bradner & McQuaid            Informational                     [Page 13]

RFC 2544                Benchmarking Methodology              March 1999


   The maximum frame rate that should be used when testing WAN
   connections SHOULD be greater than the listed theoretical maximum
   rate for the frame size on that speed connection.  The higher rate
   for WAN tests is to compensate for the fact that some vendors employ
   various forms of header compression.

   A list of maximum frame rates for LAN connections is included in
   Appendix B.

21. Bursty traffic

   It is convenient to measure the DUT performance under steady state
   load but this is an unrealistic way to gauge the functioning of a DUT
   since actual network traffic normally consists of bursts of frames.
   Some of the tests described below SHOULD be performed with both
   steady state traffic and with traffic consisting of repeated bursts
   of frames.  The frames within a burst are transmitted with the
   minimum legitimate inter-frame gap.

   The objective of the test is to determine the minimum interval
   between bursts which the DUT can process with no frame loss. During
   each test the number of frames in each burst is held constant and the
   inter-burst interval varied.  Tests SHOULD be run with burst sizes of
   16, 64, 256 and 1024 frames.

22. Frames per token

   Although it is possible to configure some token ring and FDDI
   interfaces to transmit more than one frame each time that the token
   is received, most of the network devices currently available transmit
   only one frame per token.  These tests SHOULD first be performed
   while transmitting only one frame per token.

   Some current high-performance workstation servers do transmit more
   than one frame per token on FDDI to maximize throughput.  Since this
   may be a common feature in future workstations and servers,
   interconnect devices with FDDI interfaces SHOULD be tested with 1, 4,
   8, and 16 frames per token.  The reported frame rate SHOULD be the
   average rate of frame transmission over the total trial period.

23. Trial description

   A particular test consists of multiple trials.  Each trial returns
   one piece of information, for example the loss rate at a particular
   input frame rate.  Each trial consists of a number of phases:

   a) If the DUT is a router, send the routing update to the "input"
   port and pause two seconds to be sure that the routing has settled.



Bradner & McQuaid            Informational                     [Page 14]

RFC 2544                Benchmarking Methodology              March 1999


   b)  Send the "learning frames" to the "output" port and wait 2
   seconds to be sure that the learning has settled.  Bridge learning
   frames are frames with source addresses that are the same as the
   destination addresses used by the test frames.  Learning frames for
   other protocols are used to prime the address resolution tables in
   the DUT.  The formats of the learning frame that should be used are
   shown in the Test Frame Formats document.

   c) Run the test trial.

   d) Wait for two seconds for any residual frames to be received.

   e) Wait for at least five seconds for the DUT to restabilize.

24. Trial duration

   The aim of these tests is to determine the rate continuously
   supportable by the DUT.  The actual duration of the test trials must
   be a compromise between this aim and the duration of the benchmarking
   test suite.  The duration of the test portion of each trial SHOULD be
   at least 60 seconds.  The tests that involve some form of "binary
   search", for example the throughput test, to determine the exact
   result MAY use a shorter trial duration to minimize the length of the
   search procedure, but the final determination SHOULD be made with
   full length trials.

25. Address resolution

   The DUT SHOULD be able to respond to address resolution requests sent
   by the DUT wherever the protocol requires such a process.

26. Benchmarking tests:

   Note: The notation "type of data stream" refers to the above
   modifications to a frame stream with a constant inter-frame gap, for
   example, the addition of traffic filters to the configuration of the
   DUT.

26.1 Throughput

   Objective:  To determine the DUT throughput as defined in RFC 1242.

   Procedure:  Send a specific number of frames at a specific rate
   through the DUT and then count the frames that are transmitted by the
   DUT. If the count of offered frames is equal to the count of received
   frames, the fewer frames are received than were transmitted, the rate
   of the offered stream is reduced and the test is rerun.




Bradner & McQuaid            Informational                     [Page 15]

RFC 2544                Benchmarking Methodology              March 1999


   The throughput is the fastest rate at which the count of test frames
   transmitted by the DUT is equal to the number of test frames sent to
   it by the test equipment.

   Reporting format:  The results of the throughput test SHOULD be
   reported in the form of a graph. If it is, the x coordinate SHOULD be
   the frame size, the y coordinate SHOULD be the frame rate.  There
   SHOULD be at least two lines on the graph.  There SHOULD be one line
   showing the theoretical frame rate for the media at the various frame
   sizes.  The second line SHOULD be the plot of the test results.
   Additional lines MAY be used on the graph to report the results for
   each type of data stream tested.  Text accompanying the graph SHOULD
   indicate the protocol, data stream format, and type of media used in
   the tests.

   We assume that if a single value is desired for advertising purposes
   the vendor will select the rate for the minimum frame size for the
   media. If this is done then the figure MUST be expressed in frames
   per second.  The rate MAY also be expressed in bits (or bytes) per
   second if the vendor so desires.  The statement of performance MUST
   include a/ the measured maximum frame rate, b/ the size of the frame
   used, c/ the theoretical limit of the media for that frame size, and
   d/ the type of protocol used in the test.  Even if a single value is
   used as part of the advertising copy, the full table of results
   SHOULD be included in the product data sheet.

26.2 Latency

   Objective:  To determine the latency as defined in RFC 1242.

   Procedure:  First determine the throughput for DUT at each of the
   listed frame sizes. Send a stream of frames at a particular frame
   size through the DUT at the determined throughput rate to a specific
   destination.  The stream SHOULD be at least 120 seconds in duration.
   An identifying tag SHOULD be included in one frame after 60 seconds
   with the type of tag being implementation dependent. The time at
   which this frame is fully transmitted is recorded (timestamp A).  The
   receiver logic in the test equipment MUST recognize the tag
   information in the frame stream and record the time at which the
   tagged frame was received (timestamp B).

   The latency is timestamp B minus timestamp A as per the relevant
   definition frm RFC 1242, namely latency as defined for store and
   forward devices or latency as defined for bit forwarding devices.

   The test MUST be repeated at least 20 times with the reported value
   being the average of the recorded values.




Bradner & McQuaid            Informational                     [Page 16]

RFC 2544                Benchmarking Methodology              March 1999


   This test SHOULD be performed with the test frame addressed to the
   same destination as the rest of the data stream and also with each of
   the test frames addressed to a new destination network.

   Reporting format:  The report MUST state which definition of latency
   (from RFC 1242) was used for this test.  The latency results SHOULD
   be reported in the format of a table with a row for each of the
   tested frame sizes.  There SHOULD be columns for the frame size, the
   rate at which the latency test was run for that frame size, for the
   media types tested, and for the resultant latency values for each
   type of data stream tested.

26.3 Frame loss rate

   Objective:  To determine the frame loss rate, as defined in RFC 1242,
   of a DUT throughout the entire range of input data rates and frame
   sizes.

   Procedure:  Send a specific number of frames at a specific rate
   through the DUT to be tested and count the frames that are
   transmitted by the DUT.  The frame loss rate at each point is
   calculated using the following equation:

          ( ( input_count - output_count ) * 100 ) / input_count


   The first trial SHOULD be run for the frame rate that corresponds to
   100% of the maximum rate for the frame size on the input media.
   Repeat the procedure for the rate that corresponds to 90% of the
   maximum rate used and then for 80% of this rate.  This sequence
   SHOULD be continued (at reducing 10% intervals) until there are two
   successive trials in which no frames are lost. The maximum
   granularity of the trials MUST be 10% of the maximum rate, a finer
   granularity is encouraged.

   Reporting format:  The results of the frame loss rate test SHOULD be
   plotted as a graph.  If this is done then the X axis MUST be the
   input frame rate as a percent of the theoretical rate for the media
   at the specific frame size. The Y axis MUST be the percent loss at
   the particular input rate.  The left end of the X axis and the bottom
   of the Y axis MUST be 0 percent; the right end of the X axis and the
   top of the Y axis MUST be 100 percent.  Multiple lines on the graph
   MAY used to report the frame loss rate for different frame sizes,
   protocols, and types of data streams.

   Note: See section 18 for the maximum frame rates that SHOULD be used.





Bradner & McQuaid            Informational                     [Page 17]

RFC 2544                Benchmarking Methodology              March 1999


26.4 Back-to-back frames

   Objective:  To characterize the ability of a DUT to process back-to-
   back frames as defined in RFC 1242.

   Procedure:  Send a burst of frames with minimum inter-frame gaps to
   the DUT and count the number of frames forwarded by the DUT.  If the
   count of transmitted frames is equal to the number of frames
   forwarded the length of the burst is increased and the test is rerun.
   If the number of forwarded frames is less than the number
   transmitted, the length of the burst is reduced and the test is
   rerun.

   The back-to-back value is the number of frames in the longest burst
   that the DUT will handle without the loss of any frames.  The trial
   length MUST be at least 2 seconds and SHOULD be repeated at least 50
   times with the average of the recorded values being reported.

   Reporting format:  The back-to-back results SHOULD be reported in the
   format of a table with a row for each of the tested frame sizes.
   There SHOULD be columns for the frame size and for the resultant
   average frame count for each type of data stream tested.  The
   standard deviation for each measurement MAY also be reported.

26.5 System recovery

   Objective:  To characterize the speed at which a DUT recovers from an
   overload condition.

   Procedure:  First determine the throughput for a DUT at each of the
   listed frame sizes.

   Send a stream of frames at a rate 110% of the recorded throughput
   rate or the maximum rate for the media, whichever is lower, for at
   least 60 seconds.  At Timestamp A reduce the frame rate to 50% of the
   above rate and record the time of the last frame lost (Timestamp B).
   The system recovery time is determined by subtracting Timestamp B
   from Timestamp A.  The test SHOULD be repeated a number of times and
   the average of the recorded values being reported.

   Reporting format:  The system recovery results SHOULD be reported in
   the format of a table with a row for each of the tested frame sizes.
   There SHOULD be columns for the frame size, the frame rate used as
   the throughput rate for each type of data stream tested, and for the
   measured recovery time for each type of data stream tested.






Bradner & McQuaid            Informational                     [Page 18]

RFC 2544                Benchmarking Methodology              March 1999


26.6 Reset

   Objective:  To characterize the speed at which a DUT recovers from a