An acceptance test should answer one question: does this link carry the promised load at the promised quality, measured with a tool both parties agreed on before the test. The 2544 benchmarking method tells you how to find the limit of a device; the ITU-T service activation method tells you whether a service meets its commitment at the committed rate. Those are different questions, and conflating them is why acceptance arguments happen.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
Four metrics earn their place on the sheet: throughput, latency, frame loss rate and back-to-back frames. RFC 2544 defines all four, and RFC 1242 defines the terms behind them.
RFC 2544 finds the maximum rate a device sustains; Y.1564 tests whether a configured service meets its committed and excess information rates. Use 2544 for equipment evaluation and Y.1564 for service turn-up.
iperf is a useful sanity tool and a poor acceptance instrument, because its result moves with CPU load, socket buffers and frame size rather than with the network.
The 2544 benchmarking method defines how to test network interconnect devices, and four of its tests carry almost all of the diagnostic value on an industrial site.
| Metric | Definition in plain words | Industry-common acceptance value |
|---|---|---|
| Throughput | The highest offered rate at which no frame is dropped | 100% of line rate at the tested frame size for a non-blocking switch; 99.9% or better is a common contractual floor |
| Latency | The time from the first bit leaving to the last bit arriving, measured at a stated load | Under 100 microseconds end to end for a small store-and-forward gigabit switch; cut-through designs measure lower |
| Frame loss rate | The fraction of offered frames that never arrived, at a stated load and frame size | Zero at or below the committed rate; anything above zero at committed load is a defect, not a tolerance |
| Back-to-back frames | How many frames the device absorbs in one burst at minimum inter-frame gap without loss | Depends on buffer depth; compare against the buffer figure the vendor states, not against another site |
Two conditions have to travel with those numbers or they are meaningless: the frame size, and the trial duration. That method works from a defined set of frame sizes — commonly 64, 128, 256, 512, 1024, 1280 and 1518 bytes — and trial durations are run at 60 seconds or longer so that a short burst of bad luck cannot pass a bad link.
Most acceptance disputes are not about the measurement; they are about whose number was in force.
| Where the threshold lives | Legal force | What happens in a dispute |
|---|---|---|
| Contract technical annex | Strongest — it is signed by both parties | The annex wins; the measurement only has to be shown to be valid |
| Tender response, referenced in the contract | Strong, if the response is attached and dated | Readable by both sides, and hard to argue away |
| Vendor datasheet alone | Weak — it is a claim about a sample, not a commitment about your link | Usually resolved by re-testing to the annex |
| Verbal agreement on site | None | Re-test, and expect to pay for the delay |
The cheapest possible insurance is one page in the annex listing the four metrics, the frame sizes, the trial duration, the tool and the pass values. That page ends more arguments than any amount of testing rigour.
Both are Ethernet service tests, they are not interchangeable, and picking the wrong one produces a number nobody can act on.
| Dimension | The 2544 method | ITU-T Y.1564 |
|---|---|---|
| Question it answers | What is the maximum this device can carry? | Does this configured service meet its commitment? |
| Traffic model | Single or multiple streams pushed to the limit | Per-service streams at the committed information rate, plus an excess information rate burst |
| What it reports | A single maximum rate per frame size | Pass or fail per service, with delay, delay variation and loss at the committed rate |
| Test duration | Longer, because it sweeps rates | Shorter per service, which suits turn-up windows |
| Typical use | Equipment evaluation, factory acceptance, RFP comparison | Service activation and carrier or campus handover |
| Where it misleads | A perfect maximum says nothing about behaviour at the promised rate under mixed traffic | A pass at the committed rate says nothing about headroom above it |
If you are accepting a service that someone else operates, the service activation method is the honest test: it proves the commitment, which is what you are buying. If you are comparing two switches before purchase, the benchmarking method gives you the comparable figure.
Because iPerf measures the host as much as the network.
| Tool | What its number depends on | Credibility for acceptance |
|---|---|---|
| Dedicated Ethernet test set | The network under test | High; the result is reproducible by the other party with the same model |
| iPerf on a laptop or IPC | Host CPU, NIC offload, socket buffer size, operating system scheduling and frame size | Low for acceptance; useful to prove a link is alive |
| Ping | Only reachability, and the reply is CPU-generated | Not a measurement of throughput or loss at all |
| Switch port counters | Real forwarded frames and real errors | High for validation, but they cannot generate load |
The specific trap is frame size. iPerf with default settings produces large frames at a high throughput figure, which flatters the result; the same link at 64-byte frames is a completely different workload, and 64-byte performance is exactly where buffer behaviour shows up. A test set reports both; a laptop usually reports neither honestly.
One row per test, filled in on site, signed before anyone leaves.
| Field | Example | Why |
|---|---|---|
| Link under test | Cabinet 3 switch port 1/1 to control room port 1/1, 320 m single-mode | Identifies what was measured |
| Tool and firmware | Test set model, firmware version, port speed and duplex | Makes the result reproducible |
| Method | Throughput per the 2544 method, 60 s trials, 512-byte frames | States the rule that was applied |
| Offered load and result | 100% line rate offered, 0 frames lost | The acceptance number |
| Latency and loss | 41 microseconds average, 0% loss | The quality number |
| Signatures | Both parties, date and time | Turns a reading into a record |
Record every trial, not the best one. Five runs with the worst recorded is a defensible result; one flattering run is not.
Should I use RFC 2544 or Y.1564 for a site handover?
The service activation method, if you are accepting a service with a defined committed rate, because it proves the commitment you are paying for. The benchmarking method, if you are comparing equipment or finding headroom, because it tells you the limit rather than the guarantee.
Why does the same switch report different throughput at 64 and 1518 bytes?
Because forwarding cost is largely per frame, not per bit. A switch that forwards frames per second as its limit will saturate its frame budget long before it saturates its bit rate, which is why 64-byte throughput is the harder test and the more revealing one.
How long should each trial run?
Long enough that a brief disturbance cannot decide the outcome; 60 seconds or longer per trial is the usual reading of the method, and five consecutive trials is better than one long one because it exposes instability.
Can a switch's own counters be used instead of a test set?
For validation, yes and often usefully: port counters show real forwarded frames, real CRC errors and real drops. But counters cannot generate load, so they cannot produce a throughput or latency figure on their own.
What if the two parties' testers disagree?
Fall back to the contract annex: same tool model or an agreed equivalent, same frame sizes, same trial duration, run together on the same link. Most disagreements are configuration differences, not network differences.
Acceptance is a paperwork discipline supported by measurement, not the other way round: four metrics, stated frame sizes, a stated duration, an agreed tool, and every trial recorded. Rayin publishes port counts, forwarding rates and buffer figures for its industrial switch lines so those fields can be filled from a datasheet rather than from a promise.
How to Measure LAN Throughput With iPerf, and What the Number Means
Latency, Jitter and Packet Loss: QoS Targets That Actually Matter
Backplane Bandwidth and Packet Forwarding Rate: Reading the Two Numbers
Store-and-Forward vs Cut-Through: How Forwarding Modes Differ
Microbursts and Video Lag: Where QoS and Buffers Actually Help
The definitions and method statements above come from public industry sources — RFC 2544 (benchmarking methodology for network interconnect devices, including throughput, latency, frame loss and back-to-back tests and the standard frame size set), RFC 1242 (benchmarking terminology), RFC 2889 (benchmarking methodology for LAN switching devices) and ITU-T Y.1564 (Ethernet service activation test methodology, including committed and excess information rate testing). The method, worked examples and wording are written by Sara, who checked each figure against those sources before publication. Anything presented as an industry-common or industry-typical value is labelled as such; nothing here is a measured figure from a Rayin product unless it says so.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
