When 2.5G isn't 2.5G?
When 2.5G isn't 2.5G?
I completed the upgrade of my home network, connecting both main nodes to 2.5Gbe unmanaged switches. Each PC came with a 2.5Gbe NIC, and the cables were either cat5e or cat6 without double verifying. I repeated the process several times for consistency, showing one result per scenario for clarity. I ran iperf3 on Garuda as a test server from Crabaletta. Before starting, I checked if there was any connection to the issue. The second switch was only 1Gbe, and its replacement 2.5Gbe model was just arrived today. I decided to perform both pre- and post tests. Since there’s an ipv4/ipv6 option available, I tried both. What caught my attention was the performance difference: ipv6 showed a slight edge, around 1.09 GBytes per 10 seconds. This might be due to the larger address space overhead, assuming nothing else changed. I’m also considering that the speed measured reflects payload at the IP layer, not raw media rates which include metadata handling. After moving everything to the new switch, I unplugged the old setup and connected the new one. The entire path between the devices should now be 2.5Gbe. The ipv6 test ran smoothly with about 2.73 GBytes per 10 seconds at 2.34 Gbits/sec. For the ipv4 results, they were noticeably lower than expected. I’m exploring further adjustments—maybe checking other protocols or configurations. A note: the reverse ipv4 -reverse command showed similar speeds in Garuda, suggesting directionality might play a role. I also looked into Windows QoS settings; turning it off on Crabaletta helped improve speeds, but not enough to fix the issue. Another user mentioned a thread about potential interference from Windows QoS, which I tested by disabling it on Crabaletta—speeds improved slightly. Overall, Garuda seems to be handling the traffic better than Unraid, which is running only ipv4 and showing slower rates. I’ll likely restart Garuda and see if the trend continues.
Updated driver appears to fix the issue. The previous version wasn't that outdated because the system was created earlier this year and I applied the latest updates available then. Crabaletta > Garuda ipv6 [5] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec sender [5] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec receiver ipv6 reverse [5] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec sender [5] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec receiver ipv4 [5] 0.00-10.01 sec 2.77 GBytes 2.38 Gbits/sec sender [5] 0.00-10.01 sec 2.77 Gbytes 2.37 Gbits/sec receiver ipv4 reverse [5] 0.00-10.01 sec 2.77 Gbytes 2.37 Gbits/sec sender [5] 0.00-10.01 sec 2.76 GBytes
Note some hardware problems persist with Intel 225V rev 1 & 2. Recent reports suggest the issues remain unresolved, so many recommend avoiding those versions and opting for 225V rev 3, 226V, or Realtek instead. If a driver update is released, that would be positive. Just in case you encounter further trouble, feel free to let me know.
There are options to monitor the rev rate through software. The NIC is installed on your motherboard, and you may need to check if a newer driver version improves performance. Sometimes updating the driver or resetting certain configurations can help overcome CPU limitations during disk writes.
Check the HWInfo for details. The easiest way is to read the printed information on the chip. You can identify the revision by examining the code (refer to the table). If needed, inspect the device manager for the card’s properties and look for codes in the description or parameters. B1 and B2 steps are faulty; B3 is correct. Chip Reference Stepping Affected: SLN9D or SLN9C. B1: Yes – SLNJX or SLNJY. B2: Yes – SLNMH or SLMNG. B3: No.
It's challenging to reach the hardware due to its design. This isn't my preferred method yet. I'll attempt it next time I need access. Note: Photos of the mobo show the chip is hidden by a heatsink/shroud near the IO port. The serial number is listed as PCI\VEN_8086&DEV_15F3&REV_03. The device description reads "Intel® Ethernet Controller (3) I225-V." The "(3)" might refer to a specific version. I assumed it could point to alternate instances, similar to how Chrome stores multiple files of the same name. I suspect it would be at the end if present.
The chip is typically located between the IO shield and the sound chip. You can identify it by the electrolytic capacitors around it, which are essential for the analog audio amplifier and often set apart visually from other components for improved sound quality. In rare instances, it might be positioned behind the IO shield, between the IO shield and the VRM—where the power supply components reside. More commonly, they house USB 2 hubs or USB 3 hubs/repeaters, though sometimes network chips are placed there, particularly 10G models to aid cooling via the VRM heatsink. The (3) is likely a counter, possibly a third driver version or similar.