Modern systems should not have trouble achieving 2.5Gb/s with standard 1500 byte frames. Typically you start to see issues when it is very small frames, and there are vastly more of them. Anyway, the greater the number of packets, the greater the resources required to process them, primarily the NIC and CPU.
2.5GbE network not running as expected
- Thread starter PlannerOne
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
@prdtabim I apologize, I'm not clear on what you are asking me to do. You want me to ping one of the adapter IP from the other adapter IP?
Such as ping 192.168.1.51 -f -l 1500?
What response should I be looking for, or, what will this test tell me?
@aero I completely agree, so something isn't right. I just don't know what. The CPU is i8700k. I have seen both NICs reviewed/tested and no issues running as expected. Therefore with my limited network experience, I don't know how many options I have left. To me, this should have been pretty easy to implement out of the box. That's why I haven't just thrown more money at this, it should work.
Such as ping 192.168.1.51 -f -l 1500?
What response should I be looking for, or, what will this test tell me?
@aero I completely agree, so something isn't right. I just don't know what. The CPU is i8700k. I have seen both NICs reviewed/tested and no issues running as expected. Therefore with my limited network experience, I don't know how many options I have left. To me, this should have been pretty easy to implement out of the box. That's why I haven't just thrown more money at this, it should work.
The ping process will be sucessfull if the payload could be send without fragmentation.@prdtabim I apologize, I'm not clear on what you are asking me to do. You want me to ping one of the adapter IP from the other adapter IP?
Such as ping 192.168.1.51 -f -l 1500?
What response should I be looking for, or, what will this test tell me?
@aero I completely agree, so something isn't right. I just don't know what. The CPU is i8700k. I have seen both NICs reviewed/tested and no issues running as expected. Therefore with my limited network experience, I don't know how many options I have left. To me, this should have been pretty easy to implement out of the box. That's why I haven't just thrown more money at this, it should work.
Ex. MTU 1500 ping -f -l 1500 will not be ok because the limit is 1472 ( subtract 28 bytes for headers )
MTU 1500 ping -f -l 1340 will be ok
MTU 9000 ping -f -l 5800 will be ok
The main goal of the jumbo frame ( MTU >> 1500 ) is to transfer the same amount of data using less headers and much less packets.
Fragmentation is a layer 3 function, done by routers. If your MTU is too large for layer 2 switching, the frames would simply be dropped.
It's fine to leave the MTU at 9000 generally speaking, if your switch supports it.
Other traffic, e.g. out to the internet, will be fine since TCP connections also announce something called MSS to each other (the Maximum Segment Size they can handle).
It's fine to leave the MTU at 9000 generally speaking, if your switch supports it.
Other traffic, e.g. out to the internet, will be fine since TCP connections also announce something called MSS to each other (the Maximum Segment Size they can handle).
In the actual case the tplink switch support 10k frames. I sugest the use of mtu 9000 for the easy compatibility even on old devices and to achieve the bandwidth of the 2.5Gb/s ( or close to ) in the interface.Fragmentation is a layer 3 function, done by routers. If your MTU is too large for layer 2 switching, the frames would simply be dropped.
It's fine to leave the MTU at 9000 generally speaking, if your switch supports it.
Other traffic, e.g. out to the internet, will be fine since TCP connections also announce something called MSS to each other (the Maximum Segment Size they can handle).
I have two computers, both with the 2.5Gb NIC, going to the 2.5Gb switch. I also have my Asustor AS5304T, with it's 2.5Gb port, going to this switch.
The NIC drivers only have a drop down list under jumbo frame. It is 9014. There is no 9000.
The NAS MTU selection is even numbers, i.e. 9000.
So I am unable to match numbers of all the devices on the 2.5Gb devices.
I will say at this point I'm perfectly fine with using jumbo frame if it gets the speed where it should be. I'm concerned about the MTU not matching exactly and what risk that present.
The NIC drivers only have a drop down list under jumbo frame. It is 9014. There is no 9000.
The NAS MTU selection is even numbers, i.e. 9000.
So I am unable to match numbers of all the devices on the 2.5Gb devices.
I will say at this point I'm perfectly fine with using jumbo frame if it gets the speed where it should be. I'm concerned about the MTU not matching exactly and what risk that present.
Even unmatched the bigger MTU is better in your case.I have two computers, both with the 2.5Gb NIC, going to the 2.5Gb switch. I also have my Asustor AS5304T, with it's 2.5Gb port, going to this switch.
The NIC drivers only have a drop down list under jumbo frame. It is 9014. There is no 9000.
The NAS MTU selection is even numbers, i.e. 9000.
So I am unable to match numbers of all the devices on the 2.5Gb devices.
I will say at this point I'm perfectly fine with using jumbo frame if it gets the speed where it should be. I'm concerned about the MTU not matching exactly and what risk that present.
Other details that can affect the performance
in driver advanced properties ( windows )
- see number of tx buffers and rx buffers ( must be tuned to best performance = trial and error )
- green ethernet ( disable to best performance )
- flow control ( disable to best performance )
- power saving mode ( disable to best performance )