Planning an optical module sample evaluation

01What a sample can and cannot prove

A sample evaluation answers a narrow but important question: does this module, coded this way, behave correctly in this host running this software, over this link. It is strong evidence about that combination. It is weak evidence about anything else. A module that works in one switch family may be rejected by another; a module accepted on one software release may be treated differently after an upgrade; a module that performs well over a short patch cord tells you nothing about a forty kilometre route. Define the question before requesting the sample, and resist the temptation to generalise the result. Write the conclusion as a statement about a specific combination rather than as an assertion that the product is compatible, because the narrower claim is the one that will still be true in twelve months.

02Define the scope before you ask

Decide which configurations genuinely need a sample. New combinations of module class and host platform always do. A repeat of a configuration already validated on the same software release usually does not, though a short receiving check is still worthwhile. A change of reach class within a family that has already been validated sits in between, and is usually worth a shorter test focused on the optical side. Write the list of configurations to be evaluated, with the host platform and software version for each, before contacting the supplier. This turns a vague request for samples into a specific list that can be fulfilled accurately, and it prevents the common outcome where a handful of assorted modules arrives and nobody is sure which design question each one was meant to settle.

03Choose representative test hosts

Test in the equipment that will carry the traffic, at the same software version, and in the same port type. A laboratory switch of the same family but a different model is a reasonable approximation for a first look but is not a substitute, because port groups, cage types and software behaviour differ across models in a family. Where a link connects two different platforms, test both ends, since each host reads the module independently. If the production equipment is not yet available, record that limitation in the test report explicitly and plan a confirmation test when it arrives. Also note the port number used, as some platforms treat particular ports differently, for example ports that share a forwarding block or that support breakout.

04Decide the sample quantity

One module per configuration is enough to answer the compatibility question and not enough to answer any question about consistency. Two to four per configuration allows a link to be built entirely from samples, which is the only way to test end to end behaviour without borrowing production modules, and gives a first sense of whether readings cluster tightly. For a large rollout, it is reasonable to ask for samples drawn from the build that will supply the production order rather than from stock, and to ask whether that is possible before the order is placed. Record the serial numbers of every sample received and keep them with the report, so that the modules used in the test can be distinguished later from production units.

05Checks to run before the link comes up

Start with the module on its own. Insert it into the intended port and confirm that the host recognises it without a manual override, then capture the full identification output the platform provides: vendor name, part number, serial number, date code, revision and any compatibility or type fields the platform displays. Read the diagnostic values with no fiber connected, which gives a valid temperature and voltage reading and confirms the diagnostic interface works. Compare the reported optical capabilities, reach class and wavelength fields with the datasheet, and confirm that the temperature grade shown matches what was ordered. This stage catches coding problems immediately, before fiber and far-end equipment complicate the picture, and the identification output captured here is the reference the production build must reproduce.

06Bring-up checks on the intended link

Build the link as it will be deployed, over the intended fiber where possible, and confirm that it comes up at the expected speed and duplex without configuration workarounds. Read the diagnostic values at both ends and compare receive power with the loss you predicted for the route; a reading far from prediction points at the cabling rather than the module. Where the rate uses forward error correction, confirm that both ends have the expected mode configured and that it negotiates or is set consistently. Then pass traffic and confirm the interface counters stay clean. Where the platform exposes per-lane data on parallel optics, check that all four lanes report similar receive power, since a single weak lane indicates a cabling or cleanliness issue.

07Resilience checks that are easy to skip

A module that comes up once has not been tested. Reload the host and confirm the link returns without intervention. Hot-remove and reinsert the module and confirm it is recognised again and the link recovers. Disconnect and reconnect the fiber to confirm the loss-of-signal handling and recovery behave correctly. Power-cycle the chassis rather than only reloading the software, since some initialisation problems appear only from cold. Where the port supports it, shut and re-enable the interface administratively. These checks take a few minutes each and find a category of problem that soak testing will never reveal: modules that work fine once initialised but are not reliably detected during boot, which is exactly the failure that turns a routine maintenance window into an outage.

08Soak testing under traffic

Run continuous traffic for an agreed period, long enough for a thermal steady state and for slow problems to appear. A working figure is at least twenty-four hours, and forty-eight to seventy-two hours where the link is important enough to justify the time. Load the link enough to be representative rather than leaving it idle, since some faults only show under traffic. At the start and end of the soak, record all diagnostic values and all interface counters, including CRC errors and corrected and uncorrected forward error correction codewords. What you are looking for is not only errors but drift: a module whose temperature or bias current climbs steadily through the test in a stable ambient environment is behaving differently from the rest of the sample and deserves attention.

09Retest after a software upgrade

Module handling is implemented in host software, and the rules can change between releases. If a platform upgrade is planned during the life of the equipment, and it usually is, include a retest in the upgrade plan rather than discovering the outcome during the change window. The retest is short: confirm the module is still recognised, the port still comes up, the identification output is unchanged and the diagnostics still read correctly. Keep a register of which module build was validated against which software release so that the scope of a retest is obvious. This is also the reason to record the software version in the original report; a result with no version attached cannot be reused when the question next arises.

10Record the result so it can be reused

Write a short report per configuration containing the module part number and serial numbers, the host platform, model, port and software version, the link description including fiber type and route length, the full identification output, the diagnostic readings at start and end of soak, the counter results, the list of resilience checks performed with their outcomes, the date and the name of the person who performed the test. State the conclusion as a pass or fail against the criteria agreed beforehand. Store it with the purchase record and reference it from the bill of materials. A report in this form is reusable evidence; an informal message saying the module worked is not, and will not survive the first disagreement about a later shipment.

11Lock the production configuration

Once a sample passes, convert the result into an instruction for the production order. Reference the sample serial numbers and the identification output, and state that the production build must reproduce that coding for the named platform and software version. Confirm in writing with the supplier which build was tested, and ask whether anything in the build is expected to change before the production shipment. Include the temperature grade, the reach class and any labelling requirement in the same instruction, since those are separate decisions that a coding confirmation does not cover. This step is what prevents the familiar sequence in which a carefully tested sample is followed by a production delivery that behaves differently in the same port.

12Change control on later shipments

Treat every repeat order as a small change rather than a reorder. Reference the original purchase order and the validated configuration, ask whether the build or coding has changed, and repeat a short receiving test on a sample from the new batch: identification output, diagnostics against the datasheet, link bring-up in the intended port and a brief traffic run. Record the batch reference with the result. Ask the supplier to notify you in advance of changes to the internal build or the coding, and agree that arrangement before the first production order rather than after an incident. Most optics problems that reach an operations team originate not in the module that was tested but in the one that arrived afterwards without anyone looking at it.

13Frequently asked questions