home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / benchmar / 1887 < prev    next >
Encoding:
Text File  |  1992-12-22  |  23.1 KB  |  727 lines
  1. Newsgroups: comp.benchmarks
  2. Path: sparky!uunet!think.com!ames!data.nas.nasa.gov!amelia.nas.nasa.gov!eugene
  3. From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
  4. Subject: [l/m 3/17/92] RFC 1242 -- terminology     (22/28)    c.be FAQ
  5. Keywords: who, what, where, when, why, how
  6. Sender: news@nas.nasa.gov (News Administrator)
  7. Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
  8. Date: Tue, 22 Dec 92 12:25:16 GMT
  9. Message-ID: <1992Dec22.122516.23206@nas.nasa.gov>
  10. Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
  11. Lines: 714
  12.  
  13. 22    RFC 1242 terminology (network benchmarking)    <This panel>
  14. 23
  15. 24
  16. 25    Ridiculously short benchmarks
  17. 26    Other miscellaneous benchmarks
  18. 27
  19. 28    References
  20. 1    Introduction to the FAQ chain and netiquette
  21. 2
  22. 3    PERFECT
  23. 4
  24. 5    Performance Metrics
  25. 6    Temporary scaffold of New FAQ material
  26. 7    Music to benchmark by
  27. 8    Benchmark types
  28. 9    Linpack
  29. 10
  30. 11    NIST source and .orgs
  31. 12    Benchmark Environments
  32. 13    SLALOM
  33. 14
  34. 15    12 Ways to Fool the Masses with Benchmarks
  35. 16    SPEC
  36. 17    Benchmark invalidation methods
  37. 18
  38. 19    WPI Benchmark
  39. 20    Equivalence
  40. 21    TPC
  41.  
  42.  
  43. Network Working Group                                 S. Bradner, Editor
  44. Request for Comments: 1242                            Harvard University
  45.                                                                July 1991
  46.  
  47.  
  48.       Benchmarking Terminology for Network Interconnection Devices
  49.  
  50. Status of this Memo
  51.  
  52.    This memo provides information for the Internet community.  It does
  53.    not specify an Internet standard.  Distribution of this memo is
  54.    unlimited.
  55.  
  56. Abstract
  57.  
  58.    This memo discusses and defines a number of terms that are used in
  59.    describing performance benchmarking tests and the results of such
  60.    tests.  The terms defined in this memo will be used in additional
  61.    memos to define specific benchmarking tests and the suggested format
  62.    to be used in reporting the results of each of the tests.  This memo
  63.    is a product of the Benchmarking Methodology Working Group (BMWG) of
  64.    the Internet Engineering Task Force (IETF).
  65.  
  66. 1.  Introduction
  67.  
  68.    Vendors often engage in "specsmanship" in an attempt to give their
  69.    products a better position in the marketplace.  This usually involves
  70.    much "smoke & mirrors" used to confuse the user.  This memo and
  71.    follow-up memos attempt to define a specific set of terminology and
  72.    tests that vendors can use to measure and report the performance
  73.    characteristics of network devices.  This will provide the user
  74.    comparable data from different vendors with which to evaluate these
  75.    devices.
  76.  
  77. 2.  Definition format
  78.  
  79.         Term to be defined. (e.g., Latency)
  80.  
  81.         Definition:
  82.                 The specific definition for the term.
  83.  
  84.         Discussion:
  85.                 A brief discussion about the term, it's application
  86.                 and any restrictions on measurement procedures.
  87.  
  88.         Measurement units:
  89.                 The units used to report measurements of this
  90.                 term, if applicable.
  91.  
  92.  
  93.  
  94. Benchmarking Methodology Working Group                          [Page 1]
  95.  
  96. RFC 1242                Benchmarking Terminology               July 1991
  97.  
  98.  
  99.         Issues:
  100.                 List of issues or conditions that effect this term.
  101.  
  102.         See Also:
  103.                 List of other terms that are relevant to the discussion
  104.                 of this term.
  105.  
  106. 3.  Term definitions
  107.  
  108. 3.1  Back-to-back
  109.  
  110.         Definition:
  111.                 Fixed length frames presented at a rate such that there
  112.                 is the minimum legal separation for a given medium
  113.                 between frames over a short to medium period of time,
  114.                 starting from an idle state.
  115.  
  116.         Discussion:
  117.                 A growing number of devices on a network can produce
  118.                 bursts of back-to-back frames.  Remote disk servers
  119.                 using protocols like NFS, remote disk backup systems
  120.                 like rdump, and remote tape access systems can be
  121.                 configured such that a single request can result in
  122.                 a block of data being returned of as much as 64K octets.
  123.                 Over networks like ethernet with a relatively small MTU
  124.                 this results in many fragments to be transmitted.  Since
  125.                 fragment reassembly will only be attempted if all
  126.                 fragments have been received, the loss of even one
  127.                 fragment because of the failure of some intermediate
  128.                 network device to process enough continuous frames can
  129.                 cause an endless loop as the sender repetitively
  130.                 attempts to send its large data block.
  131.  
  132.                 With the increasing size of the Internet, routing
  133.                 updates can span many frames, with modern routers able
  134.                 to transmit very quickly.  Missing frames of routing
  135.                 information can produce false indications of
  136.                 unreachability.  Tests of this parameter are intended
  137.                 to determine the extent of data buffering in the
  138.                 device.
  139.  
  140.         Measurement units:
  141.                 Number of N-octet frames in burst.
  142.  
  143.         Issues:
  144.  
  145.         See Also:
  146.  
  147.  
  148.  
  149.  
  150. Benchmarking Methodology Working Group                          [Page 2]
  151.  
  152. RFC 1242                Benchmarking Terminology               July 1991
  153.  
  154.  
  155. 3.2  Bridge
  156.  
  157.         Definition:
  158.                 A system which forwards data frames based on information
  159.                 in the data link layer.
  160.  
  161.         Discussion:
  162.  
  163.         Measurement units:
  164.                 n/a
  165.  
  166.         Issues:
  167.  
  168.         See Also:
  169.                 bridge/router (3.3)
  170.                 router (3.15)
  171.  
  172. 3.3  bridge/router
  173.  
  174.         Definition:
  175.                 A bridge/router is a network device that can selectively
  176.                 function as a router and/or a bridge based on the
  177.                 protocol of a specific frame.
  178.  
  179.         Discussion:
  180.  
  181.         Measurement units:
  182.                 n/a
  183.  
  184.         Issues:
  185.  
  186.         See Also:
  187.                 bridge (3.2)
  188.                 router (3.15)
  189.  
  190. 3.4  Constant Load
  191.  
  192.         Definition:
  193.                 Fixed length frames at a fixed interval time.
  194.  
  195.         Discussion:
  196.                 Although it is rare, to say the least, to encounter
  197.                 a steady state load on a network device in the real
  198.                 world, measurement of steady state performance may
  199.                 be useful in evaluating competing devices.  The
  200.                 frame size is specified and constant.  All device
  201.                 parameters are constant.  When there is a checksum
  202.                 in the frame, it must be verified.
  203.  
  204.  
  205.  
  206. Benchmarking Methodology Working Group                          [Page 3]
  207.  
  208. RFC 1242                Benchmarking Terminology               July 1991
  209.  
  210.  
  211.         Measurement units:
  212.                 n/a
  213.  
  214.         Issues:
  215.                 unidirectional vs. bidirectional
  216.  
  217.         See Also:
  218.  
  219. 3.5  Data link frame size
  220.  
  221.         Definition:
  222.                 The number of octets in the frame from the first octet
  223.                 following the preamble to the end of the FCS, if
  224.                 present, or to the last octet of the data if there
  225.                 is no FCS.
  226.  
  227.         Discussion:
  228.                 There is much confusion in reporting the frame
  229.                 sizes used in testing network devices or network
  230.                 measurement.  Some authors include the checksum,
  231.                 some do not.  This is a specific definition for use
  232.                 in this and subsequent memos.
  233.  
  234.         Measurement units:
  235.                 octets
  236.  
  237.         Issues:
  238.  
  239.         See Also:
  240.  
  241. 3.6  Frame Loss Rate
  242.  
  243.         Definition:
  244.                 Percentage of frames that should have been forwarded
  245.                 by a network device under steady state (constant)
  246.                 load that were not forwarded due to lack of
  247.                 resources.
  248.  
  249.         Discussion:
  250.                 This measurement can be used in reporting the
  251.                 performance of a network device in an overloaded
  252.                 state.  This can be a useful indication of how a
  253.                 device would perform under pathological network
  254.                 conditions such as broadcast storms.
  255.  
  256.         Measurement units:
  257.                 Percentage of N-octet offered frames that are dropped.
  258.                 To be reported as a graph of offered load vs frame loss.
  259.  
  260.  
  261.  
  262. Benchmarking Methodology Working Group                          [Page 4]
  263.  
  264. RFC 1242                Benchmarking Terminology               July 1991
  265.  
  266.  
  267.         Issues:
  268.  
  269.         See Also:
  270.                 overhead behavior (3.11)
  271.                 policy based filtering (3.13)
  272.                 MTU mismatch behavior (3.10)
  273.  
  274. 3.7  Inter Frame Gap
  275.  
  276.         Definition:
  277.                 The delay from the end of a data link frame as defined
  278.                 in section 3.5, to the start of the preamble of the
  279.                 next data link frame.
  280.  
  281.         Discussion:
  282.                 There is much confusion in reporting the between
  283.                 frame time used in testing network devices.  This
  284.                 is a specific definition for use in this and subsequent
  285.                 memos.
  286.  
  287.         Measurement units:
  288.                 Time with fine enough units to distinguish between
  289.                 2 events.
  290.  
  291.         Issues:
  292.                 Link data rate.
  293.  
  294.         See Also:
  295.  
  296. 3.8   Latency
  297.  
  298.         Definition:
  299.                 For store and forward devices:
  300.                 The time interval starting when the last bit of the
  301.                 input frame reaches the input port and ending when
  302.                 the first bit of the output frame is seen on the
  303.                 output port.
  304.  
  305.                 For bit forwarding devices:
  306.                 The time interval starting when the end of the first
  307.                 bit of the input frame reaches the input port and
  308.                 ending when the start of the first bit of the output
  309.                 frame is seen on the output port.
  310.  
  311.         Discussion:
  312.                 Variability of latency can be a problem.
  313.                 Some protocols are timing dependent (e.g., LAT and IPX).
  314.                 Future applications are likely to be sensitive to
  315.  
  316.  
  317.  
  318. Benchmarking Methodology Working Group                          [Page 5]
  319.  
  320. RFC 1242                Benchmarking Terminology               July 1991
  321.  
  322.  
  323.                 network latency.  Increased device delay can reduce
  324.                 the useful diameter of net.  It is desired to
  325.                 eliminate the effect of the data rate on the latency
  326.                 measurement.  This measurement should only reflect the
  327.                 actual within device latency.  Measurements should be
  328.                 taken for a spectrum of frame sizes without changing
  329.                 the device setup.
  330.  
  331.                 Ideally, the measurements for all devices would be from
  332.                 the first actual bit of the frame after the preamble.
  333.                 Theoretically a vendor could design a device that
  334.                 normally would be considered a store and forward
  335.                 device, a bridge for example, that begins transmitting
  336.                 a frame before it is fully received.  This type of
  337.                 device is known as a "cut through" device.  The
  338.                 assumption is that the device would somehow invalidate
  339.                 the partially transmitted frame if in receiving the
  340.                 remainder of the input frame, something came up that
  341.                 the frame or this specific forwarding of it was in
  342.                 error.  For example, a bad checksum.  In this case,
  343.                 the device would still be considered a store and
  344.                 forward device and the latency would still be
  345.                 from last bit in to first bit out, even though the
  346.                 value would be negative.  The intent is to treat
  347.                 the device as a unit without regard to the internal
  348.                 structure.
  349.  
  350.         Measurement units:
  351.                 Time with fine enough units to distinguish between
  352.                 2 events.
  353.  
  354.         Issues:
  355.  
  356.         See Also:
  357.                 link speed mismatch (3.9)
  358.                 constant load (3.4)
  359.                 back-to-back (3.1)
  360.                 policy based filtering (3.13)
  361.                 single frame behavior (3.16)
  362.  
  363. 3.9  Link Speed Mismatch
  364.  
  365.         Definition:
  366.                 Speed mismatch between input and output data rates.
  367.  
  368.         Discussion:
  369.                 This does not refer to frame rate per se, it refers to
  370.                 the actual data rate of the data path.  For example,
  371.  
  372.  
  373.  
  374. Benchmarking Methodology Working Group                          [Page 6]
  375.  
  376. RFC 1242                Benchmarking Terminology               July 1991
  377.  
  378.  
  379.                 an Ethernet on one side and a 56KB serial link on the
  380.                 other.  This is has also been referred to as the "fire
  381.                 hose effect".  Networks that make use of serial links
  382.                 between local high speed networks will usually have
  383.                 link speed mismatch at each end of the serial links.
  384.  
  385.         Measurement units:
  386.                 Ratio of input and output data rates.
  387.  
  388.         Issues:
  389.  
  390.         See Also:
  391.                 constant load (3.4)
  392.                 back-to-back (3.1)
  393.  
  394. 3.10  MTU-mismatch behavior
  395.  
  396.         Definition:
  397.                 The network MTU (Maximum Transmission Unit) of the
  398.                 output network is smaller than the MTU of the input
  399.                 network, this results in fragmentation.
  400.  
  401.         Discussion:
  402.                 The performance of network devices can be significantly
  403.                 affected by having to fragment frames.
  404.  
  405.         Measurement units:
  406.                 Description of behavior.
  407.  
  408.         Issues:
  409.  
  410.         See Also:
  411.  
  412. 3.11  Overhead behavior
  413.  
  414.         Definition:
  415.                 Processing done other than that for normal data frames.
  416.  
  417.         Discussion:
  418.                 Network devices perform many functions in addition
  419.                 to forwarding frames.  These tasks range from internal
  420.                 hardware testing to the processing of routing
  421.                 information and responding to network management
  422.                 requests.  It is useful to know what the effect of
  423.                 these sorts of tasks is on the device performance.
  424.                 An example would be if a router were to suspend
  425.                 forwarding or accepting frames during the processing
  426.                 of large routing update for a complex protocol like
  427.  
  428.  
  429.  
  430. Benchmarking Methodology Working Group                          [Page 7]
  431.  
  432. RFC 1242                Benchmarking Terminology               July 1991
  433.  
  434.  
  435.                 OSPF.  It would be good to know of this sort of
  436.                 behavior.
  437.  
  438.         Measurement units:
  439.                 Any quantitative understanding of this behavior is by
  440.                 the determination of its effect on other measurements.
  441.  
  442.         Issues:
  443.                 bridging and routing protocols
  444.                 control processing
  445.                 icmp
  446.                 ip options processing
  447.                 fragmentation
  448.                 error processing
  449.                 event logging/statistics collection
  450.                 arp
  451.  
  452.         See Also:
  453.                 policy based filtering (3.13)
  454.  
  455. 3.12  Overloaded behavior
  456.  
  457.         Definition:
  458.                 When demand exceeds available system resources.
  459.  
  460.         Discussion:
  461.                 Devices in an overloaded state will lose frames.  The
  462.                 device might lose frames that contain routing or
  463.                 configuration information.  An overloaded state is
  464.                 assumed when there is any frame loss.
  465.  
  466.         Measurement units:
  467.                 Description of behavior of device in any overloaded
  468.                 states for both input and output overload conditions.
  469.  
  470.         Issues:
  471.                 How well does the device recover from overloaded state?
  472.                 How does source quench production effect device?
  473.                 What does device do when its resources are exhausted?
  474.                 What is response to system management in overloaded
  475.                 state?
  476.  
  477.         See Also:
  478.  
  479. 3.13  Policy based filtering
  480.  
  481.         Definition:
  482.                 Filtering is the process of discarding received
  483.  
  484.  
  485.  
  486. Benchmarking Methodology Working Group                          [Page 8]
  487.  
  488. RFC 1242                Benchmarking Terminology               July 1991
  489.  
  490.  
  491.                 frames by administrative decision where normal
  492.                 operation would be to forward them.
  493.  
  494.         Discussion:
  495.                 Many network devices have the ability to be
  496.                 configured to discard frames based on a number
  497.                 of criteria.  These criteria can range from simple
  498.                 source or destination addresses to examining
  499.                 specific fields in the data frame itself.
  500.                 Configuring many network devices to perform
  501.                 filtering operations impacts the throughput
  502.                 of the device.
  503.  
  504.         Measurement units:
  505.                 n/a
  506.  
  507.         Issues:
  508.                 flexibility of filter options
  509.                 number of filter conditions
  510.  
  511.         See Also:
  512.  
  513. 3.14  Restart behavior
  514.  
  515.         Definition:
  516.                 Reinitialization of system causing data loss.
  517.  
  518.         Discussion:
  519.                 During a period of time after a power up or
  520.                 reset, network devices do not accept and forward
  521.                 frames.  The duration of this period of unavailability
  522.                 can be useful in evaluating devices.  In addition,
  523.                 some network devices require some form of reset
  524.                 when specific setup variables are modified.  If the
  525.                 reset period were long it might discourage network
  526.                 managers from modifying these variables on production
  527.                 networks.
  528.  
  529.         Measurement units:
  530.                 Description of device behavior under various restart
  531.                 conditions.
  532.  
  533.         Issues:
  534.                 Types:
  535.                         power on
  536.                         reload software image
  537.                         flush port, reset buffers
  538.                         restart current code image, without reconfuration
  539.  
  540.  
  541.  
  542. Benchmarking Methodology Working Group                          [Page 9]
  543.  
  544. RFC 1242                Benchmarking Terminology               July 1991
  545.  
  546.  
  547.                 Under what conditions is a restart required?
  548.                 Does the device know when restart needed (i.e., hung
  549.                         state timeout)?
  550.                 Does the device recognize condition of too frequent
  551.                         auto-restart?
  552.                 Does the device run diagnostics on all or some resets?
  553.                 How may restart be initiated?
  554.                         physical intervention
  555.                         remote via terminal line or login over network
  556.  
  557.         See Also:
  558.  
  559. 3.15  Router
  560.  
  561.         Definition:
  562.                 A system which forwards data frames based on
  563.                 information in the network layer.
  564.  
  565.         Discussion:
  566.                 This implies "running" the network level protocol
  567.                 routing algorithm and performing whatever actions
  568.                 that the protocol requires.  For example, decrementing
  569.                 the TTL field in the TCP/IP header.
  570.  
  571.         Measurement units:
  572.                 n/a
  573.  
  574.         Issues:
  575.  
  576.         See Also:
  577.                 bridge (3.2)
  578.                 bridge/router (3.3)
  579.  
  580. 3.16  Single frame behavior
  581.  
  582.         Definition:
  583.                 One frame received on the input to a device.
  584.  
  585.         Discussion:
  586.                 A data "stream" consisting of a single frame can
  587.                 require a network device to do a lot of processing.
  588.                 Figuring routes, performing ARPs, checking
  589.                 permissions etc., in general, setting up cache entries.
  590.                 Devices will often take much more time to process a
  591.                 single frame presented in isolation than it would if
  592.                 the same frame were part of a steady stream.  There
  593.                 is a worry that some devices would even discard a single
  594.                 frame as part of the cache setup procedure under the
  595.  
  596.  
  597.  
  598. Benchmarking Methodology Working Group                         [Page 10]
  599.  
  600. RFC 1242                Benchmarking Terminology               July 1991
  601.  
  602.  
  603.                 assumption that the frame is only the first of many.
  604.  
  605.         Measurement units:
  606.                 Description of the behavior of the device.
  607.  
  608.         Issues:
  609.  
  610.         See Also:
  611.                 policy based filtering (3.13)
  612.  
  613. 3.17  Throughput
  614.  
  615.         Definition:
  616.                 The maximum rate at which none of the offered frames
  617.                 are dropped by the device.
  618.  
  619.         Discussion:
  620.                 The throughput figure allows vendors to report a
  621.                 single value which has proven to have use in the
  622.                 marketplace.  Since even the loss of one frame in a
  623.                 data stream can cause significant delays while
  624.                 waiting for the higher level protocols to time out,
  625.                 it is useful to know the actual maximum data
  626.                 rate that the device can support.  Measurements should
  627.                 be taken over a assortment of frame sizes.  Separate
  628.                 measurements for routed and bridged data in those
  629.                 devices that can support both.  If there is a checksum
  630.                 in the received frame, full checksum processing must
  631.                 be done.
  632.  
  633.         Measurement units:
  634.                 N-octet input frames per second
  635.                 input bits per second
  636.  
  637.         Issues:
  638.                 single path vs. aggregate
  639.                 load
  640.                 unidirectional vs bidirectional
  641.                 checksum processing required on some protocols
  642.  
  643.         See Also:
  644.                 frame loss rate (3.6)
  645.                 constant load (3.4)
  646.                 back-to-back (3.1)
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654. Benchmarking Methodology Working Group                         [Page 11]
  655.  
  656. RFC 1242                Benchmarking Terminology               July 1991
  657.  
  658.  
  659. 4.  Acknowledgements
  660.  
  661.    This memo is a product of the IETF BMWG working group:
  662.  
  663.         Chet Birger, Coral Networks
  664.         Scott Bradner, Harvard University (chair)
  665.         Steve Butterfield, independant consultant
  666.         Frank Chui, TRW
  667.         Phill Gross, CNRI
  668.         Stev Knowles, FTP Software, Inc.
  669.         Mat Lew, TRW
  670.         Gary Malkin, FTP Software, Inc.
  671.         K.K. Ramakrishnan, Digital Equipment Corp.
  672.         Mick Scully, Ungerman Bass
  673.         William M. Seifert, Wellfleet Communications Corp.
  674.         John Shriver, Proteon, Inc.
  675.         Dick Sterry, Microcom
  676.         Geof Stone, Network Systems Corp.
  677.         Geoff Thompson, SynOptics
  678.         Mary Youssef, IBM
  679.  
  680. Security Considerations
  681.  
  682.    Security issues are not discussed in this memo.
  683.  
  684. Author's Address
  685.  
  686.    Scott Bradner
  687.    Harvard University
  688.    William James Hall 1232
  689.    33 Kirkland Street
  690.    Cambridge, MA 02138
  691.  
  692.    Phone: (617) 495-3864
  693.  
  694.    EMail: SOB@HARVARD.HARVARD.EDU
  695.    Or, send comments to: bmwg@harvisr.harvard.edu.
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710. Benchmarking Methodology Working Group                         [Page 12]
  711.  
  712.  
  713.                    ^ A  
  714.                 s / \ r                
  715.                m /   \ c              
  716.               h /     \ h            
  717.              t /       \ i          
  718.             i /         \ t        
  719.            r /           \ e      
  720.           o /             \ c    
  721.          g /               \ t  
  722.         l /                 \ u
  723.        A /                   \ r
  724.         <_____________________> e   
  725.                 Language
  726.  
  727.