Comparison: Intel i350-T4 Genuine vs Fake

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Samir

Post Liker and Deal Hunter Extraordinaire!
Jul 21, 2017
3,616
1,699
113
50
HSV and SFO
Been told HP and it does seems like one. It does seems legit and genuine HP enterprise version. But I'm not 100% sure. There're some suspicion here and there (QA, Component printing (even embossed)).

Just that it's frustrating to just being able analyze it only on the physical level. Never ending.
Yes, very frustrating indeed. And this problem only exists because there are people that think fakes and counterfeits are acceptable and continue to purchase them--otherwise fakes would be a product looking for a market vs a supply filling a demand. This is one of the 'features' created by the race to the bottom that buying by price alone has encouraged.
 

Stephan

Well-Known Member
Apr 21, 2017
1,047
809
113
Germany
Yesterday I bought another 3 I350-T4 for my custom Proxmox cluster servers. Aiming to utilize the SR-IOV feature.
Any particular reason why SR-IOV on Proxmox? At 1 Gbps any emulated NIC should be just as good and less trouble, like finding a card which supports it on your motherboard.

Cards look okay and good quality. Chinese copy, clone or not, why not buy n+1 so you have a spare. And be done in no time?
 
  • Like
Reactions: Samir

citd

New Member
Dec 10, 2023
5
5
3
Any particular reason why SR-IOV on Proxmox? At 1 Gbps any emulated NIC should be just as good and less trouble, like finding a card which supports it on your motherboard.

Cards look okay and good quality. Chinese copy, clone or not, why not buy n+1 so you have a spare. And be done in no time?
My background actually a retired Hardware Accelerated engineer. A noob one

IMO, in single node Proxmox should not be a problem. But in clustered VM nodes / servers.

SR-IOV : Hardware Accelerated.
Proxmox VE : Software Accelerated.

INFO : HA - Hardware Accelerator, physically exist in shape of circuit + maybe firmware. Nowadays HA(hardware accelerated) circuit are built in an integrated FPGA module (SoC) such as in Oscilloscope, etc. where updating the firmware will give the manufacturer the opportunity in updating the new logical circuit itself. not just software. But AFAIK in I350 SR-IOV is not built in FPGA. Just physical circuit and firmware.

HA should significantly relieves CPU utilization and overhead in managing Proxmox virtual network brigde (vmbr0, etc). I never actually compared the actual result for SR-IOV since this is my 1st mini data center (haha. more to homelab).

VF - Virtual Function, resources sharing (Proxmox VE or VMWare)
vs
PF - Physical Function, resources sharing (SR-IOV, direct resource access between cluster nodes through NIC PCIe)

Regardless at which level the traffic / bandwidth. Main objective is to pass the virtualization job to the SR-IOV in I350 chipset bypassing HyperVisor kernel and reduce CPU overhead.

Still in Networking and Server System I'm totally a beginner. Please correct me if I'm wrong.
 
Last edited:
  • Like
Reactions: Samir

Samir

Post Liker and Deal Hunter Extraordinaire!
Jul 21, 2017
3,616
1,699
113
50
HSV and SFO
I never actually compared the actual result for SR-IOV since this is my 1st mini data center (haha. more to homelab).
This would be interesting to have quantified somewhere, but I'm sure as all things the benefits would vary based on load, generation of cpu hardware, exact data being transferred, etc, etc. Still would be nice to see something like 'minimum 4% benefit and maximum 40%' or something like that.
 

citd

New Member
Dec 10, 2023
5
5
3
And did I mentioned?

HA is FASSST. Significantly faster over SA.

That's the reason why Intel acquired Altera, AMD got Xilinx (Altera definitely losing to Xilinx). Lisa Su is beast.
 
  • Like
Reactions: Samir

Samir

Post Liker and Deal Hunter Extraordinaire!
Jul 21, 2017
3,616
1,699
113
50
HSV and SFO
And did I mentioned?

HA is FASSST. Significantly faster over SA.

That's the reason why Intel acquired Altera, AMD got Xilinx (Altera definitely losing to Xilinx). Lisa Su is beast.
Ah, I see. But is that in a purely technical aspect (as hardware is always faster than software), or in your real-world results?
 

mrpops2ko

New Member
Feb 12, 2017
5
4
3
34
Ah, I see. But is that in a purely technical aspect (as hardware is always faster than software), or in your real-world results?
theres a myriad of reasons to use SR-IOV and it is really good. i've done some benchmarking on it already and when you compare vmxnet3 vs SR-IOV i was getting something like 300us with vmxnet3 and sub 100us with SR-IOV. i can do a VF to VF ping now and show you.

Code:
root@alexandria:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.123 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.069 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.075 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.080 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.068 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.073 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.114 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.082 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.084 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=0.106 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.071 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.105 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.059 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=0.095 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.081 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=0.084 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=0.101 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=0.057 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=0.090 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=0.062 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=0.066 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=0.072 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=0.082 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=0.072 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=0.068 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=0.097 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=0.102 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=0.103 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=0.060 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=0.052 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=0.073 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=0.075 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=0.072 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=0.074 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=0.105 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=0.081 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=0.062 ms
^C
--- 192.168.1.1 ping statistics ---
39 packets transmitted, 39 received, 0% packet loss, time 38889ms
rtt min/avg/max/mdev = 0.052/0.080/0.123/0.017 ms
this is with an intel x520.

the benefits though are numerous, you get the lower latency, you get hardware offloading (so all the TCP checksumming, hashing etc are all done by hardware rather than software), you get kernel bypass (the VFs appear just like regular nic's that you attach to each VM / LXC / container) which results in the chain of travel the packet just being DMA'd from point to point in the chain rather than having software do it all.

SR-IOV is mandatory in any of the telco field because SR-IOV is the only thing capable of handling all those small packets. usually its combined with openstack / ovs and DPDK if you are one of the big boys. SR-IOV and DPDK combined are supposed to be the god tier implication with poll drivers.
 
  • Like
Reactions: citd

citd

New Member
Dec 10, 2023
5
5
3
theres a myriad of reasons to use SR-IOV and it is really good. i've done some benchmarking on it already and when you compare vmxnet3 vs SR-IOV i was getting something like 300us with vmxnet3 and sub 100us with SR-IOV. i can do a VF to VF ping now and show you.

Code:
root@alexandria:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.123 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.069 ms

--- 192.168.1.1 ping statistics ---
39 packets transmitted, 39 received, 0% packet loss, time 38889ms
rtt min/avg/max/mdev = 0.052/0.080/0.123/0.017 ms
this is with an intel x520.
That is it. Thanks for the heads up. Now I know what to expect at the very least.

I350 expected to have a lower latency on SR-IOV statistically (uncertain configuration) over X520 even though the later are considered more powerful. Expecting higher latency ratio on Virtual Adaptor (vmxnet3 over SR-IOV). SW base VS HW base.