RFC2889 日本語訳
2889 Benchmarking Methodology for LAN Switching Devices. R.Mandeville, J. Perser. August 2000. (Format: TXT=73251 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Mandeville
Request for Comments: 2889 CQOS Inc.
Category: Informational J. Perser
Spirent Communications
August 2000
コメントを求めるワーキンググループR.マンデヴィルの要求をネットワークでつないでください: 2889年のCQOS株式会社カテゴリ: 情報のJ.Perser Spirentコミュニケーション2000年8月
Benchmarking Methodology for LAN Switching Devices
LAN切換装置のためのベンチマーキング方法論
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Frame formats and sizes . . . . . . . . . . . . . . . . . . . 3
5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 3
5.1 Fully meshed throughput, frame loss and forwarding rates 4
5.2 Partially meshed one-to-many/many-to-one . . . . . . . . 7
5.3 Partially meshed multiple devices . . . . . . . . . . . . 10
5.4 Partially meshed unidirectional traffic . . . . . . . . . 13
5.5 Congestion Control . . . . . . . . . . . . . . . . . . . 16
5.6 Forward Pressure and Maximum Forwarding Rate . . . . . . 19
5.7 Address caching capacity . . . . . . . . . . . . . . . . 22
5.8 Address learning rate . . . . . . . . . . . . . . . . . . 25
5.9 Errored frames filtering. . . . . . . . . . . . . . . . . 27
5.10 Broadcast frame Forwarding and Latency . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A: Formulas . . . . . . . . . . . . . . . . . . . . . 31
Appendix B: Generating Offered Load . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 セットアップ. . . . . . . . . . . . . . . . . . . . . . . . . . 2 4をテストしてください。 形式とサイズ. . . . . . . . . . . . . . . . . . . 3 5を縁どってください。 ベンチマーキングTests. . . . . . . . . . . . . . . . . . . . . . 3 5.1Fullyはスループット、フレームの損失を網の目にかけました、そして、1つへの4の5.2のPartially多くへのかみ合っているもの/多く.75.3Partiallyが網の目にかけたレートに複数の装置を送って、.105.4Partiallyは単方向の交通を網の目にかけました; .135.5 容量. . . . . . . . . . . . . . . . 22 5.8Address学習をキャッシュする混雑Control. . . . . . . . . . . . . . . . . . . 16 5.6Forward PressureとMaximum Forwarding Rate. . . . . . 19 5.7Addressは、.255.9個のErroredフレームがフィルターにかけていると評定します。 . . . . . . . . . . . . . . . . 27 5.10はフレームForwardingとLatency. . . . . . . . . 28 6を放送します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 30 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 30 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 30盲腸A: 定石. . . . . . . . . . . . . . . . . . . . . 31付録B: 発生は完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 35を負荷. . . . . . . . . . . . . 32に提供しました。
Mandeville & Perser Informational [Page 1] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[1ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
1. Introduction
1. 序論
This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. It extends the methodology already defined for benchmarking network interconnecting devices in RFC 2544 [3] to switching devices.
このドキュメントがローカル・エリア・ネットワーク(LAN)切換装置のベンチマーキングに方法論を提供することを意図します。 それはRFC2544[3]で切換装置と装置とインタコネクトするベンチマーキングネットワークのために既に定義された方法論について敷衍しています。
This RFC primarily deals with devices which switch frames at the Medium Access Control (MAC) layer. It provides a methodology for benchmarking switching devices, forwarding performance, congestion control, latency, address handling and filtering. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.
このRFCは主として、Medium Access Control(MAC)のスイッチ・フレームが層にする装置に対処します。 性能、輻輳制御、潜在、アドレス取り扱い、およびフィルタリングを転送して、それはベンチマーキング切換装置に方法論を供給します。 また、テストを定義することに加えて、このドキュメントはテストの結果を報告するための特定の形式について説明します。
A previous document, "Benchmarking Terminology for LAN Switching Devices" [2], defined many of the terms that are used in this document. The terminology document SHOULD be consulted before attempting to make use of this document.
前のドキュメント(「LAN切換装置のためのベンチマーキング用語」[2])は本書では使用される用語の多くを定義しました。 用語はSHOULDを記録します。このドキュメントを利用するのを試みる前に、相談されてください。
2. Requirements
2. 要件
The following RFCs SHOULD be consulted before attempting to make use of this document: RFC 1242 [1], RFC 2285 [2], and RFC 2544 [3].
以下のRFCs SHOULD、このドキュメントを利用するのを試みる前に、相談されてください: RFC1242[1]、RFC2285[2]、およびRFC2544[3]。
For the sake of clarity and continuity, this RFC adopts the template for benchmarking tests set out in Section 26 of RFC 2544.
明快と連続のために、このRFCはRFC2544のセクション26を始められたベンチマーキングテストのためのテンプレートを採用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3. Test setup
3. テストセットアップ
This document extends the general test setup described in section 6 of RFC 2544 [3] to the benchmarking of LAN switching devices. RFC 2544 [3] primarily describes non-meshed traffic where input and output interfaces are grouped in mutually exclusive sending and receiving pairs. In fully meshed traffic, each interface of a DUT/SUT is set up to both receive and transmit frames to all the other interfaces under test.
このドキュメントはRFC2544[3]のセクション6でLAN切換装置のベンチマーキングに説明された一般的なテストセットアップを広げています。 RFC2544[3]は主として、入出力インタフェースが互いに排他的な送受信組で分類される非かみ合っている交通を説明します。 完全にかみ合っている交通では、DUT/SUTの各インタフェースは、ともに他のすべてのインタフェースにフレームをテストで受けて、伝えるためにセットアップされます。
Prior to each test run, the DUT/SUT MUST learn the MAC addresses used in the test and the address learning SHOULD be verified. Addresses not learned will be forwarded as flooded frames and reduce the amount of correctly forwarded frames. The rate at which address learning frames are offered may have to be adjusted to be as low as 50 frames per second or even less, to guarantee successful learning. The DUT/SUT address aging time SHOULD be configured to be greater than
各試運転の前に、DUT/SUT MUSTはSHOULDが確かめられることを学びながらテストとアドレスで使用されるMACアドレスを学びます。 学習されなかったアドレスは、水につかっているフレームとして進められて、正しく進められたフレームの量を減少させるでしょう。 アドレス学習フレームが提供されるレートは、1秒あたり50個のフレームか以下とさえ同じくらい低く、うまくいっている学習を保証するように調整されなければならないかもしれません。 よりすばらしくなるように構成されていて、DUT/SUTは古い時間SHOULDを記述します。
Mandeville & Perser Informational [Page 2] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[2ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
the period of the learning phase of the test plus the trial duration plus any configuration time required by the testing device. Addresses SHOULD NOT age out until the trial duration is completed. More than one learning trial may be needed for the association of the address to the port to occur.
テストの学習フェーズと、トライアル持続時間と構成何時でも期間がテスト装置が必要です。 トライアルまで、持続時間が完成するSHOULD NOT時代を記述します。 1つ以上の学習トライアルがポートへのアドレスが起こる協会に必要であるかもしれません。
If a DUT/SUT uses a hashing algorithm with address learning, the DUT/SUT may not learn the necessary addresses to perform the tests. The format of the MAC addresses MUST be adjustable so that the address mapping may be re-arranged to ensure that the DUT/SUT learns all the addresses.
DUT/SUTが学ぶアドレスと共に論じ尽くすアルゴリズムを使用するなら、DUT/SUTは、テストを実行するために必要なアドレスを学ばないかもしれません。 MACアドレスの形式は、DUT/SUTがすべてのアドレスを学ぶのを保証するためにアドレス・マッピングを再配列できるくらい調整可能でなければなりません。
4. Frame formats and sizes
4. フレーム形式とサイズ
The test frame format is defined in RFC 2544 section 8 [3] and MUST contain a unique signature field located in the UDP DATA area of the Test Frame (see Appendix C [3]). The purpose of the signature field is filter out frames that are not part of the offered load.
テストフレーム形式は、RFC2544部8の[3]で定義されて、Test FrameについてUDP DATA領域に位置するユニークな署名分野を含まなければなりません。(Appendix C[3])を見てください。 署名分野の目的は提供された負荷の一部でないフレームを無視することです。
The signature field MUST be unique enough to identify the frames not originating from the DUT/SUT. The signature field SHOULD be located after byte 56 (collision window [4] ) or at the end of the frame. The length, contents and method of detection is not defined in this memo.
署名分野はDUT/SUTから発しないフレームを特定できるくらいユニークでなければなりません。 署名は見つけられた後バイトが56であったならSHOULDをさばきます。(衝突ウィンドウ[4] )かフレームの端で。 長さ、コンテンツ、および検出の方法はこのメモで定義されません。
The signature field MAY have a unique identifier per port. This would filter out misforwarded frames. It is possible for a DUT/SUT to strip off the MAC layer, send it through its switching matrix, and transmit it out with the correct destination MAC address but the wrong payload.
署名分野には、1ポートあたり1つのユニークな識別子があるかもしれません。 これはmisforwardedフレームを無視するでしょう。 DUT/SUTがMAC層を全部はぎ取って、切り換えマトリクスでそれを送って、正しい送付先MACアドレスにもかかわらず、間違ったペイロードによる外にそれを伝えるのは、可能です。
For frame sizes, refer to RFC 2544, section 9 [3].
フレーム・サイズについて、RFC2544、セクション9[3]を参照してください。
There are three possible frame formats for layer 2 Ethernet switches: standard MAC Ethernet frames, standard MAC Ethernet frames with vendor-specific tags added to them, and IEEE 802.3ac frames tagged to accommodate 802.1p&Q. The two types of tagged frames may exceed the standard maximum length frame of 1518 bytes, and may not be accepted by the interface controllers of some DUT/SUTs. It is recommended to check the compatibility of the DUT/SUT with tagged frames before testing.
層2のイーサネットスイッチのための3つの可能なフレーム形式があります: フレーム、それらへの業者特有のタグが加えられている標準のMACイーサネットフレーム、およびIEEE 802.3acフレームが802.1pを収容するためにタグ付けをした標準のMACイーサネットとQ。 2つのタイプのタグ付けをされたフレームは、最大1518バイトの標準の長さのフレームを超えて、いくつかのDUT/SUTsのインタフェースコントローラによって受け入れられないかもしれません。 テストする前のタグ付けをされたフレームにDUT/SUTの互換性について問い合わせるのはお勧めです。
Devices switching tagged frames of over 1518 bytes will have a different maximum forwarding rate than untagged frames.
1518バイト以上のタグ付けをされたフレームを切り換える装置がフレームに非タグ付けをしたのと異なった最大の伝送速度を持つでしょう。
5. Benchmarking Tests
5. ベンチマーキングテスト
The following tests offer objectives, procedures, and reporting formats for benchmarking LAN switching devices.
以下のテストはベンチマーキングLAN切換装置のために目的、手順、および報告に形式を提供します。
Mandeville & Perser Informational [Page 3] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[3ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.1 Fully meshed throughput, frame loss and forwarding rates
5.1 完全にかみ合っているスループット、フレームの損失、および伝送速度
5.1.1 Objective
5.1.1 目的
To determine the throughput, frame loss and forwarding rates of DUT/SUTs offered fully meshed traffic as defined in RFC 2285 [2].
完全に提供されたDUT/SUTsのスループット、フレームの損失、および伝送速度を測定するのはRFC2285[2]で定義されるように交通を網の目にかけました。
5.1.2 Setup Parameters
5.1.2 セットアップパラメタ
When offering full meshed traffic, the following parameters MUST be defined. Each parameter is configured with the following considerations.
完全なかみ合っている交通を提供するとき、以下のパラメタを定義しなければなりません。 各パラメタは以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Interframe Gap (IFG) - The IFG between frames inside a burst MUST
be at the minimum specified by the standard (9.6 us for 10Mbps
Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps
Ethernet) of the medium being tested.
インターフレームGap(IFG)、--、規格によって指定された最小限には炸裂の中のフレームの間のIFGがあるに違いない(9.6 10Mbpsイーサネットのための私たち、100Mbpsイーサネットのための960ナノ秒、および1つのGbpsイーサネットのための96ナノ秒) テストされる媒体について。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load, regardless of traffic
orientation or duplex mode. Certain test configurations will
theoretically over-subscribe the DUT/SUT.
ILoad--1ポートあたりの意図しているLoadは媒体の最大の理論上の負荷の割合で急送されます、交通オリエンテーションか重複のモードにかかわらず。 あるテスト構成は理論的にDUT/SUTを申し込み過ぎるでしょう。
In half duplex, an ILoad over 50% will over-subscribe the DUT/SUT.
半二重では、50%以上のILoadはDUT/SUTを申し込み過ぎるでしょう。
Burst Size - The burst size defines the number of frames sent
back-to-back at the minimum legal IFG [4] before pausing
transmission to receive frames. Burst sizes SHOULD vary between 1
and 930 frames. A burst size of 1 will simulate constant load
[1].
Sizeを押し破いてください--放出量はフレーム搬入するためにトランスミッションをポーズする前に最小の法的なIFG[4]に背中合わせの状態で送られたフレームの数を定義します。 放出量SHOULDは1〜930個のフレームを変えます。 1の放出量は一定の負荷[1]をシミュレートするでしょう。
Addresses per port - Represents the number of addresses which are
being tested for each port. Number of addresses SHOULD be a
binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...).
Recommended value is 1.
1ポートあたりのアドレス--各ポートがないかどうかテストされているアドレスの数を表します。 数、アドレスSHOULDでは、aバイナリー指数になってください(すなわち、1、2、4、8、16、32、64、128、256)。 推奨値は1です。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
Mandeville & Perser Informational [Page 4] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[4ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.1.3 Procedure
5.1.3 手順
All ports on the tester MUST transmit test frames either in a Frame Based or Time Based mode (Appendix B). All ports SHOULD start transmitting their frames within 1% of the trial duration. For a trial duration of 30 seconds, all ports SHOULD have started transmitting frames within 300 milliseconds of each other.
Frame BasedかTime Basedモード(付録B)でテスターの上のポートが伝えなければならないすべてがフレームをテストします。 すべてが、トライアル持続時間の1%以内でそれらのフレームを伝えながら、SHOULD始めを移植します。 30秒、SHOULDが互いの300ミリセカンド以内でフレームを伝え始めたすべてのポートのトライアル持続時間のために。
Each port in the test MUST send test frames to all other ports in a round robin type fashion. The sequence of addresses MUST NOT change when congestion control is applied. The following table shows how each port in a test MUST transmit test frames to all other ports in the test. In this example, there are six ports with 1 address per port:
テストにおける各ポートは連続タイプファッションで他のすべてのポートにテストフレームを送らなければなりません。 アドレスの系列は、輻輳制御がいつ適用されているかを変えてはいけません。 以下のテーブルはテストにおける各ポートがテストで他のすべてのポートにどうテストフレームを送らなければならないかを示しています。 この例には、1ポートあたり1つのアドレスがある6つのポートがあります:
Source Port Destination Ports (in order of transmission)
ソースポート仕向港(トランスミッションの順に)
Port #1 2 3 4 5 6 2... Port #2 3 4 5 6 1 3... Port #3 4 5 6 1 2 4... Port #4 5 6 1 2 3 5... Port #5 6 1 2 3 4 6... Port #6 1 2 3 4 5 1...
#1 2 3 4 5 6 2、を移植してください… #2 3 4 5 6 1 3、を移植してください… #3 4 5 6 1 2 4、を移植してください… #4 5 6 1 2 3 5、を移植してください… #5 6 1 2 3 4 6、を移植してください… #6 1 2 3 4 5 1、を移植してください…
As shown in the table, there is an equal distribution of destination addresses for each transmit opportunity. This keeps the test balanced so that one destination port is not overloaded by the test algorithm and all ports are equally and fully loaded throughout the test. Not following this algorithm exactly will produce inconsistent results.
テーブルにそれぞれのための送付先アドレスの等しい分配があるのを示すように、機会を伝えてください。 これが、テストのバランスをとり続けるので、1つの仕向港はテストアルゴリズムで積みすぎられません、そして、すべてのポートがテストの間中等しさに、そして完全に積み込まれます。 このアルゴリズムに従わないのはまさに結果に一貫性がないでしょう。
For tests using multiple addresses per port, the actual port destinations are the same as described above and the actual source/destination address pairs SHOULD be chosen randomly to exercise the DUT/SUT's ability to perform address lookups.
テストに、1ポートあたりのアドレスで、実際のポートの目的地が説明されるのと同じである倍数と実際のソース/目的地アドレス組SHOULDを使用して、手当たりしだいに選ばれて、アドレスルックアップを実行するDUT/SUTの性能を運動させてください。
For every address, learning frames MUST be sent to the DUT/SUT to allow the DUT/SUT update its address tables properly.
あらゆるアドレスにおいて、適切にDUT/SUTアップデートにアドレス・テーブルを許容するために学習フレームをDUT/SUTに送らなければなりません。
5.1.4 Measurements
5.1.4 測定値
Each port should receive the same number of test frames that it transmitted. Each receiving port MUST categorize, then count the frames into one of two groups:
各ポートはそれが伝えた同じ数のテストフレームを受けるはずです。 各受流口は、2つのグループの1つまでフレームを分類して、次に、数えなければなりません:
1.) Received Frames: received frames MUST have the correct
destination MAC address and SHOULD match a signature field.
1.) 容認されたフレーム: 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。
2.) Flood count [2].
2.) カウント[2]をあふれさせてください。
Mandeville & Perser Informational [Page 5] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[5ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Any frame originating from the DUT/SUT (spanning tree, SNMP, RIP,
...) MUST not be counted as a received frame. Frames originating
from the DUT/SUT MAY be counted as flooded frames or not counted at
all.
DUT/SUT(スパニングツリー、SNMP、RIP)から発するどんなフレーム 容認されたフレームにみなされてはいけません。 水につかっているフレームにみなされたか、または全く数えられなかったDUT/SUT MAYから発するフレーム。
Frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3] with the following notes: Frame loss rate SHOULD be measured at the end of the trail duration. The term "rate", for this measurement only, does not imply the units in the fashion of "per second."
損失率を縁どってください。DUT/SUT SHOULDでは、以下の注意でセクション26.3[3]で定義されるように、報告されてください: 損失率のSHOULDを縁どってください。道の持続時間の終わりでは、測定されます。 この測定だけのために、「レート」という用語は「秒」のファッションでユニットを含意しません。
5.1.4.1 Throughput
5.1.4.1 スループット
Throughput measurement is defined in section 26.1 [3]. A search algorithm is employed to find the maximum Oload [2] with a zero Frame loss rate [1]. The algorithm MUST adjust Iload to find the throughput.
スループット測定はセクション26.1[3]で定義されます。 検索アルゴリズムは、ゼロがある最大のOload[2]がFrame損失率[1]であることがわかるのに使われます。 アルゴリズムは、スループットを見つけるようにIloadを調整しなければなりません。
5.1.4.2 Forwarding Rate
5.1.4.2 伝送速度
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of test frames per second that the device is observed to successfully forward to the correct destination interface in response to a specified Oload. The Oload MUST also be cited.
DUT/SUT SHOULDのレート(FR)を進めて、装置が首尾よく指定されたOloadに対応して正しい目的地のインタフェースに送るために観測される1秒あたりのテストフレームの数として報告されてください。 また、Oloadを引用しなければなりません。
Forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL as defined in section 3.6 [2]. The MOL MUST also be cited.
装置が首尾よく正しい目的地のインタフェースに送られることができる秒あたりのテストフレームの数としてセクション3.6[2]で定義されるMOLに対応して最大の提供された負荷(FRMOL)における伝送速度を報告しなければなりません。 MOL MUST、また、引用されてください。
Maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements. The iterative set of forwarding rate measurements are made by adjusting Iload. The Oload applied to the device MUST also be cited.
繰り返しのセットの伝送速度測定値から抜粋されるDUT/SUTの最も高い伝送速度として最大の伝送速度(MFR)を報告しなければなりません。 Iloadを調整することによって、繰り返しの伝送速度測定をします。 また、装置に適用されたOloadを引用しなければなりません。
5.1.5 Reporting format
5.1.5 書式を報告すること。
The results for these tests SHOULD be reported in the form of a graph. The x coordinate SHOULD be the frame size, the y coordinate SHOULD be the test results. There SHOULD be at least two lines on the graph, one plotting the theoretical and one plotting the test results.
これらのための結果は報告されたコネがグラフのフォームであったならSHOULDをテストします。 xはフレームがサイズであったならSHOULDを調整して、yはテストが結果であったならSHOULDを調整します。 SHOULDは少なくともそこでは、そうです。グラフ、理論上を企む1つ、およびものの試験の成績をプロットする2つの線。
To measure the DUT/SUT's ability to switch traffic while performing many different address lookups, the number of addresses per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
Mandeville & Perser Informational [Page 6] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[6ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.2 Partially meshed one-to-many/many-to-one
5.2 1つへの多くへの部分的にかみ合っているもの/多く
5.2.1 Objective
5.2.1 目的
To determine the throughput when transmitting from/to multiple ports and to/from one port. As with the fully meshed throughput test, this test is a measure of the capability of the DUT to switch frames without frame loss. Results of this test can be used to determine the ability of the DUT to utilize an Ethernet port when switching traffic from multiple Ethernet ports.
/から複数のポートまで1つのポートからの/に送るとき、スループットを測定するために。 完全にかみ合っているスループットテストのように、このテストはDUTがフレームの損失なしでフレームを切り換える能力の測定です。 複数のイーサネットポートから交通を切り換えるときDUTがイーサネットポートを利用する能力を決定するのにこのテストの結果を使用できます。
5.2.2 Setup Parameters
5.2.2 セットアップパラメタ
When offering bursty meshed traffic, the following parameters MUST be defined. Each parameter is configured with the following considerations.
burstyを提供すると交通がかみ合ったとき、以下のパラメタを定義しなければなりません。 各パラメタは以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Traffic Direction - Traffic can be generated in one direction, the
reverse direction, or both directions.
交通Direction--交通は一方向、反対の方向、または方向の両方に発生できます。
Interframe Gap (IFG) - The IFG between frames inside a burst MUST
be at the minimum specified by the standard (9.6 us for 10Mbps
Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps
Ethernet) of the medium being tested.
インターフレームGap(IFG)、--、規格によって指定された最小限には炸裂の中のフレームの間のIFGがあるに違いない(9.6 10Mbpsイーサネットのための私たち、100Mbpsイーサネットのための960ナノ秒、および1つのGbpsイーサネットのための96ナノ秒) テストされる媒体について。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load, regardless of traffic
orientation or duplex mode. Certain test configurations will
theoretically over-subscribe the DUT/SUT.
ILoad--1ポートあたりの意図しているLoadは媒体の最大の理論上の負荷の割合で急送されます、交通オリエンテーションか重複のモードにかかわらず。 あるテスト構成は理論的にDUT/SUTを申し込み過ぎるでしょう。
In half duplex bidirectional traffic, an ILoad over 50% will
over-subscribe the DUT/SUT.
半二重の双方向の交通では、50%以上のILoadはDUT/SUTを申し込み過ぎるでしょう。
Burst Size - The burst size defines the number of frames sent
back-to-back at the minimum legal IFG [4] before pausing
transmission to receive frames. Burst sizes SHOULD vary between 1
and 930 frames. A burst size of 1 will simulate constant load
[1].
Sizeを押し破いてください--放出量はフレーム搬入するためにトランスミッションをポーズする前に最小の法的なIFG[4]に背中合わせの状態で送られたフレームの数を定義します。 放出量SHOULDは1〜930個のフレームを変えます。 1の放出量は一定の負荷[1]をシミュレートするでしょう。
Mandeville & Perser Informational [Page 7] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[7ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Addresses per port - Represents the number of addresses which are
being tested for each port. Number of addresses SHOULD be a
binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...).
Recommended value is 1.
1ポートあたりのアドレス--各ポートがないかどうかテストされているアドレスの数を表します。 数、アドレスSHOULDでは、aバイナリー指数になってください(すなわち、1、2、4、8、16、32、64、128、256)。 推奨値は1です。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
5.2.3 Procedure
5.2.3 手順
All ports on the tester MUST transmit test frames either in a Frame Based or Time Based mode (Appendix B). Depending upon traffic direction, some or all of the ports will be transmitting. All ports SHOULD start transmitting their frames within 1% of the trial duration. For a trial duration of 30 seconds, all ports SHOULD have started transmitting frames within 300 milliseconds of each other.
Frame BasedかTime Basedモード(付録B)でテスターの上のポートが伝えなければならないすべてがフレームをテストします。 交通方向によって、ポートのいくつかかすべてが伝わるでしょう。 すべてが、トライアル持続時間の1%以内でそれらのフレームを伝えながら、SHOULD始めを移植します。 30秒、SHOULDが互いの300ミリセカンド以内でフレームを伝え始めたすべてのポートのトライアル持続時間のために。
Test frames transmitted from the Many Ports MUST be destined to the One port. Test frames transmitted from the One Port MUST be destined to the Many ports in a round robin type fashion. See section 5.1.3 for a description of the round robin fashion.
Many Portsから伝えられたテストフレームをOneポートに運命づけなければなりません。 連続タイプファッションでOne Portから伝えられたテストフレームをManyポートに運命づけなければなりません。 連続ファッションの記述に関してセクション5.1.3を見てください。
For tests using multiple addresses per port, the actual port destinations are the same as described above and the actual source/destination address pairs SHOULD be chosen randomly to exercise the DUT/SUT's ability to perform address lookups.
テストに、1ポートあたりのアドレスで、実際のポートの目的地が説明されるのと同じである倍数と実際のソース/目的地アドレス組SHOULDを使用して、手当たりしだいに選ばれて、アドレスルックアップを実行するDUT/SUTの性能を運動させてください。
+----------+
| |
| Many | <--------
| | \
+----------+ \
\
+----------+ \ +-------------+
| | ------------> | |
| Many | <-----------------------> | One |
| | ------------> | |
+----------+ / +-------------+
/
+----------+ /
| | /
| Many | <-------
| |
+----------+
+----------+ | | | 多く| <、-、-、-、-、-、-、--、|、| \ +----------+ \ \ +----------+ \ +-------------+ | | ------------>|、|、| 多く| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 1つ| | | ------------>|、| +----------+ / +-------------+ / +----------+ / | | / | 多く| <、-、-、-、-、-、--、|、| +----------+
For every address, the testing device MUST send learning frames to allow the DUT/SUT to update its address tables properly.
あらゆるアドレス、テスト装置がDUT/SUTが適切にアドレス・テーブルをアップデートするのを許容するために学習フレームを送らなければならないので。
Mandeville & Perser Informational [Page 8] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[8ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.2.4 Measurements
5.2.4 測定値
Each receiving port MUST categorize, then count the frames into one of two groups:
各受流口は、2つのグループの1つまでフレームを分類して、次に、数えなければなりません:
1.) Received Frames: received frames MUST have the correct
destination MAC address and SHOULD match a signature field.
1.) 容認されたフレーム: 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。
2.) Flood count [2].
2.) カウント[2]をあふれさせてください。
Any frame originating from the DUT/SUT MUST not be counted as a received frame. Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all.
いずれも容認されたフレームにみなされなくDUT/SUT MUSTからの由来を縁どっています。 水につかっているフレームにみなされたか、または全く数えられなかったDUT/SUT MAYから発するフレーム。
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of test frames per second that the device is observed to successfully transmit to the correct destination interface in response to a specified Oload. The Oload MUST also be cited.
DUT/SUT SHOULDのレート(FR)を進めて、装置が首尾よく指定されたOloadに対応して正しい目的地のインタフェースに伝わるのが観測される秒あたりのテストフレームの数として報告されてください。 また、Oloadを引用しなければなりません。
Forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL as defined in section 3.6 [2]. The MOL MUST also be cited.
装置が首尾よく正しい目的地のインタフェースに送られることができる秒あたりのテストフレームの数としてセクション3.6[2]で定義されるMOLに対応して最大の提供された負荷(FRMOL)における伝送速度を報告しなければなりません。 MOL MUST、また、引用されてください。
Maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements. The iterative set of forwarding rate measurements are made by adjusting Iload. The Oload applied to the device MUST also be cited.
繰り返しのセットの伝送速度測定値から抜粋されるDUT/SUTの最も高い伝送速度として最大の伝送速度(MFR)を報告しなければなりません。 Iloadを調整することによって、繰り返しの伝送速度測定をします。 また、装置に適用されたOloadを引用しなければなりません。
5.2.5 Reporting Format
5.2.5 書式を報告すること。
The results for these tests SHOULD be reported in the form of a graph. The x coordinate SHOULD be the frame size, the y coordinate SHOULD be the test results. There SHOULD be at least two lines on the graph, one plotting the theoretical and one plotting the test results.
これらのための結果は報告されたコネがグラフのフォームであったならSHOULDをテストします。 xはフレームがサイズであったならSHOULDを調整して、yはテストが結果であったならSHOULDを調整します。 SHOULDは少なくともそこでは、そうです。グラフ、理論上を企む1つ、およびものの試験の成績をプロットする2つの線。
To measure the DUT/SUT's ability to switch traffic while performing many different address lookups, the number of addresses per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
Mandeville & Perser Informational [Page 9] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[9ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.3 Partially meshed multiple devices
5.3は複数の装置を部分的に網の目にかけました。
5.3.1 Objective
5.3.1 目的
To determine the throughput, frame loss and forwarding rates of two switching devices equipped with multiple ports and one high speed backbone uplink (Gigabit Ethernet, ATM, SONET).
2個の切換装置のスループット、フレームの損失、および伝送速度を測定するのは複数のポートと1つの高速背骨アップリンク(ギガビットイーサネット、ATM、Sonet)を備えていました。
5.3.2 Setup Parameters
5.3.2 セットアップパラメタ
When offering bursty partially meshed traffic, the following parameters MUST be defined. Each variable is configured with the following considerations.
burstyを提供すると交通が部分的にかみ合ったとき、以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Interframe Gap (IFG) - The IFG between frames inside a burst MUST
be at the minimum specified by the standard (9.6 us for 10Mbps
Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps
Ethernet) of the medium being tested.
インターフレームGap(IFG)、--、規格によって指定された最小限には炸裂の中のフレームの間のIFGがあるに違いない(9.6 10Mbpsイーサネットのための私たち、100Mbpsイーサネットのための960ナノ秒、および1つのGbpsイーサネットのための96ナノ秒) テストされる媒体について。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load, regardless of traffic
orientation or duplex mode. Certain test configurations will
theoretically over-subscribe the DUT/SUT.
ILoad--1ポートあたりの意図しているLoadは媒体の最大の理論上の負荷の割合で急送されます、交通オリエンテーションか重複のモードにかかわらず。 あるテスト構成は理論的にDUT/SUTを申し込み過ぎるでしょう。
In half duplex, an ILoad over 50% will over-subscribe the DUT/SUT.
半二重では、50%以上のILoadはDUT/SUTを申し込み過ぎるでしょう。
Burst Size - The burst size defines the number of frames sent
back-to-back at the minimum legal IFG [4] before pausing
transmission to receive frames. Burst sizes SHOULD vary between 1
and 930 frames. A burst size of 1 will simulate constant load
[1].
Sizeを押し破いてください--放出量はフレーム搬入するためにトランスミッションをポーズする前に最小の法的なIFG[4]に背中合わせの状態で送られたフレームの数を定義します。 放出量SHOULDは1〜930個のフレームを変えます。 1の放出量は一定の負荷[1]をシミュレートするでしょう。
Addresses per port - Represents the number of addresses which are
being tested for each port. Number of addresses SHOULD be a
binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...).
Recommended value is 1.
1ポートあたりのアドレス--各ポートがないかどうかテストされているアドレスの数を表します。 数、アドレスSHOULDでは、aバイナリー指数になってください(すなわち、1、2、4、8、16、32、64、128、256)。 推奨値は1です。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
Mandeville & Perser Informational [Page 10] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[10ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Local Traffic - A Boolean value of ON or OFF. The frame sequence
algorithm MAY be altered to remove local traffic. With local
traffic ON, the algorithm is exactly the same as a fully meshed
throughput. With local traffic OFF, the port sends frames to all
other ports on the other side of the backbone uplink in a round
robin type fashion.
地方のTraffic--ONかOFFのブール値。 フレーム系列アルゴリズムは、ローカルの交通を取り除くために変更されるかもしれません。 ローカルの交通ONで、アルゴリズムはまさに完全にかみ合っているスループットと同じです。 ローカルの交通OFFと共に、ポートは背骨アップリンクの反対側の上の他のすべてのポートに連続タイプファッションでフレームを送信します。
5.3.3 Procedure
5.3.3 手順
All ports on the tester MUST transmit test frames either in a Frame Based or Time Based mode (Appendix B). All ports SHOULD start transmitting their frames within 1% of the trial duration. For a trial duration of 30 seconds, all ports SHOULD have started transmitting frames with 300 milliseconds of each other.
Frame BasedかTime Basedモード(付録B)でテスターの上のポートが伝えなければならないすべてがフレームをテストします。 すべてが、トライアル持続時間の1%以内でそれらのフレームを伝えながら、SHOULD始めを移植します。 30秒、SHOULDが互いの300ミリセカンドがいるフレームを伝え始めたすべてのポートのトライアル持続時間のために。
Each port in the test MUST send test frames to all other ports in a round robin type fashion as defined in section 5.1.3. Local traffic MAY be removed from the round robin list in order to send the entire load across the backbone uplink.
テストにおける各ポートはセクション5.1.3で定義されるように連続タイプファッションで他のすべてのポートにテストフレームを送らなければなりません。 背骨アップリンクの向こう側に全体の負荷を送るために連続リストからローカルの交通を取り除くかもしれません。
For tests using multiple addresses per port, the actual port destinations are the same as described above and the actual source/destination address pairs SHOULD be chosen randomly to exercise the DUT/SUT's ability to perform address lookups.
テストに、1ポートあたりのアドレスで、実際のポートの目的地が説明されるのと同じである倍数と実際のソース/目的地アドレス組SHOULDを使用して、手当たりしだいに選ばれて、アドレスルックアップを実行するDUT/SUTの性能を運動させてください。
For every address, the testing device MUST send learning frames to allow the DUT/SUT to update its address tables properly.
あらゆるアドレス、テスト装置がDUT/SUTが適切にアドレス・テーブルをアップデートするのを許容するために学習フレームを送らなければならないので。
To measure the DUT/SUT's ability to switch traffic while performing many different address lookups, the number of addresses per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
5.3.4 Measurements
5.3.4 測定値
Each receiving port MUST categorize, then count the frames into one of two groups:
各受流口は、2つのグループの1つまでフレームを分類して、次に、数えなければなりません:
1.) Received frames MUST have the correct destination MAC address
and SHOULD match a signature field.
1.) 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。
2.) Flood count [2].
2.) カウント[2]をあふれさせてください。
Any frame originating from the DUT/SUT MUST not be counted as a received frame. Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all.
いずれも容認されたフレームにみなされなくDUT/SUT MUSTからの由来を縁どっています。 水につかっているフレームにみなされたか、または全く数えられなかったDUT/SUT MAYから発するフレーム。
Mandeville & Perser Informational [Page 11] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[11ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3] with the following notes: Frame loss rate SHOULD be measured at the end of the trial duration. The term "rate", for this measurement only, does not imply the units in the fashion of "per second."
損失率を縁どってください。DUT/SUT SHOULDでは、以下の注意でセクション26.3[3]で定義されるように、報告されてください: 損失率のSHOULDを縁どってください。トライアル持続時間の終わりでは、測定されます。 この測定だけのために、「レート」という用語は「秒」のファッションでユニットを含意しません。
5.3.4.1 Throughput
5.3.4.1 スループット
Throughput measurement is defined in section 26.1 [3]. A search algorithm is employed to find the maximum Oload [2] with a zero Frame loss rate [1]. The algorithm MUST adjust Iload to find the throughput.
スループット測定はセクション26.1[3]で定義されます。 検索アルゴリズムは、ゼロがある最大のOload[2]がFrame損失率[1]であることがわかるのに使われます。 アルゴリズムは、スループットを見つけるようにIloadを調整しなければなりません。
5.3.4.2 Forwarding rate
5.3.4.2 伝送速度
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of test frames per second that the device is observed to successfully forward to the correct destination interface in response to a specified Oload. The Oload MUST also be cited.
DUT/SUT SHOULDのレート(FR)を進めて、装置が首尾よく指定されたOloadに対応して正しい目的地のインタフェースに送るために観測される1秒あたりのテストフレームの数として報告されてください。 また、Oloadを引用しなければなりません。
Forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL as defined in section 3.6 [2]. The MOL MUST also be cited.
装置が首尾よく正しい目的地のインタフェースに送られることができる秒あたりのテストフレームの数としてセクション3.6[2]で定義されるMOLに対応して最大の提供された負荷(FRMOL)における伝送速度を報告しなければなりません。 MOL MUST、また、引用されてください。
Maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements. The iterative set of forwarding rate measurements are made by adjusting Iload. The Oload applied to the device MUST also be cited.
繰り返しのセットの伝送速度測定値から抜粋されるDUT/SUTの最も高い伝送速度として最大の伝送速度(MFR)を報告しなければなりません。 Iloadを調整することによって、繰り返しの伝送速度測定をします。 また、装置に適用されたOloadを引用しなければなりません。
5.3.5 Reporting format
5.3.5 書式を報告すること。
The results for these tests SHOULD be reported in the form of a graph. The x coordinate SHOULD be the frame size, the y coordinate SHOULD be the test results. There SHOULD be at least two lines on the graph, one plotting the theoretical and one plotting the test results.
これらのための結果は報告されたコネがグラフのフォームであったならSHOULDをテストします。 xはフレームがサイズであったならSHOULDを調整して、yはテストが結果であったならSHOULDを調整します。 SHOULDは少なくともそこでは、そうです。グラフ、理論上を企む1つ、およびものの試験の成績をプロットする2つの線。
To measure the DUT/SUT's ability to switch traffic while performing many different address lookups, the number of addresses per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
Mandeville & Perser Informational [Page 12] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[12ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.4 Partially meshed unidirectional traffic
5.4 部分的にかみ合っている単方向の交通
5.4.1 Objective
5.4.1 目的
To determine the throughput of the DUT/SUT when presented multiple streams of unidirectional traffic with half of the ports on the DUT/SUT are transmitting frames destined to the other half of the ports.
半分のポートがオンな状態で単方向の交通の複数の流れが提示されるとき、DUT/SUTに関するスループットを測定するために、DUT/SUTはポートのもう片方の半分に運命づけられたフレームを伝えています。
5.4.2 Setup Parameters
5.4.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Interframe Gap (IFG) - The IFG between frames inside a burst MUST
be at the minimum specified by the standard (9.6 us for 10Mbps
Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps
Ethernet) of the medium being tested.
インターフレームGap(IFG)、--、規格によって指定された最小限には炸裂の中のフレームの間のIFGがあるに違いない(9.6 10Mbpsイーサネットのための私たち、100Mbpsイーサネットのための960ナノ秒、および1つのGbpsイーサネットのための96ナノ秒) テストされる媒体について。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load, regardless of traffic
orientation or duplex mode. Certain test configurations will
theoretically over-subscribe the DUT/SUT.
ILoad--1ポートあたりの意図しているLoadは媒体の最大の理論上の負荷の割合で急送されます、交通オリエンテーションか重複のモードにかかわらず。 あるテスト構成は理論的にDUT/SUTを申し込み過ぎるでしょう。
ILoad will not over-subscribe the DUT/SUT in this test.
ILoadはこのテストでDUT/SUTを申し込み過ぎないでしょう。
Burst Size - The burst size defines the number of frames sent
back-to-back at the minimum legal IFG [4] before pausing
transmission to receive frames. Burst sizes SHOULD vary between 1
and 930 frames. A burst size of 1 will simulate constant load
[1].
Sizeを押し破いてください--放出量はフレーム搬入するためにトランスミッションをポーズする前に最小の法的なIFG[4]に背中合わせの状態で送られたフレームの数を定義します。 放出量SHOULDは1〜930個のフレームを変えます。 1の放出量は一定の負荷[1]をシミュレートするでしょう。
Addresses per port - Represents the number of addresses which are
being tested for each port. Number of addresses SHOULD be a
binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...).
Recommended value is 1.
1ポートあたりのアドレス--各ポートがないかどうかテストされているアドレスの数を表します。 数、アドレスSHOULDでは、aバイナリー指数になってください(すなわち、1、2、4、8、16、32、64、128、256)。 推奨値は1です。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
Mandeville & Perser Informational [Page 13] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[13ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.4.3 Procedure
5.4.3 手順
Ports do not send and receive test frames simultaneously. As a
consequence, there should be no collisions unless the DUT is
misforwarding frames, generating flooded or Spanning-Tree frames
or is enabling some flow control mechanism. Ports used for this
test are either transmitting or receiving, but not both. Those
ports which are transmitting send test frames destined to
addresses corresponding to each of the ports receiving. This
creates a unidirectional mesh of traffic.
ポートは、同時に、テストフレームを送って、受けません。 結果として、DUTがフレームをmisforwardingしていない場合、衝突が全くあるべきではありません、と発生があふれさせたか、またはSpanning-木は、何らかのフロー制御メカニズムを縁どっているか、可能にしています。 このテストに使用されるポートは、伝わるか、または受信しますが、ともに受信されているというわけではありません。 伝わっているそれらのポートで、それぞれのポートに対応するアドレスに運命づけられたテストフレームは受信されます。 これは交通の単方向のメッシュを作成します。
All ports on the tester MUST transmit test frames either in a
Frame Based or Time Based mode (Appendix B). All ports SHOULD
start transmitting their frames within 1% of the trial duration.
For a trial duration of 30 seconds, all ports SHOULD have started
transmitting frames with 300 milliseconds of each other.
Frame BasedかTime Basedモード(付録B)でテスターの上のポートが伝えなければならないすべてがフレームをテストします。 すべてが、トライアル持続時間の1%以内でそれらのフレームを伝えながら、SHOULD始めを移植します。 30秒、SHOULDが互いの300ミリセカンドがいるフレームを伝え始めたすべてのポートのトライアル持続時間のために。
Each transmitting port in the test MUST send frames to all
receiving ports in a round robin type fashion. The sequence of
addresses MUST NOT change when congestion control is applied.
The following table shows how each port in a test MUST transmit
test frames to all other ports in the test. In this 8 port
example, port 1 through 4 are transmitting and ports 5 through 8
are receiving; each with 1 address per port:
テストにおけるポートが送らなければならない各伝えることは連続タイプファッションですべての受流口に縁どられます。 アドレスの系列は、輻輳制御がいつ適用されているかを変えてはいけません。 以下のテーブルはテストにおける各ポートがテストで他のすべてのポートにどうテストフレームを送らなければならないかを示しています。 この8ポートの例、1〜4が伝えているポート、およびポートでは、5〜8は受信されています。 それぞれ1で、ポート単位で以下を記述してください。
Source Port, then Destination Ports (in order of transmission)
ソースPort、当時のDestination Ports(トランスミッションの順に)
Port #1 5 6 7 8 5 6...
Port #2 6 7 8 5 6 7...
Port #3 7 8 5 6 7 8...
Port #4 8 5 6 7 8 5...
#1 5 6 7 8 5 6、を移植してください… #2 6 7 8 5 6 7、を移植してください… #3 7 8 5 6 7 8、を移植してください… #4 8 5 6 7 8 5、を移植してください…
As shown in the table, there is an equal distribution of
destination addresses for each transmit opportunity. This keeps
the test balanced so that one destination port is not overloaded
by the test algorithm and all receiving ports are equally and
fully loaded throughout the test. Not following this algorithm
exactly will product inconsistent results.
テーブルにそれぞれのための送付先アドレスの等しい分配があるのを示すように、機会を伝えてください。 これが、テストのバランスをとり続けるので、1つの仕向港はテストアルゴリズムで積みすぎられません、そして、すべての受流口がテストの間中等しさに、そして完全に積み込まれます。 このアルゴリズムに従わないのはまさに製品の矛盾した結果がそうするでしょう。
For tests using multiple addresses per port, the actual port
destinations are the same as described above and the actual
source/destination address pairs SHOULD be chosen randomly to
exercise the DUT/SUT's ability to perform address lookups.
テストに、1ポートあたりのアドレスで、実際のポートの目的地が説明されるのと同じである倍数と実際のソース/目的地アドレス組SHOULDを使用して、手当たりしだいに選ばれて、アドレスルックアップを実行するDUT/SUTの性能を運動させてください。
For every address, the testing device MUST send learning frames to
allow the DUT/SUT to load its address tables properly. The
address table's aging time SHOULD be set sufficiently longer than
あらゆるアドレス、テスト装置がDUT/SUTが適切にアドレス・テーブルを積み込むのを許容するために学習フレームを送らなければならないので。 セットが十分長かったなら、アドレステーブルは古い時間SHOULDです。
Mandeville & Perser Informational [Page 14] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[14ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
the learning time and trial duration time combined. If the
address table ages out during the test, the results will show a
lower performing DUT/SUT.
学習時間とトライアル持続時間は結合しました。 アドレス・テーブルがテストの間の外で老朽化すると、結果は下側の実行DUT/SUTを見せるでしょう。
To measure the DUT/SUT's ability to switch traffic while
performing many different address lookups, the number of addresses
per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
5.4.4 Measurements
5.4.4 測定値
Each receiving port MUST categorize, then count the frames into
one of two groups:
各受流口は、2つのグループの1つまでフレームを分類して、次に、数えなければなりません:
1.) Received Frames: received frames MUST have the correct
destination MAC address and SHOULD match a signature field.
1.) 容認されたフレーム: 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。
2.) Flood count [2].
2.) カウント[2]をあふれさせてください。
Any frame originating from the DUT/SUT MUST not be counted as a received frame. Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all.
いずれも容認されたフレームにみなされなくDUT/SUT MUSTからの由来を縁どっています。 水につかっているフレームにみなされたか、または全く数えられなかったDUT/SUT MAYから発するフレーム。
Frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3] with the following notes: Frame loss rate SHOULD be measured at the end of the trial duration. The term "rate", for this measurement only, does not imply the units in the fashion of "per second."
損失率を縁どってください。DUT/SUT SHOULDでは、以下の注意でセクション26.3[3]で定義されるように、報告されてください: 損失率のSHOULDを縁どってください。トライアル持続時間の終わりでは、測定されます。 この測定だけのために、「レート」という用語は「秒」のファッションでユニットを含意しません。
5.4.4.1 Throughput
5.4.4.1 スループット
Throughput measurement is defined in section 26.1 [3]. A search algorithm is employed to find the maximum Oload [2] with a zero Frame loss rate [1]. The algorithm MUST adjust Iload to find the throughput.
スループット測定はセクション26.1[3]で定義されます。 検索アルゴリズムは、ゼロがある最大のOload[2]がFrame損失率[1]であることがわかるのに使われます。 アルゴリズムは、スループットを見つけるようにIloadを調整しなければなりません。
5.4.4.2 Forwarding rate
5.4.4.2 伝送速度
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of test frames per second that the device is observed to successfully forward to the correct destination interface in response to a specified Oload. The Oload MUST also be cited.
DUT/SUT SHOULDのレート(FR)を進めて、装置が首尾よく指定されたOloadに対応して正しい目的地のインタフェースに送るために観測される1秒あたりのテストフレームの数として報告されてください。 また、Oloadを引用しなければなりません。
Forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL as defined in section 3.6 [2]. The MOL MUST also be cited.
装置が首尾よく正しい目的地のインタフェースに送られることができる秒あたりのテストフレームの数としてセクション3.6[2]で定義されるMOLに対応して最大の提供された負荷(FRMOL)における伝送速度を報告しなければなりません。 MOL MUST、また、引用されてください。
Mandeville & Perser Informational [Page 15] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[15ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements. The iterative set of forwarding rate measurements are made by adjusting Iload. The Oload applied to the device MUST also be cited.
繰り返しのセットの伝送速度測定値から抜粋されるDUT/SUTの最も高い伝送速度として最大の伝送速度(MFR)を報告しなければなりません。 Iloadを調整することによって、繰り返しの伝送速度測定をします。 また、装置に適用されたOloadを引用しなければなりません。
5.4.5 Reporting format
5.4.5 書式を報告すること。
The results for these tests SHOULD be reported in the form of a graph. The x coordinate SHOULD be the frame size, the y coordinate SHOULD be the test results. There SHOULD be at least two lines on the graph, one plotting the theoretical and one plotting the test results.
これらのための結果は報告されたコネがグラフのフォームであったならSHOULDをテストします。 xはフレームがサイズであったならSHOULDを調整して、yはテストが結果であったならSHOULDを調整します。 SHOULDは少なくともそこでは、そうです。グラフ、理論上を企む1つ、およびものの試験の成績をプロットする2つの線。
To measure the DUT/SUT's ability to switch traffic while performing many different address lookups, the number of addresses per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
5.5 Congestion Control
5.5 輻輳制御
5.5.1 Objective
5.5.1 目的
To determine how a DUT handles congestion. Does the device implement congestion control and does congestion on one port affect an uncongested port. This procedure determines if Head of Line Blocking and/or Backpressure are present.
DUTがどのように混雑を扱うかを決定するために。 装置は輻輳制御を実行します、そして、1つのポートにおける混雑は非充血しているポートに影響しますか? この手順は、Blocking、そして/または、Backpressureが線のHeadであるなら存在していることを決定します。
5.5.2 Setup Parameters
5.5.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Interframe Gap (IFG) - The IFG between frames inside a burst MUST
be at the minimum specified by the standard (9.6 us for 10Mbps
Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps
Ethernet) of the medium being tested.
インターフレームGap(IFG)、--、規格によって指定された最小限には炸裂の中のフレームの間のIFGがあるに違いない(9.6 10Mbpsイーサネットのための私たち、100Mbpsイーサネットのための960ナノ秒、および1つのGbpsイーサネットのための96ナノ秒) テストされる媒体について。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
Addresses per port - Represents the number of addresses which are
being tested for each port. Number of addresses SHOULD be a
binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...).
Recommended value is 1.
1ポートあたりのアドレス--各ポートがないかどうかテストされているアドレスの数を表します。 数、アドレスSHOULDでは、aバイナリー指数になってください(すなわち、1、2、4、8、16、32、64、128、256)。 推奨値は1です。
Mandeville & Perser Informational [Page 16] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[16ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
5.5.3 Procedure
5.5.3 手順
This test MUST consist of a multiple of four ports with the same MOL. Four ports are REQUIRED and MAY be expanded to fully utilize the DUT/SUT in increments of four. Each group of four will contain a test block with two of the ports as source transmitters and two of the ports as receivers. The diagram below depicts the flow of traffic between the switch ports:
このテストは同じMOLと共に4つのポートの倍数から成らなければなりません。 4つのポートが、REQUIREDであり、4の増分でDUT/SUTを完全に利用するために広げられるかもしれません。 各4人のグループがソース送信機と受信機としての2つのポートとして2つのポートがあるテストブロックを含むでしょう。 以下のダイヤグラムはスイッチポートの間の交通の流れについて表現します:
+----------+ 50 % MOL +-------------+
| | ------------------------> | |
| | 50 % MOL | uncongested |
| | --------- | |
+----------+ \ +-------------+
\
\
\
+----------+ \ +-------------+
| | ---------> | |
| | 100 % MOL | congested |
| | ------------------------> | |
+----------+ +-------------+
+----------+ 50%のmol+-------------+ | | ------------------------>|、|、|、| 50%のmol| 非充血しました。| | | --------- | | +----------+ \ +-------------+ \ \ \ +----------+ \ +-------------+ | | --------->|、|、|、| 100%のmol| 充血します。| | | ------------------------>|、| +----------+ +-------------+
Both source transmitters MUST transmit the exact number of test frames. The first source MUST transmit test frames at the MOL with the destination address of the two receive ports in an alternating order. The first test frame to the uncongested receive port, second test frame to the congested receive port, then repeat. The second source transmitter MUST transmit test frames at the MOL only to the congested receive port.
両方のソース送信機はテストフレームのはっきりした数を伝えなければなりません。 交替が2つのもののアドレスがポートを受ける目的地を命令していて、最初の情報筋はMOLでテストフレームを伝えなければなりません。 非充血への一次テストフレームがポートを受けて、混雑への2番目のテストフレームは、ポートを受けて、次に、繰り返されます。 セカンドソース送信機はMOLでテストフレームを混雑だけに送信しなければなりません。ポートを受けてください。
Both receive ports SHOULD distinguish between test frames originating from the source ports and frames originating from the DUT/SUT. Only test frames from the source ports SHOULD be counted.
両方がSHOULDがソース港から発するテストフレームとDUT/SUTから発するフレームの間で区別するポートを受けます。 ソースからのテストフレームだけがSHOULDを移植します。数えられます。
The uncongested receive port should be receiving at a rate of half the MOL. The number of test frames received on the uncongested port SHOULD be 50% of the test frames transmitted by the first source transmitter. The congested receive port should be receiving at the MOL. The number of test frames received on the congested port should be between 100% and 150% of the test frames transmitted by one source transmitter.
非充血は半分のレートで受信するのが、MOLであったならポートを受けます。 テストの50%がフレームであったなら非充血しているポートSHOULDに受け取られたテストフレームの数は最初のソース送信機で伝わりました。 混雑はポートを受けます。MOLで受信するべきです。 混雑しているポートの上に受け取られたテストフレームの数が1個のソース送信機によって伝えられたテストフレームの100%と150%の間あるべきです。
Mandeville & Perser Informational [Page 17] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[17ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Test frames destined to uncongested ports in a switch device should not be dropped due to other ports being congested, even if the source is sending to both the congested and uncongested ports.
充血する他のポートのためスイッチ装置の非充血しているポートに運命づけられたテストフレームを落とすべきではありません、ソースが混雑していて非充血しているポートに発信しても。
5.5.4 Measurements
5.5.4 測定値
Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count.
正しい送付先アドレスを持っていない受け取られたどんなフレームも洪水カウントの一部にみなされた状態で容認されたフレームとSHOULDにみなしてはいけません。
Any frame originating from the DUT/SUT MUST not be counted as a received frame. Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all.
いずれも容認されたフレームにみなされなくDUT/SUT MUSTからの由来を縁どっています。 水につかっているフレームにみなされたか、または全く数えられなかったDUT/SUT MAYから発するフレーム。
Frame loss rate of the DUT/SUT's congested and uncongested ports MUST be reported as defined in section 26.3 [3] with the following notes: Frame loss rate SHOULD be measured at the end of the trial duration. The term "rate", for this measurement only, does not imply the units in the fashion of "per second."
DUT/SUTの損失率を充血させて、非充血しているポートを報告しなければならないフレームは以下の注意でセクションで26.3[3]を定義しました: 損失率のSHOULDを縁どってください。トライアル持続時間の終わりでは、測定されます。 この測定だけのために、「レート」という用語は「秒」のファッションでユニットを含意しません。
Offered Load to the DUT/SUT MUST be reported as the number of test frames per second that the DUT/SUT observed to accept. This may be different that the MOL.
LoadをDUT/SUT MUSTに提供して、DUT/SUTが見た秒あたりのテストフレームの数として受け入れると報告されてください。 これが異なるかもしれない、それ、MOL。
Forwarding rate (FR) of the DUT/SUT's congested and uncongested ports MUST be reported as the number of test frames per second that the device is observed to successfully transmit to the correct destination interface in response to a specified offered load. The offered load MUST also be cited.
DUT/SUTの伝送速度(FR)は充血しました、そして、装置が首尾よく指定された提供された負荷に対応して正しい目的地のインタフェースに伝わるのが観測される秒あたりのテストフレームの数として非充血しているポートを報告しなければなりません。 また、提供された負荷を引用しなければなりません。
5.5.5 Reporting format
5.5.5 書式を報告すること。
This test MUST report the frame lost rate at the uncongested port, the forwarding rate (at 50% offered load) at the uncongested port, and the frame lost rate at the congested port. This test MAY report the frame counts transmitted and frame counts received by the DUT/SUT.
このテストは、フレームが非充血しているポートで非充血しているポートのレート、伝送速度(50%提供された負荷における)を失ったと報告しなければなりません、そして、フレームは混雑しているポートでレートを失いました。 このテストは、フレームカウントが伝わって、フレームカウントがDUT/SUTのそばで受信されたと報告するかもしれません。
5.5.5.1 HOLB
5.5.5.1 HOLB
If there is frame loss at the uncongested port, "Head of Line" blocking is present. The DUT cannot forward the amount of traffic to the congested port and as a result it is also losing frames destined to the uncongested port.
フレームの損失が非充血しているポートにあれば、「線のヘッド」ブロッキングは存在しています。 DUTは交通の量を混雑しているポートに送ることができません、そして、その結果、また、それは非充血しているポートに運命づけられたフレームをなくしています。
Mandeville & Perser Informational [Page 18] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[18ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.5.5.2 Back Pressure
5.5.5.2 逆圧
If there is no frame loss on the congested port, then backpressure is present. It should be noted that this test expects the overall load to the congested port to be greater than 100%. Therefore if the load is greater than 100% and no frame loss is detected, then the DUT must be implementing a flow control mechanism. The type of flow control mechanism used is beyond the scope of this memo.
混雑しているポートの上にフレームの損失が全くなければ、背圧は存在しています。 このテストが、混雑しているポートへの総合的な負荷が100%以上であると予想することに注意されるべきです。 したがって、負荷が100%以上であり、フレームの損失が全く検出されないなら、DUTはフロー制御メカニズムを実行しなければなりません。 使用されるフロー制御メカニズムのタイプはこのメモの範囲を超えています。
It should be noted that some DUTs may not be able to handle the 100% load presented at the input port. In this case, there may be frame loss reported at the uncongested port which is due to the load at the input port rather than the congested port's load.
いくつかのDUTsが入力ポートに提示された100%の負荷を扱うことができないかもしれないことに注意されるべきです。 この場合、負荷のためである非充血しているポートで報告されたフレームの損失が混雑しているポートの負荷よりむしろ入力ポートにあるかもしれません。
If the uncongested frame loss is reported as zero, but the maximum forwarding rate is less than 7440 (for 10Mbps Ethernet), then this may be an indication of congestion control being enforced by the DUT. In this case, the congestion control is affecting the throughput of the uncongested port.
非充血しているフレームの損失がゼロとして報告されますが、最大の伝送速度が7440(10Mbpsイーサネットのための)未満であるなら、これはDUTによって励行される輻輳制御のしるしであるかもしれません。 この場合、輻輳制御は非充血しているポートに関するスループットに影響しています。
If no congestion control is detected, the expected percentage frame loss for the congested port is 33% at 150% overload. It is receiving 100% load from 1 port, and 50% from another, and can only get 100% possible throughput, therefore having a frame loss rate of 33% (150%-50%/150%).
輻輳制御が全く検出されないなら、混雑しているポートのための予想された割合フレームの損失は150%のオーバーロードで33%です。 それは、1つのポートから100%の負荷を受け取って、別のものから50%を受け取っていて、100%の可能なスループットを得ることができるだけです、したがって、33%(150%から50%/150%)のフレーム損失率を持っています。
5.6 Forward Pressure and Maximum Forwarding Rate
5.6 前進の圧力と最大の伝送速度
5.6.1 Objective
5.6.1 目的
The Forward Pressure test overloads a DUT/SUT port and measures the output for forward pressure [2]. If the DUT/SUT transmits frames with an interframe gap less than 96 bits (section 4.2.3.2.2 [4]), then forward pressure is detected.
Forward Pressureテストは、DUT/SUTポートを積みすぎて、前進の圧力[2]のための出力を測定します。 DUT/SUTが96ビット未満のインターフレーム隙間でフレームを伝える、(セクション4.2 .3 .2 .2 [4]) そして、前進の圧力は検出されます。
The objective of the Maximum Forwarding Rate test is to measure the peak value of the Forwarding Rate when the Offered Load is varied between the throughput [1] and the Maximum Offered Load [2].
Maximum Forwarding Rateテストの目的はOffered Loadがスループット[1]とMaximum Offered Load[2]の間で変えられるとき、Forwarding Rateのピーク値を測定することです。
5.6.2 Setup Parameters
5.6.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Mandeville & Perser Informational [Page 19] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[19ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
Step Size - The minimum incremental resolution that the Iload will
be incremented in frames per second. The smaller the step size,
the more accurate the measurement and the more iterations
required. As the Iload approaches the MOL, the minimum step size
will increase because of gap resolution on the testing device.
Sizeを踏んでください--Iloadが1秒あたりのフレームで増加されるという最小の増加の解決。 ステップサイズが小さければ小さいほど、測定が、より正確であり、より多くの繰り返しが必要です。 IloadがMOLにアプローチするのに従って、最小のステップサイズはギャップ解決でテスト装置で増加するでしょう。
5.6.3 Procedure
5.6.3 手順
5.6.3.1 Maximum forwarding rate
5.6.3.1 最大の伝送速度
If the Throughput [1] and the MOL [2] are the same, then MFR [2] is equal to the MOL [2].
Throughput[1]とMOL[2]が同じであるなら、MFR[2]はMOL[2]と等しいです。
This test MUST at a minimum be performed in a two-port configuration as described below. Learning frames MUST be sent to allow the DUT/SUT to update its address tables properly.
以下で説明されるように最小限で2ポートの構成でこのテストを実行しなければなりません。 DUT/SUTが適切にアドレス・テーブルをアップデートするのを許容するために学習フレームを送らなければなりません。
Test frames are transmitted to the first port (port 1) of the DUT/SUT at the Iload. The FR [2] on the second port (port 2) of the DUT/SUT is measured. The Iload is incremented for each Step Size to find the MFR. The algorithm for the test is as follows:
テストフレームはIloadでDUT/SUTの最初のポート(ポート1)に送られます。 DUT/SUTの2番目のポート(ポート2)の上のFR[2]は測定されます。 各Step SizeがMFRを見つけるように、Iloadは増加されます。 テストのためのアルゴリズムは以下の通りです:
CONSTANT
MOL = ... frames/sec; {Maximum Offered Load}
VARIABLE
MFR := 0 frames/sec; {Maximum Forwarding Rate}
ILOAD := starting throughput in frames/sec; {offered load}
STEP := ... frames/sec; {Step Size}
BEGIN
ILOAD := ILOAD - STEP;
DO
BEGIN
ILOAD := ILOAD + STEP
IF (ILOAD > MOL) THEN
BEGIN
ILOAD := MOL
END
AddressLearning; {Port 2 broadcasts with its source address}
Transmit(ILOAD); {Port 1 sends frames to Port 2 at Offered load}
IF (Port 2 Forwarding Rate > MFR) THEN
BEGIN
MFR := Port 2 Forwarding Rate; {A higher value than before}
END
CONSTANT MOL=…フレーム/秒。 最大のOffered Load、0フレーム/秒のVARIABLE MFR:=。 最大のForwarding Rate、フレーム/秒のILOADの:=の始めのスループット。 提供された負荷STEP:=… フレーム/秒。 ステップサイズはILOAD:=ILOADを始めます--踏んでください。 ILOAD:=mol終わりのAddressLearningがその時始まるなら(ILOAD>mol)、ILOAD:=ILOAD+ステップを始めてください。 ソースアドレスによるポート2放送は(ILOAD)を伝えます。 1がOffered荷重でPort2へのフレームを送るポートは(ポート2Forwarding Rate>MFR)THEN BEGIN MFR:=であるなら2Forwarding Rateを移植します。 以前より高い値、END
Mandeville & Perser Informational [Page 20] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[20ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
END
WHILE (ILOAD < MOL); {ILOAD has reached the MOL value}
DONE
(ILOAD<mol)である間、終わってください。 ILOADがMOL値に達した、DONE
5.6.3.2 Minimum Interframe Gap
5.6.3.2 最小のインターフレームギャップ
The Minimum Interframe gap test SHOULD, at a minimum, be performed in a two-port configuration as described below. Learning frames MUST be sent to allow the DUT/SUT to update its address tables properly.
Minimum Interframeギャップは最小限でSHOULDをテストして、以下で説明されるように2ポートの構成で実行されてください。 DUT/SUTが適切にアドレス・テーブルをアップデートするのを許容するために学習フレームを送らなければなりません。
Test frames SHOULD be transmitted to the first port (port 1) of the DUT/SUT with an interframe gap of 88 bits. This will apply forward pressure to the DUT/SUT and overload it at a rate of one byte per frame. The test frames MUST be constructed with a source address of port 1 and a destination address of port 2.
フレームSHOULDをテストしてください。88ビットのインターフレーム隙間でDUT/SUTの最初のポート(ポート1)に送られてください。 これは、前進の圧力をDUT/SUTに加えて、1フレームあたり1バイトのレートでそれを積みすぎるでしょう。 ポート1のソースアドレスとポート2の送付先アドレスでテストフレームを建築しなければなりません。
The FR on the second port (port 2) of the DUT/SUT is measured. The measured Forwarding Rate should not exceed the medium's maximum theoretical utilization (MOL).
DUT/SUTの2番目のポート(ポート2)の上のFRは測定されます。 測定Forwarding Rateは媒体の最大の理論上の利用(MOL)を超えているはずがありません。
5.6.4 Measurements
5.6.4 測定値
Port 2 MUST categorize, then count the frames into one of two groups:
ポート2は、2つのグループの1つまでフレームを分類して、次に、数えなければなりません:
1.) Received Frames: received frames MUST have the correct
destination MAC address and SHOULD match a signature field.
1.) 容認されたフレーム: 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。
2.) Flood count [2].
2.) カウント[2]をあふれさせてください。
Any frame originating from the DUT/SUT MUST not be counted as a received frame. Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all.
いずれも容認されたフレームにみなされなくDUT/SUT MUSTからの由来を縁どっています。 水につかっているフレームにみなされたか、または全く数えられなかったDUT/SUT MAYから発するフレーム。
5.6.5 Reporting format
5.6.5 書式を報告すること。
MFR MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements. The Iload applied to the device MUST also be cited.
MFR MUST、繰り返しのセットの伝送速度測定値から抜粋されるDUT/SUTの最も高い伝送速度として、報告されてください。 また、装置に適用されたIloadを引用しなければなりません。
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of frames per second that the device is observed to successfully transmit to the correct destination interface in response to a specified Oload. The Iload MUST be cited and the Oload MAY be recorded.
DUT/SUT SHOULDのレート(FR)を進めて、装置が首尾よく指定されたOloadに対応して正しい目的地のインタフェースに伝わるのが観測される秒あたりのフレームの数として報告されてください。 Iloadを引用しなければなりません、そして、Oloadは記録されるかもしれません。
If the FR exceeds the MOL during the Minimum Interframe gap test, this MUST be highlighted with the expression "Forward Pressure detected".
FRがMinimum Interframeじゅん爆試験の間、MOLを超えているなら、「前進のPressureは検出した」表現でこれを強調しなければなりません。
Mandeville & Perser Informational [Page 21] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[21ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
5.7 Address Caching Capacity
5.7 容量をキャッシュするアドレス
5.7.1 Objective
5.7.1 目的
To determine the address caching capacity of a LAN switching device as defined in RFC 2285, section 3.8.1 [2].
RFC2285、セクション3.8.1[2]で定義されるようにLAN切換装置の容量をキャッシュするアドレスを決定するために。
5.7.2 Setup Parameters
5.7.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Age Time - The maximum time that a DUT/SUT will keep a learned
address in its forwarding table.
Timeの年をとってください--DUT/SUTが推進テーブルの学術的アドレスを保管する最大の時間。
Addresses Learning Rate - The rate at which new addresses are
offered to the DUT/SUT to be learned. The rate at which address
learning frames are offered may have to be adjusted to be as low
as 50 frames per second or even less, to guarantee successful
learning.
アドレスLearning Rate--新しいアドレスが学習されるためにDUT/SUTに提供されるレート。 アドレス学習フレームが提供されるレートは、1秒あたり50個のフレームか以下とさえ同じくらい低く、うまくいっている学習を保証するように調整されなければならないかもしれません。
Initial Addresses - The initial number of addresses to start the
test with. The number MUST be between 1 and the maximum number
supported by the implementation.
Addressesに頭文字をつけてください--テストを始めるアドレスの初期の数。 1と実現で支持された最大数の間には、数があるに違いありません。
5.7.3 Procedure
5.7.3 手順
The aging time of the DUT/SUT MUST be known. The aging time MUST be longer than the time necessary to produce frames at the specified rate. If a low frame rate is used for the test, then it may be possible that sending a large amount of frames may actually take longer than the aging time.
古さはDUT/SUT MUSTを調節します。知られています。 フレームを生産するのに必要な時間より長い間、古い時間が指定されたレートにあるに違いありません。 低フレームレートがテストに使用されるなら、多量のフレームを送るのが実際に古い時間より長い間かかるのは、可能であるかもしれません。
This test MUST at a minimum be performed in a three-port configuration described below. The test MAY be expanded to fully utilized the DUT/SUT in increments of two or three ports. An increment of two would include an additional Learning port and Test port. An increment of three would include an additional Learning port, Test port, and Monitoring port.
最小限で以下で説明された3ポートの構成でこのテストを実行しなければなりません。 テストは完全に利用されているのに広げられるかもしれません。2の増分か3つのポートのDUT/SUT。 2の増分は追加LearningポートとTestポートを含んでいるでしょう。 3の増分は追加Learningポート、Testポート、およびMonitoringポートを含んでいるでしょう。
The Learning port (Lport) transmits learning frames to the DUT/SUT with varying source addresses and a fixed destination address corresponding to the address of the device connected to the Test port (Tport) of the DUT/SUT. By receiving frames with varying source addresses, the DUT/SUT should learn these new addresses. The source addresses MAY be in sequential order.
Learningポート(Lport)はDUT/SUTのTestポート(Tport)に接続された装置のアドレスに対応する異なったソースアドレスと固定送付先アドレスで学習フレームをDUT/SUTに伝えます。 異なったソースアドレスでフレーム搬入することによって、DUT/SUTはこれらの新しいアドレスを学ぶはずです。 ソースアドレスが連続したオーダーにあるかもしれません。
Mandeville & Perser Informational [Page 22] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[22ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
The Test port (Tport) of the DUT/SUT acts as the receiving port for the learning frames. Test frames will be transmitted back to the addresses learned on the Learning port. The algorithm for this is explained below.
DUT/SUTのTestポート(Tport)は学習フレームへの受流口として作動します。 テストフレームはLearningポートの上で学習されたアドレスに伝えて戻されるでしょう。 これのためのアルゴリズムは以下で説明されます。
The Monitoring port (Mport) on the DUT/SUT acts as a monitoring port to listen for flooded or mis-forwarded frames. If the test spans multiple broadcast domains (VLANs), each broadcast domain REQUIRES a Monitoring port.
Monitoringは、DUT/SUT条例のときに水につかっているか誤進められたフレームの聞こうとするためにモニターしているポートとして(Mport)を移植します。 テストがわたるなら、倍数はドメイン(VLANs)を放送して、それぞれの放送ドメインREQUIRESはMonitoringポートです。
It is highly recommended that SNMP, Spanning Tree, and any other frames originating from the DUT/SUT be disabled when running this test. If such protocols cannot be turned off, the flood count MUST be modified only to count test frame originating from Lport and MUST NOT count frames originating from the DUT/SUT.
このテストを走らせるとき、DUT/SUTから発するSNMP、Spanning Tree、およびいかなる他のフレームも無効にされるのは、非常にお勧めです。 そのようなプロトコルをオフにすることができないなら、洪水カウントは、変更しなければなりませんが、Lportから発するテストフレームを数えて、DUT/SUTから発するフレームを数えてはいけません。
The algorithm for the test is as follows:
テストのためのアルゴリズムは以下の通りです:
CONSTANT
AGE = ...; {value greater that DUT aging time}
MAX = ...; {maximum address support by implementation}
VARIABLE
LOW := 0; {Highest passed valve}
HIGH := MAX; {Lowest failed value}
N := ...; {user specified initial starting point}
BEGIN
DO
BEGIN
PAUSE(AGE); {Age out any learned addresses}
AddressLearning(TPort); {broadcast a frame with its source
Address and broadcast destination}
AddressLearning(LPort); {N frames with varying source addresses
to Test Port}
Transmit(TPort); {N frames with varying destination addresses
corresponding to Learning Port}
IF (MPort receive frame != 0) OR
(LPort receive frames < TPort transmit) THEN
BEGIN {Address Table of DUT/SUT was full}
HIGH := N;
END
ELSE
BEGIN {Address Table of DUT/SUT was NOT full}
LOW := N;
END
N := LOW + (HIGH - LOW)/2;
END WHILE (HIGH - LOW >= 2);
END {Value of N equals number of addresses supported by DUT/SUT}
一定の時代=…; そのDUT古い時間により大きい値、MAX=…; 実現による最大のアドレスサポート、VARIABLE LOW:=0。 最も高い通っているバルブHIGH:=MAX。 最も低い失敗した値のN:=…; ユーザの指定された初期の出発点BEGIN DO BEGIN PAUSE(AGE)。 あらゆる学術的アドレスから、AddressLearning(TPort)の年をとってください。 そのソースAddressと放送の目的地があるフレームを放送してください、AddressLearning(LPort)。 ソースアドレスをTest Portに変えるNフレームが(TPort)を伝えます。 Learning Portに対応する異なった送付先アドレスがあるNフレーム、DUT/SUTのアドレスTableが(MPortはフレーム!=0を受けます)OR(LPortは<TPortが伝えるフレームを受ける)THEN BEGINであるなら完全であった、HIGH:=N。 END ELSE BEGIN、DUT/SUTのアドレスTableが完全でなかった、LOW:=N。 N:=低い+(高値--安値)/2を終わらせてください。 終わり、ゆったり過ごします(高値--低い>=2)。 終わりNの値はDUT/SUTによってサポートされたアドレスの数と等しいです。
Mandeville & Perser Informational [Page 23] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[23ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Using a binary search approach, the test targets the exact number of addresses supported per port with consistent test iterations. Due to the aging time of DUT/SUT address tables, each iteration may take some time during the waiting period for the addresses to clear. If possible, configure the DUT/SUT for a low value for the aging time.
二分探索アプローチを使用して、テストは一致検定繰り返しでポート単位でサポートされたアドレスのはっきりした数を狙います。 DUT/SUTアドレス・テーブルの古い時間のため、各繰り返しはアドレスがクリアする待ちの期間、ある程度時間がかかるかもしれません。 できれば、古い時間の低値のためにDUT/SUTを構成してください。
Once the high and low values of N meet, then the threshold of address handling has been found.
一度、Nの上下の値は満たされて、次に、アドレス取り扱いの敷居は見つけられました。
5.7.4 Measurements
5.7.4 測定値
Whether the offered addresses per port was successful forwarded without flooding.
1ポートあたりの提供されたアドレスは氾濫なしで進めた状態でうまくいくのであったかどうか
5.7.5 Reporting format
5.7.5 書式を報告すること。
After the test is run, results for each iteration SHOULD be displayed in a table to include:
テストが各繰り返しSHOULD単位で走って、結果として生じた後に、含んでいるテーブルに表示してください:
The number of addresses used for each test iteration (varied).
アドレスの数は各テストに、繰り返し(変えられる)を使用しました。
The intended load used for each test iteration (fixed).
意図している負荷は各テストに、繰り返し(修理されている)を使用しました。
Number of test frames that were offered to Tport of the DUT/SUT.
This SHOULD match the number of addresses used for the test
iteration. Test frames are the frames sent with varying
destination addresses to confirm that the DUT/SUT has learned all
of the addresses for each test iteration.
DUT/SUTのTportに提供されたテストフレームの数。 このSHOULDはテスト繰り返しに使用されるアドレスの数に合っています。 テストフレームはDUT/SUTがそれぞれのテスト繰り返しのためのアドレスのすべてを学んだと確認するために異なった送付先アドレスと共に送られたフレームです。
The flood count on Tport during the test portion of each test. If
the number is non-zero, this is an indication of the DUT/SUT
flooding a frame in which the destination address is not in the
address table.
それぞれのテストの試料の間のTportにおける洪水カウント。 数が非ゼロであるなら、これは送付先アドレスがアドレス・テーブルにないフレームをあふれさせるDUT/SUTのしるしです。
The number of frames correctly forwarded to test Lport during the
test portion of the test. Received frames MUST have the correct
destination MAC address and SHOULD match a signature field. For a
passing test iteration, this number should be equal to the number
of frames transmitted by Tport.
フレームの数はテストの試料の間、正しくLportをテストに送りました。 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。 一時的なテスト繰り返しにおいて、この数はTportによって伝えられたフレームの数と等しいはずです。
The flood count on Lport during the test portion of each test. If
the number is non-zero, this is an indication of the DUT/SUT
flooding a frame in which the destination address is not in the
address table.
それぞれのテストの試料の間のLportにおける洪水カウント。 数が非ゼロであるなら、これは送付先アドレスがアドレス・テーブルにないフレームをあふれさせるDUT/SUTのしるしです。
Mandeville & Perser Informational [Page 24] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[24ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
The flood count on Mport. If the value is not zero, then this
indicates that for that test iteration, the DUT/SUT could not
determine the proper destination port for that many frames. In
other words, the DUT/SUT flooded the frame to all ports since its
address table was full.
Mportにおける洪水カウント。 値がゼロでないなら、これは、そのテスト繰り返しのために、DUT/SUTがそんなに多くのフレームに適切な仕向港を決定できなかったのを示します。 言い換えれば、アドレス・テーブルが完全であったので、DUT/SUTはすべてのポートへフレームをあふれさせました。
5.8 Address Learning Rate
5.8 アドレス学習率
5.8.1 Objective
5.8.1 目的
To determine the rate of address learning of a LAN switching device.
LAN切換装置を知っているアドレスのレートを測定するために。
5.8.2 Setup Parameters
5.8.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Age Time - The maximum time that a DUT/SUT will keep a learned
address in its forwarding table.
Timeの年をとってください--DUT/SUTが推進テーブルの学術的アドレスを保管する最大の時間。
Initial Addresses Learning Rate - The starting rate at which new
addresses are offered to the DUT/SUT to be learned.
Addresses Learning Rateに頭文字をつけてください--新しいアドレスが学習されるためにDUT/SUTに提供される初任給。
Number of Addresses - The number of addresses that the DUT/SUT
must learn. The number MUST be between 1 and the maximum number
supported by the implementation. It is recommended no to exceed
the address caching capacity found in section 5.9
Addressesの数--DUT/SUTが学ばなければならないアドレスの数。 1と実現で支持された最大数の間には、数があるに違いありません。 セクション5.9で見つけられた容量をキャッシュするアドレスを超えるのは、お勧めのノーです。
5.8.3 Procedure
5.8.3 手順
The aging time of the DUT/SUT MUST be known. The aging time MUST be longer than the time necessary to produce frames at the specified rate. If a low frame rate is used for the test, then it may be possible that sending a large amount of frames may actually take longer than the aging time.
古さはDUT/SUT MUSTを調節します。知られています。 フレームを生産するのに必要な時間より長い間、古い時間が指定されたレートにあるに違いありません。 低フレームレートがテストに使用されるなら、多量のフレームを送るのが実際に古い時間より長い間かかるのは、可能であるかもしれません。
This test MUST at a minimum be performed in a three-port configuration in section 5.9.3. The test MAY be expanded to fully utilized the DUT/SUT in increments of two or three ports. An increment of two would include an additional Learning port and Test port. An increment of three would include an additional Learning port, Test port, and Monitoring port.
最小限でセクション5.9.3における3ポートの構成でこのテストを実行しなければなりません。 テストは完全に利用されているのに広げられるかもしれません。2の増分か3つのポートのDUT/SUT。 2の増分は追加LearningポートとTestポートを含んでいるでしょう。 3の増分は追加Learningポート、Testポート、およびMonitoringポートを含んでいるでしょう。
An algorithm similar to the one used to determine address caching capacity can be used to determine the address learning rate. This test iterates the rate at which address learning frames are offered
ものと同様のアルゴリズムは、以前はよくアドレス学習率を測定するのに容量をキャッシュするアドレスを使用できることを決定していました。 フレームが提供されることを学びながら、このテストはどのアドレスでレートを繰り返すか。
Mandeville & Perser Informational [Page 25] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[25ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
by the test device connected to the DUT/SUT. It is recommended to set the number of addresses offered to the DUT/SUT in this test to the maximum caching capacity.
テストで、装置はDUT/SUTに接続しました。 このテストでDUT/SUTに提供されたアドレスの数を容量をキャッシュする最大に設定するのはお勧めです。
The address learning rate might be determined for different numbers of addresses but in each test run, the number MUST remain constant and SHOULD be equal to or less than the maximum address caching capacity.
異なった数のアドレスにおいて、アドレス学習率は決定しているかもしれませんが、各試運転に、数は定数とSHOULDのままで残らなければなりません。最大のアドレスキャッシュより等しいか少ない容量になってください。
5.8.4 Measurements
5.8.4 測定値
Whether the offered addresses per port were successful forwarded without flooding at the offered learning rate.
1ポートあたりの提供されたアドレスが提供された学習のときに氾濫なしで進めた状態でうまくいったか否かに関係なく、評価してください。
5.8.5 Reporting format
5.8.5 書式を報告すること。
After the test is run, results for each iteration SHOULD be displayed in a table:
テストが各繰り返しSHOULD単位で走って、結果として生じた後に、テーブルに表示してください:
The number of addresses used for each test iteration (fixed).
アドレスの数は各テストに、繰り返し(修理されている)を使用しました。
The intended load used for each test iteration (varied).
意図している負荷は各テストに、繰り返し(変えられる)を使用しました。
Number of test frames that were transmitted by Tport. This SHOULD
match the number of addresses used for the test iteration. Test
frames are the frames sent with varying destination addresses to
confirm that the DUT/SUT has learned all of the addresses for each
test iteration.
Tportによって伝えられたテストフレームの数。 このSHOULDはテスト繰り返しに使用されるアドレスの数に合っています。 テストフレームはDUT/SUTがそれぞれのテスト繰り返しのためのアドレスのすべてを学んだと確認するために異なった送付先アドレスと共に送られたフレームです。
The flood count on Tport during the test portion of each test. If
the number is non-zero, this is an indication of the DUT/SUT
flooding a frame in which the destination address is not in the
address table.
それぞれのテストの試料の間のTportにおける洪水カウント。 数が非ゼロであるなら、これは送付先アドレスがアドレス・テーブルにないフレームをあふれさせるDUT/SUTのしるしです。
The number of frames correctly forwarded to test Lport during the
test portion of the test. Received frames MUST have the correct
destination MAC address and SHOULD match a signature field. For a
passing test iteration, this number should be equal to the number
of frames transmitted by Tport.
フレームの数はテストの試料の間、正しくLportをテストに送りました。 容認されたフレームで、正しい目的地のMACアドレスとSHOULDは署名分野に合わなければなりません。 一時的なテスト繰り返しにおいて、この数はTportによって伝えられたフレームの数と等しいはずです。
The flood count on Lport during the test portion of each test. If
the number is non-zero, this is an indication of the DUT/SUT
flooding a frame in which the destination address is not in the
address table.
それぞれのテストの試料の間のLportにおける洪水カウント。 数が非ゼロであるなら、これは送付先アドレスがアドレス・テーブルにないフレームをあふれさせるDUT/SUTのしるしです。
Mandeville & Perser Informational [Page 26] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[26ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
The flood count on Mport. If the value is not zero, then this
indicates that for that test iteration, the DUT/SUT could not
determine the proper destination port for that many frames. In
other words, the DUT/SUT flooded the frame to all ports since its
address table was full.
Mportにおける洪水カウント。 値がゼロでないなら、これは、そのテスト繰り返しのために、DUT/SUTがそんなに多くのフレームに適切な仕向港を決定できなかったのを示します。 言い換えれば、アドレス・テーブルが完全であったので、DUT/SUTはすべてのポートへフレームをあふれさせました。
5.9 Errored frames filtering
5.9 Erroredフレームフィルタリング
5.9.1 Objective
5.9.1 目的
The objective of the Errored frames filtering test is to determine the behavior of the DUT under error or abnormal frame conditions. The results of the test indicate if the DUT/SUT filters the errors, or simply propagates the errored frames along to the destination.
テストをフィルターにかけるErroredフレームの目的は誤りか異常なフレーム条件のもとでDUTの動きを決定することです。 テストの結果は、DUT/SUTが誤りをフィルターにかけるか、または単にerroredフレームを伝播するかをずっと目的地に示します。
5.9.2 Setup Parameters
5.9.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load possible. The actual
transmitted frame per second is dependent upon half duplex or full
duplex operation. The test SHOULD be run multiple times with a
different load per port in each case.
ILoad--1ポートあたりの意図しているLoadは媒体の可能な最大の理論上の負荷の割合で急送されます。 1秒あたりの実際の伝えられたフレームは半二重か全二重操作に依存しています。 中に1ポートあたり1つの異なった負荷がある走行複数の回が各ケースであったならSHOULDをテストしてください。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
5.9.3 Procedure
5.9.3 手順
Each of the illegal frames for Ethernet MUST be checked:
イーサネットのためのそれぞれの不法なフレームをチェックしなければなりません:
Oversize - The DUT/SUT MAY filter frames larger than 1518 bytes from being propagated through the DUT/SUT section 4.2.4.2.1 [4]. Oversized frames transmitted to the DUT/SUT should not be forwarded. DUT/SUT supporting tagged Frames MAY forward frames up to and including 1522 bytes long (section 4.2.4.2.1 [5]).
特大品--DUT/SUT MAYは1518バイトより伝播されるのからDUT/SUT部4.2の.4.2.1[4]まで大きいフレームをフィルターにかけます。 DUT/SUTに伝えられた特大のフレームを進めるべきではありません。 タグ付けをされたFramesを支持するDUT/SUTは1522年のバイト長を含めてフレームを進めるかもしれません。(4.2.4.2.1[5])を区分してください。
Undersize - The DUT/SUT MUST filter frames less than 64 bytes from being propagated through the DUT/SUT (section 4.2.4.2.2 [4]). Undersized frames (or collision fragments) received by the DUT/SUT must not be forwarded.
DUT/SUT MUSTは伝播されるのからDUT/SUTまで64バイト未満のフレームをフィルターにかけます。アンダサイズ--、(4.2.4.2.2[4])を区分してください。 DUT/SUTによって受け取られた小型のフレーム(または、衝突断片)を進めてはいけません。
CRC Errors - The DUT/SUT MUST filter frames that fail the Frame Check Sequence Validation (section 4.2.4.1.2 [4]) from being propagated through the DUT/SUT. Frames with an invalid CRC transmitted to the DUT/SUT should not be forwarded.
DUT/SUT MUSTはFrame Check Sequence Validationに失敗するフレームをフィルターにかけます。CRC Errors--、(4.2にDUT/SUTを通して伝播されるのからの.4.1.2[4])を区分してください。 無効のCRCがDUT/SUTに伝えられているフレームを進めるべきではありません。
Mandeville & Perser Informational [Page 27] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[27ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Dribble Bit Errors - The DUT/SUT MUST correct and forward frames containing dribbling bits. Frames transmitted to the DUT/SUT that do not end in an octet boundary but contain a valid frame check sequence MUST be accepted by the DUT/SUT (section 4.2.4.2.1 [4]) and forwarded to the correct receive port with the frame ending in an octet boundary (section 3.4 [4]).
Bit Errorsをドリブルしてください--よだれのビットを含むDUT/SUT MUSTの正しくて前進のフレーム。 八重奏境界の中にフレーム結末がある状態で、.4.2.1[4])の、そして、正しさに送られたセクション4.2はポートを受けます。DUT/SUTが八重奏境界に終わるのではなく、有効なフレームチェックシーケンスを含むDUT/SUTに伝えられたフレームを受け入れなければならない、((セクション3.4[4])。
Alignment Errors - The DUT/SUT MUST filter frames that fail the Frame Check Sequence Validation AND do not end in an octet boundary. This is a combination of a CRC error and a Dribble Bit error. When both errors are occurring in the same frame, the DUT/SUT MUST determine the CRC error takes precedence and filters the frame (section 4.2.4.1.2 [4]) from being propagated.
整列Errors--Frame Check Sequence Validation ANDに失敗するDUT/SUT MUSTフィルタフレームは八重奏境界に終わりません。 これはCRC誤りとDribble Bit誤りの組み合わせです。 両方の誤りが同じフレームに発生しているとき、DUT/SUT MUSTは、CRC誤りが先行とフィルタにフレームを取ることを決定します。(4.2に伝播されるのからの.4.1.2[4])を区分してください。
5.9.5 Reporting format
5.9.5 書式を報告すること。
For each of the error conditions in section 5.6.3, a "pass" or "fail" MUST be reported. Actual frame counts MAY be reported for diagnostic purposes.
セクション5.6.3における、それぞれのエラー条件において、「パス」か「失敗してください」を報告しなければなりません。 実際のフレームカウントは診断目的で報告されるかもしれません。
5.10 Broadcast frame Forwarding and Latency
5.10 放送フレームForwardingとLatency
5.10.1 Objective
5.10.1 目的
The objective of the Broadcast Frame Forwarding and Latency Test is to determine the throughput and latency of the DUT when forwarding broadcast traffic. The ability to forward broadcast frames will depend upon a specific function built into the device for that purpose. It is therefore necessary to determine the ability of DUT/SUT to handle broadcast frames, since there may be many different ways of implementing such a function.
Broadcast Frame ForwardingとLatency Testの目的は放送交通を進めるとき、DUTのスループットと潜在を測定することです。 放送フレームを進める能力は装置がそのために組み込まれた具体的な機能に依存するでしょう。 したがって、DUT/SUTが放送フレームを扱う能力を決定するのが必要です、そのような機能を実行する多くの異なった方法があるかもしれないので。
5.10.2 Setup Parameters
5.10.2 セットアップパラメタ
The following parameters MUST be defined. Each variable is configured with the following considerations.
以下のパラメタを定義しなければなりません。 各変数は以下の問題によって構成されます。
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
フレームSize--お勧めのフレーム・サイズは64、128、256、512、1024です、1280と1518バイト、RFC2544部9の[3]単位で。 4CRCバイトはサイズが指定したフレームに含まれています。
Duplex mode - Half duplex or full duplex.
重複のモード--半二重か全二重。
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load, regardless of traffic
orientation or duplex mode. Certain test configurations will
theoretically over-subscribe the DUT/SUT.
ILoad--1ポートあたりの意図しているLoadは媒体の最大の理論上の負荷の割合で急送されます、交通オリエンテーションか重複のモードにかかわらず。 あるテスト構成は理論的にDUT/SUTを申し込み過ぎるでしょう。
Mandeville & Perser Informational [Page 28] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[28ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
ILoad will not over-subscribe the DUT/SUT in this test.
ILoadはこのテストでDUT/SUTを申し込み過ぎないでしょう。
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
トライアルDuration--お勧めのTrial Durationは30秒です。 トライアル持続時間SHOULD、1〜300秒調整可能であってください。
5.10.3 Procedure
5.10.3 手順
For this test, there are two parts to be run.
このテストのために、2つの走るべき部品があります。
Broadcast Frame Throughput - This portion of the test uses a single source test port to transmit test frames with a broadcast address using the frame specified in RFC 2544 [3]. Selected receive ports then measure the forwarding rate and Frame loss rate.
放送Frame Throughput--テストのこの部分は、放送演説がRFC2544[3]で指定されたフレームを使用している状態でテストフレームを伝えるのに単一のソーステスト港を使用します。 選択されて、ポートを受けてください、そして、次に、伝送速度とFrame損失率を測定してください。
Broadcast Frame Latency - This test uses the same setup as the Broadcast Frame throughput, but instead of a large stream of test frames being sent, only one test frame is sent and the latency to each of the receive ports are measured in seconds.
ポートを受けてください。Frame Latencyを放送してください--これがBroadcast Frameスループットにもかかわらず、送ります、あるテストフレームだけを送るということであるテストフレームの大きな川とそれぞれへの潜在の代わりに同じくらいがセットアップする用途をテストする、秒に測定されます。
5.10.4 Measurements
5.10.4 測定値
Frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3] with the following notes: Frame loss rate SHOULD be measured at the end of the trial duration. The term "rate", for this measurement only, does not imply the units in the fashion of "per second."
損失率を縁どってください。DUT/SUT SHOULDでは、以下の注意でセクション26.3[3]で定義されるように、報告されてください: 損失率のSHOULDを縁どってください。トライアル持続時間の終わりでは、測定されます。 この測定だけのために、「レート」という用語は「秒」のファッションでユニットを含意しません。
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of test frames per second that the device is observed to successfully forward to the correct destination interface in response to a specified Oload. The Oload MUST also be cited.
DUT/SUT SHOULDのレート(FR)を進めて、装置が首尾よく指定されたOloadに対応して正しい目的地のインタフェースに送るために観測される1秒あたりのテストフレームの数として報告されてください。 また、Oloadを引用しなければなりません。
5.10.5 Reporting format
5.10.5 書式を報告すること。
The results for these tests SHOULD be reported in the form of a graph. The x coordinate SHOULD be the frame size, the y coordinate SHOULD be the test results. There SHOULD be at least two lines on the graph, one plotting the theoretical and one plotting the test results.
これらのための結果は報告されたコネがグラフのフォームであったならSHOULDをテストします。 xはフレームがサイズであったならSHOULDを調整して、yはテストが結果であったならSHOULDを調整します。 SHOULDは少なくともそこでは、そうです。グラフ、理論上を企む1つ、およびものの試験の成績をプロットする2つの線。
To measure the DUT/SUT's ability to switch traffic while performing many different address lookups, the number of addresses per port MAY be increased in a series of tests.
多くの異なったアドレスルックアップを実行している間に交通を切り換えるDUT/SUTの性能を測定するために、1ポートあたりのアドレスの数は一連のテストで増加するかもしれません。
Mandeville & Perser Informational [Page 29] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[29ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
6. Security Considerations
6. セキュリティ問題
As this document is solely for the purpose of providing metric methodology and describes neither a protocol nor a protocol's implementation, there are no security considerations associated with this document.
このドキュメントが唯一メートル法の方法論を提供する目的のためにあって、プロトコルもプロトコルの実現も説明しないとき、このドキュメントに関連しているどんなセキュリティ問題もありません。
7. References
7. 参照
[1] Bradner, S., Editor, "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
[1] ブラドナー、S.、エディタ、「ネットワーク相互接続装置のためのベンチマーキング用語」、RFC1242、1991年7月。
[2] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998.
[2] マンデヴィル、R.、「LAN切換装置のためのベンチマーキング用語」、RFC2285、1998年2月。
[3] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[3] ブラドナーとS.とJ.McQuaid、「ネットワーク内部連絡装置のためのベンチマーキング方法論」、RFC2544、1999年3月。
[4] ANSI/IEEE, "CSMA/CD Access Method and Physical Layer
Specifications," ISO/IEC 8802-3, ISBN 0-7381-0330-6, 1998.
[4] ANSI/IEEE、「CSMA/CDは方法と物理的な層の仕様にアクセスする」ISO/IEC8802-3、ISBN0-7381-0330-6、1998。
[5] IEEE Draft, "Frame Extensions for Virtual Bridged Local Area
Networks (VLAN) Tagging on 802.3 Networks", 802.3ac/D3.1, July
1998.
[5] IEEEは1998年7月に「仮想の橋を架けられたローカル・エリア・ネットワーク(VLAN)のためのフレーム拡大は802.3でネットワークにタグ付けをすること」での802.3ac/D3.1を作成します。
8. Authors' Addresses
8. 作者のアドレス
Robert Mandeville CQOS Inc. 21 Technology Irvine, CA 92618 USA
ロバートマンデヴィルCQOS Inc.21Technologyカリフォルニア92618アーバイン(米国)
Phone: +1 (949) 400-4444 EMail: bob@cqos.com
以下に電話をしてください。 +1 (949) 400-4444 メールしてください: bob@cqos.com
Jerry Perser Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA
ジェリーPerser Spirent Communications26750Agoura Roadカリフォルニア91302カラバサス(米国)
Phone: + 1 818 676 2300 EMail: jerry_perser@netcomsystems.com
以下に電話をしてください。 2300がメールする+1 818 676: jerry_perser@netcomsystems.com
Mandeville & Perser Informational [Page 30] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[30ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Appendix A: Formulas
付録A: 定石
A.1 Calculating the InterBurst Gap
InterBurstギャップについて計算するA.1
IBG is defined in RFC 2285 [2] as the interval between two bursts. To achieve a desired load, the following Input Parameter need to be defined:
IBGはRFC2285[2]で2回の炸裂の間隔と定義されます。 必要な負荷を達成するために、以下のInput Parameterは、定義される必要があります:
LENGTH - Frame size in bytes including the CRC.
LENGTH--CRCを含むバイトで表現されるフレーム・サイズ。
LOAD - The intended load in percent. Range is 0 to 100.
LOAD--パーセントで表現される意図している負荷。 範囲は、0〜100です。
BURST - The number of frames in the burst (integer value).
BURST--炸裂(整数値)における、フレームの数。
SPEED - media's speed in bits/sec
Ethernet is 10,000,000 bits/sec
Fast Ethernet is 100,000,000 bits/sec
Gigabit Ethernet is 1,000,000,000 bits/sec
SPEED--ビット/秒のイーサネットにおけるメディアの速度は1000万ビット/秒のファースト・イーサネットが1億ビット/秒のGigabitイーサネットが10億ビット/秒であるということであるということです。
IFG - A constant 96 bits for the minimum interframe gap.
IFG--最小のインターフレームギャップへの一定の96ビット。
The IBG (in seconds) can be calculated:
IBG(秒の)について計算できます:
[(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
IBG = -----------------------------------------------------------
SPEED
(100/負荷--1) *は+ *(IFG+64+8*長さ]IFG IBG=を押し破きました。----------------------------------------------------------- 速度
A.2 Calculating the Number of Bursts for the Trial Duration
トライアル持続時間のために炸裂の数について計算するA.2
The number of bursts for the trial duration is rounded up to the nearest integer number. The follow Input Parameter need to be defined:
トライアル持続時間のための炸裂の数は最も近い整数まで一周します。 尾行Input Parameterは、定義される必要があります:
LENGTH - Frame size in bytes including the CRC.
LENGTH--CRCを含むバイトで表現されるフレーム・サイズ。
BURST - The number of frames in the burst (integer value).
BURST--炸裂(整数値)における、フレームの数。
SPEED - media's speed in bits/sec
Ethernet is 10,000,000 bits/sec
Fast Ethernet is 100,000,000 bits/sec
Gigabit Ethernet is 1,000,000,000 bits/sec
SPEED--ビット/秒のイーサネットにおけるメディアの速度は1000万ビット/秒のファースト・イーサネットが1億ビット/秒のGigabitイーサネットが10億ビット/秒であるということであるということです。
IFG - A constant 96 bits for the minimum interframe gap.
IFG--最小のインターフレームギャップへの一定の96ビット。
IBG - Found in the above formula
IBG--上の公式では、見つけられます。
DURATION - Trial duration in seconds.
DURATION--秒のトライアル持続時間。
Mandeville & Perser Informational [Page 31] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[31ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
An intermediate number of the Burst duration needs to be calculated first:
Burst持続時間の中間的数は、最初に計算される必要があります:
TXTIME = -----------------------------------------
SPEED
TXTIME=----------------------------------------- 速度
Number of Burst for the Trial Duration (rounded up):
Trial Duration(切り上げられる)のためのBurstの数:
DURATION
#OFBURSTS = --------------
(TXTIME + IBG)
持続時間#OFBURSTS=-------------- (TXTIME+IBG)
Example:
例:
LENGTH = 64 bytes per frame
LOAD = 100 % offered load
BURST = 24 frames per burst
SPEED = 10 Mbits/sec (Ethernet)
DURATION = 10 seconds test
100%が10 10メガビット/秒(イーサネット)の炸裂SPEEDあたり24個の負荷BURST=フレーム=DURATION=秒提供したフレームLOAD=あたり64LENGTH=バイトはテストされます。
IBG = 1612.8 uS
TXTIME = 1603.2 uS
#OFBURSTS = 3110
IBGが1612.8と等しい、私たち、TXTIME=1603.2に、私たち#OFBURSTSは3110と等しいです。
Appendix B: Generating Offered Load
付録B: 発生は負荷を提供しました。
In testing, the traffic generator is configured with the Iload (Intended Load) and measures the Oload (Offered Load). If the DUT/SUT applies congestion control, then the Iload and the Oload are not the same value. The question arises, how to generate the Oload? This appendix will describe two different methods.
テストで、交通ジェネレータは、Iload(意図しているLoad)によって構成されて、Oload(Loadを提供する)を測定します。 DUT/SUTが輻輳制御を適用するなら、IloadとOloadは同じ値ではありません。 質問が起こる、Oload?発生させる方法 この付録は2つの異なった方法を説明するでしょう。
The unit of measurement for Oload is bits per second. The two methods described here will hold one unit constant and let the DUT/SUT vary the other unit. The traffic generator SHOULD specify which method it uses.
Oloadのための測定の単位はbpsです。 ここで説明された2つの方法で、1個のユニットを一定に主張して、DUT/SUTはもう片方のユニットを変えるでしょう。 交通ジェネレータSHOULDは、それがどの方法を使用するかを指定します。
B.1 Frame Based Load
B.1のフレームのベースの荷重
Frame Based Load holds the number of bits constant. The Trial Duration will vary based upon congestion control. Advantage is implementation is a simple state machine (or loop). The disadvantage is that Oload needs to be measured independently.
フレームBased Loadはビット定数の数を保持します。 Trial Durationは輻輳制御に基づいた状態で異なるでしょう。 利点は実現が簡単な州のマシン(輪にする)であるということです。 不都合はOloadが、独自に測定される必要があるということです。
Mandeville & Perser Informational [Page 32] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[32ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
All ports on the traffic generator MUST transmit the exact number of test frames. The exact number of test frames is found by multiplying the Iload of the port by the Trial Duration. All ports MAY NOT transmit the same number of frames if their Iload is not the same. An example would be the Partially meshed many-to-one test.
交通ジェネレータの上のポートがはっきりした数を伝えなければならないすべてがフレームをテストします。 テストフレームのはっきりした数は、ポートのIloadをTrial Durationに掛けることによって、見つけられます。 それらのIloadが同じでないなら、すべてのポートは同じ数のフレームを伝えないかもしれません。 例はPartially1つへのかみ合っている多くテストでしょう。
All ports SHOULD start transmitting their frames within 1% of the trial duration. For a trial duration of 30 seconds, all ports SHOULD have started transmitting frames within 300 milliseconds of each other.
すべてが、トライアル持続時間の1%以内でそれらのフレームを伝えながら、SHOULD始めを移植します。 30秒、SHOULDが互いの300ミリセカンド以内でフレームを伝え始めたすべてのポートのトライアル持続時間のために。
The reported Oload SHOULD be the average during the Trial Duration. If the traffic generator continues to transmit after the Trial Duration due to congestion control, Oload MAY be averaged over the entire transmit time. Oload for the DUT/SUT MUST be the aggregate of all the Oloads per port. Oload per port MAY be reported.
Oload SHOULDがTrial Durationの間平均であると報告しました。 交通ジェネレータが、Trial Durationの後に輻輳制御のため伝わり続けているなら、Oloadは全体の上で平均されるかもしれません。時間を伝えてください。 Oload、すべての1ポートあたりのOloadsのDUT/SUT MUSTに関しては、集合になってください。 1ポートあたりのOloadは報告されるかもしれません。
B.2 Time Based Load
B.2時間は負荷を基礎づけました。
Time based load holds the Trial Duration constant, while allowing the number of octets transmitted to vary. Advantages are an accurate Trial Duration and integrated Oload measurement. Disadvantage is that the starting and stopping of the traffic generator MUST be more accurate.
八重奏の数を許容している間のベースの負荷が一定にTrial Durationを持っている時は、異なるように伝わりました。 利点は、正確なTrial Durationと統合Oload測定です。 不都合は交通ジェネレータの始めと停止が、より正確でなければならないということです。
All ports on the traffic generator are configured to transmit the Iload for a finite amount of time. Each port MUST count the number of octets successfully transmitted.
交通ジェネレータの上のすべてのポートが、有限時間Iloadを伝えるために構成されます。 各ポートは首尾よく伝えられた八重奏の数を数えなければなりません。
The start and stop is initiated at a layer defined by the test parameters. The layer can be the MAC layer, IP layer, or some other point in the protocol stack. The traffic generator MUST complete its layer specific transmit process when the stop time is reached (i.e. no fragments, finish the frame).
始めと停止はテストパラメタによって定義された層で開始されます。 層は、プロトコル・スタックのMAC層、IP層、またはある他のポイントであるかもしれません。 停止時間に達しているとき(いいえはすなわち、断片化して、終わりはフレームです)、交通ジェネレータは加工処理していた状態で詳細が伝える層を完成しなければなりません。
All ports MUST start transmitting their frames within 1% of the trial duration. For a trial duration of 30 seconds, all ports SHOULD have started transmitting frames within 300 milliseconds of each other.
すべてのポートが、トライアル持続時間の1%以内でそれらのフレームを伝え始めなければなりません。 30秒、SHOULDが互いの300ミリセカンド以内でフレームを伝え始めたすべてのポートのトライアル持続時間のために。
All ports SHOULD stop transmitting frames after the specified trail duration within 0.01% of the trial duration. Each port's stop time MUST be reference to its start time. This trial duration error controls the accuracy of the Oload measurement and SHOULD be reported with the Oload measurement.
すべてが、指定された道の持続時間の後にトライアル持続時間の0.01%以内でフレームを伝えながら、SHOULD停止を移植します。 各ポートの停止時間は開始時刻の参照であるに違いありません。 この公判の持続時間誤り制御、精度、Oload測定とSHOULDでは、Oload測定で、報告されてください。
Each port is allowed an offset error of 0.1% and a trial duration error of 0.01%.
0.1%の相殺誤謬と0.01%のトライアル持続時間誤りは各ポートに許容されています。
Mandeville & Perser Informational [Page 33] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[33ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Oload is found by taking the number of octets successfully transmitted and dividing by the trial duration. Oload for the DUT/SUT MUST be the aggregate of all the Oloads per port. Oload per port MAY be reported for diagnostic purposes.
Oloadは、トライアル持続時間で伝えられて、分割しながら、首尾よく八重奏の数を取ることによって、見つけられます。 Oload、すべての1ポートあたりのOloadsのDUT/SUT MUSTに関しては、集合になってください。 1ポートあたりのOloadは診断目的で報告されるかもしれません。
Mandeville & Perser Informational [Page 34] RFC 2889 LAN Switch Benchmarking Methodology August 2000
マンデヴィルとPerserの情報[34ページ]のRFC2889LANはベンチマーキング方法論2000年8月に切り替わります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mandeville & Perser Informational [Page 35]
マンデヴィルとPerser情報です。[35ページ]
一覧
スポンサーリンク
