It is the most natural expectation in networking: two gigabit ports on the NAS, so copies should run at two gigabit. They do not — and once you see why, you will know exactly what the second port is for, and what to buy instead when one PC really needs more speed.
Plug in the second cable, bond the ports, copy a big file — and the transfer still reports the same ~110 MB/s it did yesterday. Nothing is broken. A single file copy is a single connection, and a single connection is pinned to one physical link. That one rule explains almost every "link aggregation did nothing" complaint ever posted.
Link aggregation decides per connection, not per packet. When your PC starts a transfer, the NAS and switch hash the addresses involved and pick one member link for that whole conversation. Every packet of the copy then travels down that one cable.
This is deliberate, not lazy. Sending one conversation down two cables at once would deliver packets out of order, and TCP reads reordering as damage — it slows down, asks for repeats, and your "faster" setup ends up slower than a single clean port. So every sane implementation pins a flow to a link: one flow, one link, one gigabit ceiling.
The second conversation. A second PC copying at the same time, a backup job running while someone streams a video, sync traffic on one port while the office works on the other — parallel loads spread across the links, and the NAS as a whole pushes far more data than one port allows.
In an office where five PCs hit the NAS all day, a bond or a well-split pair of ports transforms the experience. At a single desk with a single user, it changes nothing you can feel. Judge this upgrade by how many things talk at once, not by one benchmark at one desk.
Run a tool like iperf with parallel streams switched on and it will happily light up both links and report close to 2 Gbps. That number is real — for a lab tool deliberately opening many conversations at once.
A Windows file copy opens one. Measuring with parallel streams and then expecting Explorer to match is exactly how the disappointment gets manufactured. Always test with the workload you actually have: one real copy, from the real PC, of a real file.
There is one honest way a single PC can spread a single file copy over several links: SMB Multichannel. Windows supports it, and Synology supports it on suitable models and DSM versions. Instead of one connection, the PC and NAS open several at once and stripe the transfer across them.
It needs support on both ends, separate interfaces with their own addresses (it is not used over a bond), and matching ports on the PC side too. Where it is available, it is the genuine answer to "one PC, more speed" at gigabit scale. Check your model's documentation — support varies, and it is worth confirming before buying cables.
A single 2.5 GbE or 10 GbE port has no hashing rules at all: every connection, including your one big copy, can use the whole port. That is the upgrade that actually moves a solo user's number.
And in a virtual build like the video's, remember where the ceiling really is. The VMXNET3 adapter is a 10G-class virtual card on paper — but behind it sits the host machine's one physical network port and the switch port it plugs into. Upgrading that single physical link raises the ceiling for the NAS and for every VM sharing the host.
The video builds the multi-port Synology step by step — watch it, then measure your result with one real copy, not a parallel benchmark.
▶️ Watch Full VideoThat number is the combined width of both lanes, not the speed limit for one car. Each single connection still gets one 1 Gbps lane. Two users copying at the same time can use about 220 MB/s between them.
No. Every DSM bond mode distributes whole connections across the links. The modes differ in switch requirements and failover behaviour, never in the one-connection-one-link rule.
Not if it has a job. A separate network, a failover path, or several people using the NAS at once are all real wins. It is only pointless for the one job it cannot do — making a single copy faster.