项目背景

Nynov did not begin as a complete team. In January 2024, we entered the industry, starting out by selling firmware. In September 2025, the first two-machine project shipped and the team was formally formed. From that point on, we began facing head-on the problem that kept recurring and that everyone else kept sidestepping: how to make acquisition and isolation solutions stable and efficient under system isolation (VT-D). There was no ready answer and no off-the-shelf tool. We first broke it down into a few very concrete scenarios:

• —RPC dual-conversion — the earliest network version, but by the end of last year it ran into problems such as latency from data transmission (200t) and network fluctuation;
• —An earlier alternative tried conversion at the application layer, but adaptation to many systems was problematic and handshakes failed, leaving only vague errors in the logs;
• —RTL8125 — we were the first team to propose this approach; the development process is full of notes like "tried here" and "didn't work there," and eventually yielded a workable solution — the prototype of what the market now calls 8125;
• —RDMA — building on 8125 and other network cards in real conditions, we developed Nynov RDMA, which we consider the better acquisition solution today;
• —VT-D FW — isolation firmware has long been another direction for our R&D team; we have now spent four months on it and completed the full development of the isolation firmware.

"The acquisition layer (observation)" and "system compatibility" are two constraints that pull against each other. Observation itself disturbs the object under test: one more cable, one more process, one more config change, and the machine's behavior may drift from what it naturally does. What you then see is no longer the machine you wanted to see. This is the well-worn "observer effect" in engineering, but on site it is routinely underestimated — until halfway through troubleshooting you realize the data you relied on was produced only after observation interfered.

• —Buy a generic solution off the shelf and it covers "most cases," but not "stable over the long run";
• —Modify the existing system and you can fix things for a while, but not the two layers of low-level timing and isolation;
• —Skirting the low level with a software shortcut is easiest, but the cost is leaving uncertainty somewhere you cannot see, with no way to trace it when things break on site.

We did not treat it as a "product" to ship, but as a problem we would face for the long haul, and took it apart. The work split into two halves, each answering one constraint:

• —Driver layer — responsible for getting the data right. The goal is to capture all data from the machine running natively, not from an unreasonable channel.
• —Hardware layer — responsible for isolating the environment. The goal is to keep reading and correctness from interfering with each other, so connecting in does not change how the machine originally runs.

Both lines obey one baseline rule: never interrupt the machine's original way of running. Anything that would alter the behavior of the object under test is off the table. In practice, the two lines eventually crystallized into self-developed firmware and drivers: deeply customized on mainstream NIC platforms, with stable links and low packet loss over long continuous runs; covering mainstream motherboards and system versions, with compatibility regression completed before shipment. This is not a one-off delivery but a habit carried over from the earliest version — treating "stability" and "compatibility" as engineering metrics to verify repeatedly, not a line on a spec sheet.

The problem did not change; the names did, several times. From the earliest version to today's product lines, the lineage is roughly:

• —RPC dual-conversion — the first version, solving the most urgent need at the time: "getting two machines to talk";
• —early application-layer conversion — moving beyond RPC dual-conversion to expand coverage into the application layer;
• —RDMA — one of today's shipping product lines, covering NIC driver development;
• —VT-D FW — the other line, covering isolation firmware development.

Along the way we also took on many projects from the market. Each one was not a mere delivery but a chance to make the words "stability" and "compatibility" more concrete: edge cases seen on site, handshake sequences the manual never spelled out, timing quirks specific to a certain motherboard — these experiences went into our own firmware and drivers and became part of the next version. We entered the industry in January 2024, starting from selling firmware; in September 2025, the first two-machine project shipped and the team was formally formed. Since then we have kept developing, striving tirelessly to solve our customers' problems.

We are clear about the boundaries of this kind of work, and on that basis we set ourselves three principles:

• —Restraint — we do not chase good-looking numbers on a spec sheet; we only chase links that stay stable after long runs.
• —Honesty — we write clearly what we can do and do not promise what we cannot. A warning spoken in advance beats ten apologies afterward.
• —Long-term — we are willing to put practice into every customer's compatibility problem, so every cent of theirs lands where it should.

The compliance boundary is equally clear: all products on this site are limited to legally authorized own devices and compliant business scenarios. Users must ensure their use complies with local laws and the terms of any third parties involved. What we provide is a tooling method for observation and isolation — we do not replace nor participate in any modification of a device's original business.

The story is not finished. If you too are waiting for an answer no one else would take on, we probably speak the same language.