Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test 4-interface Intel NIC I340-T4 #3

Closed
geerlingguy opened this issue Oct 22, 2020 · 78 comments
Closed

Test 4-interface Intel NIC I340-T4 #3

geerlingguy opened this issue Oct 22, 2020 · 78 comments

Comments

@geerlingguy
Copy link
Owner

geerlingguy commented Oct 22, 2020

I ordered a Intel I340-T4 PCIe x4 4-port Gigabit Network Adapter (specs, and am waiting for it to arrive. I would like to see if this adapter also requires the BAR space expansion that the GPU required (see #2), and also whether I can see all four interfaces over the PCIe x1 2.0 bus, or whether I can only see some of them.

The card itself is an x4 card, meaning it won't slot into the stock PCIe x1 slot on the Compute Module. I could hack into it with a dremel, but instead, I bought an x16 to x1 riser/adapter: PCI-e PCI Express 1X to 16X Extension Cable.

We'll see if I can get it working! I have the 1x to 16x cable already, just waiting on the GigE adapter to come in.

Edit: Here's the card plugged into the IO Board:

intel-i340-16x-1x-raspberry-pi-cm4

@annunity
Copy link

Looking forward to the results. I am curious if it will work with something like openwrt and make a killer home router. Cheers

@geerlingguy
Copy link
Owner Author

@annunity you and me both! I just got it plugged in for my initial "I should be getting to bed but I'll test this instead" routine :)

@geerlingguy
Copy link
Owner Author

$ lspci
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
01:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
01:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
01:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)

So far so good. One of the interfaces using -vv:

$ sudo lspci -vv
...
01:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
	Subsystem: Intel Corporation Ethernet Server Adapter I340-T4
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin D routed to IRQ 0
	Region 0: Memory at 600200000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Region 3: Memory at 60028c000 (32-bit, non-prefetchable) [disabled] [size=16K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
		Address: 0000000000000000  Data: 0000
		Masking: 00000000  Pending: 00000000
	Capabilities: [70] MSI-X: Enable- Count=10 Masked-
		Vector table: BAR=3 offset=00000000
		PBA: BAR=3 offset=00002000
	Capabilities: [a0] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <32us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Device Serial Number 90-e2-ba-ff-ff-33-72-64
	Capabilities: [1a0 v1] Transaction Processing Hints
		Device specific mode supported
		Steering table in TPH capability structure

@geerlingguy
Copy link
Owner Author

PCIe interface seems happy with the default BAR space:

[    0.870492] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[    0.870517] brcm-pcie fd500000.pcie:   No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[    0.870589] brcm-pcie fd500000.pcie:      MEM 0x0600000000..0x0603ffffff -> 0x00f8000000
[    0.870660] brcm-pcie fd500000.pcie:   IB MEM 0x0000000000..0x00ffffffff -> 0x0100000000
[    0.926496] brcm-pcie fd500000.pcie: link up, 5 GT/s x1 (SSC)
[    0.926820] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    0.926839] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.926860] pci_bus 0000:00: root bus resource [mem 0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff])
[    0.926920] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400
[    0.927192] pci 0000:00:00.0: PME# supported from D0 D3hot
[    0.930550] PCI: bus0: Fast back to back transfers disabled
[    0.930573] pci 0000:00:00.0: bridge configuration invalid ([bus ff-ff]), reconfiguring
[    0.930801] pci 0000:01:00.0: [8086:150e] type 00 class 0x020000
[    0.930890] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0007ffff]
[    0.930961] pci 0000:01:00.0: reg 0x1c: [mem 0x00000000-0x00003fff]
[    0.931032] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[    0.931278] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    0.931374] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5 GT/s x1 link at 0000:00:00.0 (capable of 16.000 Gb/s with 5 GT/s x4 link)
[    0.931607] pci 0000:01:00.1: [8086:150e] type 00 class 0x020000
[    0.931691] pci 0000:01:00.1: reg 0x10: [mem 0x00000000-0x0007ffff]
[    0.931762] pci 0000:01:00.1: reg 0x1c: [mem 0x00000000-0x00003fff]
[    0.932046] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
[    0.932329] pci 0000:01:00.2: [8086:150e] type 00 class 0x020000
[    0.932412] pci 0000:01:00.2: reg 0x10: [mem 0x00000000-0x0007ffff]
[    0.932482] pci 0000:01:00.2: reg 0x1c: [mem 0x00000000-0x00003fff]
[    0.932765] pci 0000:01:00.2: PME# supported from D0 D3hot D3cold
[    0.933045] pci 0000:01:00.3: [8086:150e] type 00 class 0x020000
[    0.933128] pci 0000:01:00.3: reg 0x10: [mem 0x00000000-0x0007ffff]
[    0.933199] pci 0000:01:00.3: reg 0x1c: [mem 0x00000000-0x00003fff]
[    0.933482] pci 0000:01:00.3: PME# supported from D0 D3hot D3cold
[    0.936779] PCI: bus1: Fast back to back transfers disabled
[    0.936799] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    0.936845] pci 0000:00:00.0: BAR 8: assigned [mem 0x600000000-0x6002fffff]
[    0.936884] pci 0000:01:00.0: BAR 0: assigned [mem 0x600000000-0x60007ffff]
[    0.936910] pci 0000:01:00.0: BAR 6: assigned [mem 0x600080000-0x6000fffff pref]
[    0.936928] pci 0000:01:00.1: BAR 0: assigned [mem 0x600100000-0x60017ffff]
[    0.936953] pci 0000:01:00.2: BAR 0: assigned [mem 0x600180000-0x6001fffff]
[    0.936978] pci 0000:01:00.3: BAR 0: assigned [mem 0x600200000-0x60027ffff]
[    0.937002] pci 0000:01:00.0: BAR 3: assigned [mem 0x600280000-0x600283fff]
[    0.937027] pci 0000:01:00.1: BAR 3: assigned [mem 0x600284000-0x600287fff]
[    0.937052] pci 0000:01:00.2: BAR 3: assigned [mem 0x600288000-0x60028bfff]
[    0.937076] pci 0000:01:00.3: BAR 3: assigned [mem 0x60028c000-0x60028ffff]
[    0.937107] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.937131] pci 0000:00:00.0:   bridge window [mem 0x600000000-0x6002fffff]
[    0.937449] pcieport 0000:00:00.0: enabling device (0140 -> 0142)
[    0.937692] pcieport 0000:00:00.0: PME: Signaling with IRQ 55
[    0.938097] pcieport 0000:00:00.0: AER: enabled with IRQ 55

@geerlingguy
Copy link
Owner Author

However, not seeing the new interfaces by default:

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:5c:89:43 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DORMANT group default qlen 1000
    link/ether b8:27:eb:74:f2:6c brd ff:ff:ff:ff:ff:ff

@geerlingguy
Copy link
Owner Author

Glancing around in make menuconfig I didn't see any relevant Intel drivers for networking... so I went on their website and found the "Intel® Ethernet Adapter Complete Driver Pack" which says it's compatible with the "Intel® Ethernet Server Adapter I340-T4". It does mention in the README that 32-bit Linux is supported, but I could find no mention of ARM anywhere.

To download the .zip archive, you have to do it in a browser since it requires the manual acceptance of a download license. That's annoying, because I had to download it to my Mac then copy it over to the Pi via SCP.

@geerlingguy
Copy link
Owner Author

All right, so after digging into that process and realizing that downloads like the entire universe of Windows and Linux drivers in a giant archive, I found that the Intel Linux base driver page mentions:

igb-x.x.x.tar.gz driver: Supports all 82575/6, 82580, I350, I354, and I210/I211 based gigabit network connections.

So I downloaded that driver and manually copied it to the Pi, then:

$ tar zxf igb-5.4.6.tar.gz
$ cd igb-5.4.6/src/
$ make install
make[1]: Entering directory '/home/pi/linux'
  CC [M]  /home/pi/igb-5.4.6/src/igb_main.o
/home/pi/igb-5.4.6/src/igb_main.c: In function ‘igb_get_os_driver_version’:
/home/pi/igb-5.4.6/src/igb_main.c:10044:7: error: implicit declaration of function ‘isdigit’ [-Werror=implicit-function-declaration]
   if(!isdigit(*c) && *c != '.')
       ^~~~~~~
At top level:
/home/pi/igb-5.4.6/src/igb_main.c:9439:12: warning: ‘igb_resume’ defined but not used [-Wunused-function]
 static int igb_resume(struct device *dev)
            ^~~~~~~~~~
/home/pi/igb-5.4.6/src/igb_main.c:9413:12: warning: ‘igb_suspend’ defined but not used [-Wunused-function]
 static int igb_suspend(struct device *dev)
            ^~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:266: /home/pi/igb-5.4.6/src/igb_main.o] Error 1
make[1]: *** [Makefile:1732: /home/pi/igb-5.4.6/src] Error 2
make[1]: Leaving directory '/home/pi/linux'
make: *** [Makefile:86: default] Error 2

@geerlingguy
Copy link
Owner Author

After seeing noseka1/linuxband#12, I monkey-patched the igb_main.c and added #include <linux/ctype.h> alongside the other includes, and that got things a bit further.

However, now it's complaining about permissions when it tries to copy over manfiles:

...
  MODPOST 1 modules
  CC [M]  /home/pi/igb-5.4.6/src/igb.mod.o
  LD [M]  /home/pi/igb-5.4.6/src/igb.ko
make[1]: Leaving directory '/home/pi/linux'
Copying manpages...
install: cannot create regular file '/usr/share/man/man7/igb.7.gz': Permission denied
make: *** [Makefile:120: install] Error 1

So trying with sudo make install:

$ sudo make install
make[1]: Entering directory '/home/pi/linux'
  Building modules, stage 2.
  MODPOST 1 modules
make[1]: Leaving directory '/home/pi/linux'
Copying manpages...
Installing modules...
make[1]: Entering directory '/home/pi/linux'
  INSTALL /home/pi/igb-5.4.6/src/igb.ko
  DEPMOD  5.4.72-v7l+
make[1]: Leaving directory '/home/pi/linux'
Running depmod...
Updating initramfs...

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

Rebooted and...

$ sudo ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:5c:89:43 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:33:72:64 brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:33:72:65 brd ff:ff:ff:ff:ff:ff
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:33:72:66 brd ff:ff:ff:ff:ff:ff
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:33:72:67 brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DORMANT group default qlen 1000
    link/ether b8:27:eb:74:f2:6c brd ff:ff:ff:ff:ff:ff

BINGO!

Now, time to pull out a gigabit switch and start testing the maximum bandwidth I can pump through everything with iperf! But that will have to wait for another day, as I'm pretty much running on fumes right now.

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

Hehehe this is so dumb but fills me with joy:

IMG_2556

I don't even have enough ports on my little office switch, I'm going to have to go into storage to grab my bigger switch tomorrow.

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b8:27:eb:5c:89:43 brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.120/24 brd 10.0.100.255 scope global dynamic noprefixroute eth0
       valid_lft 86197sec preferred_lft 75397sec
    inet6 fe80::2f77:1eba:a042:9f2a/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 90:e2:ba:33:72:64 brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.45/24 brd 10.0.100.255 scope global dynamic noprefixroute eth1
       valid_lft 86391sec preferred_lft 75591sec
    inet6 fe80::88c:a286:503d:490c/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 90:e2:ba:33:72:65 brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.46/24 brd 10.0.100.255 scope global dynamic noprefixroute eth2
       valid_lft 86345sec preferred_lft 75545sec
    inet6 fe80::10fb:5fd6:67f2:168e/64 scope link 
       valid_lft forever preferred_lft forever
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 90:e2:ba:33:72:66 brd ff:ff:ff:ff:ff:ff
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 90:e2:ba:33:72:67 brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:74:f2:6c brd ff:ff:ff:ff:ff:ff
$ dmesg | grep igb
[    4.192441] igb: loading out-of-tree module taints kernel.
[    4.200685] igb 0000:01:00.0: enabling device (0140 -> 0142)
[    4.201190] igb 0000:01:00.0: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts.
[    4.376204] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Linux Driver
[    4.376225] igb 0000:01:00.0: eth1: (PCIe:5.0GT/s:Width x1) 
[    4.376244] igb 0000:01:00.0 eth1: MAC: 90:e2:ba:33:72:64
[    4.376337] igb 0000:01:00.0: eth1: PBA No: E81600-008
[    4.376353] igb 0000:01:00.0: LRO is disabled
[    4.376371] igb 0000:01:00.0: Using MSI interrupts. 1 rx queue(s), 1 tx queue(s)
[    4.379455] igb 0000:01:00.1: enabling device (0140 -> 0142)
[    4.379940] igb 0000:01:00.1: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts.
[    4.558290] igb 0000:01:00.1: Intel(R) Gigabit Ethernet Linux Driver
[    4.558310] igb 0000:01:00.1: eth2: (PCIe:5.0GT/s:Width x1) 
[    4.558329] igb 0000:01:00.1 eth2: MAC: 90:e2:ba:33:72:65
[    4.558423] igb 0000:01:00.1: eth2: PBA No: E81600-008
[    4.558438] igb 0000:01:00.1: LRO is disabled
[    4.558456] igb 0000:01:00.1: Using MSI interrupts. 1 rx queue(s), 1 tx queue(s)
[    4.558847] igb 0000:01:00.2: enabling device (0140 -> 0142)
[    4.559353] igb 0000:01:00.2: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts.
[    4.736590] igb 0000:01:00.2: Intel(R) Gigabit Ethernet Linux Driver
[    4.736611] igb 0000:01:00.2: eth3: (PCIe:5.0GT/s:Width x1) 
[    4.736639] igb 0000:01:00.2 eth3: MAC: 90:e2:ba:33:72:66
[    4.736731] igb 0000:01:00.2: eth3: PBA No: E81600-008
[    4.736746] igb 0000:01:00.2: LRO is disabled
[    4.736765] igb 0000:01:00.2: Using MSI interrupts. 1 rx queue(s), 1 tx queue(s)
[    4.737172] igb 0000:01:00.3: enabling device (0140 -> 0142)
[    4.737659] igb 0000:01:00.3: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts.
[    4.926383] igb 0000:01:00.3: Intel(R) Gigabit Ethernet Linux Driver
[    4.926403] igb 0000:01:00.3: eth4: (PCIe:5.0GT/s:Width x1) 
[    4.926421] igb 0000:01:00.3 eth4: MAC: 90:e2:ba:33:72:67
[    4.926513] igb 0000:01:00.3: eth4: PBA No: E81600-008
[    4.926529] igb 0000:01:00.3: LRO is disabled
[    4.926546] igb 0000:01:00.3: Using MSI interrupts. 1 rx queue(s), 1 tx queue(s)

And after plugging in another connection to one of the jacks on the board:

[  200.034885] igb 0000:01:00.3 eth4: igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[  200.035107] IPv6: ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready

@annunity
Copy link

Haha nice. Probably still less messy this using 4 usb nics. This is definitely one of those because you can sort of projects.

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

So one thing I would like to take a look at is OpenWRT. And just seeing how many bits I can push through the Pi per second using iperf. Any other uses people can think of for having 5 interfaces on one Pi (besides the obvious, like having an Apache HTTP site running on each hard IP address, which is not as interesting to me nowadays).

Edit: Some ideas to test:

@annunity
Copy link

Just a heads up. Openwrt for the pi 4 is still using daily snapshots or you can compile it yourself. The snapshots work fine if you are just testing but you will have trouble updating the packages after a while. The main appeal for me is to use load balancing or vlans in Openwrt. Beats having a large expensive switch.

geerlingguy added a commit that referenced this issue Oct 28, 2020
@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

Just testing one interface with iperf:

On the Pi:

$ sudo apt install -y iperf
$ iperf --bind 10.0.100.48 --server

On my Mac:

$ iperf -c 10.0.100.48
------------------------------------------------------------
Client connecting to 10.0.100.48, TCP port 5001
TCP window size:  201 KByte (default)
------------------------------------------------------------
[  4] local 10.0.100.118 port 56661 connected with 10.0.100.48 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec

Just doing a quick test on my Mac with two interfaces, I found that I got:

483 Mbits/sec # 10.0.100.48
481 Mbits/sec # 10.0.100.120

So 964 Mbits/sec total, which just shows that my local 1 Gbps switch has, as expected, 1 Gbps of total capacity.

Now, I think what I'll do to try to test all five GigE ports at once is to have my Pi Dramble (4x Pi 4s) connecting directly to each of the ports on the Intel NIC, with a hardcoded IP address for each connection.

Then have my Mac connected over the network to the wired Ethernet on the CM4.

Then set up five instances of iperf --bind [interface ip] --server on the CM4, and then have Ansible trigger iperf -c [interface ip] for each of the Pis, plus localhost, at the same time (--forks 5).

This could get messy. I know the cabling at least will get messy.

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

For each Pi, I prepped the boot volume with:

# First, flash 64-bit Pi OS lite to it via Raspberry Pi Imager.

# Second, touch ssh file so I can access it.
$ touch /Volumes/boot/ssh

# Third, write a wpa_supplicant file so it connects to my WiFi.
$ cat > /Volumes/boot/wpa_supplicant.conf << EOF
country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
scan_ssid=1
  ssid="ssid_here"
  psk="password_here"
}
EOF

# Fourth, pop card in Pi, boot pi, and watch for it using `fing` on Mac.

# Fifth, mark in separate document the IP and MAC for the Pi.

# Sixth, copy my SSH key to the Pi.
ssh-copy-id pi@[ip address here]

# Seventh, log into the Pi.
ssh pi@[ip address here]

# Eight, configure a static IP in /etc/dhcpcd.conf.
$ sudo nano /etc/dhcpcd.conf
(I'm using range 192.168.0.4-192.168.0.11)

This is a tedious and annoying process, but this is research for science so it is worth it.

The next step will be building a small Ansible playbook that creates little networks for each of the interfaces, using the same IP and netmask between the individual Pis and the Intel NIC interfaces... or maybe doing it all by hand. It's one of those XKCD 1319 issues. (Edit: I went manual for this part.)

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

Now I added a mapping of static IPs to /etc/dhcpcd.conf on the CM4:

interface eth1
static ip_address=192.168.0.11/24
static routers=192.168.0.1

interface eth2
static ip_address=192.168.0.10/24
static routers=192.168.0.1

interface eth3
static ip_address=192.168.0.9/24
static routers=192.168.0.1

interface eth4
static ip_address=192.168.0.8/24
static routers=192.168.0.1

And rebooted. It looks like all the links are up, so it's time to start seeing if I can hit multiple interfaces at the same time and get more than 1 Gigabit pumping through this Pi!

EDIT: That mapping doesn't work, because the independent networks each need different IP ranges, so I set up a new mapping:

# TO PI 4
interface eth1
static ip_address=192.168.0.8/24
static routers=192.168.0.1

# TO PI 3
interface eth2
static ip_address=172.16.0.8/24
static routers=172.16.0.1

# TO PI 2
interface eth3
static ip_address=198.51.100.8/24
static routers=198.51.100.1

# TO PI 1
interface eth4
static ip_address=203.0.113.8/24
static routers=203.0.113.1

And I ran the iperf server on all the interfaces on the CM4:

iperf --bind 192.168.0.8 --server
iperf --bind 172.16.0.8 --server
iperf --bind 198.51.100.8 --server
iperf --bind 203.0.113.8 --server
iperf --bind 10.0.100.120 --server

@geerlingguy
Copy link
Owner Author

For each of the Dramble Pis, I had to get iperf installed:

sudo ifconfig eth0 down
sudo apt update
sudo apt install -y iperf
sudo ifconfig eth0 up

Then I set up five iperf servers (one on each interface on the CM4), and manually triggered a bunch of iperf -c [ip] on each of the Pis individually as well as on my Mac to the primary interface, and... TODO

@geerlingguy
Copy link
Owner Author

Er... I think I need to use a different IP range for each of the interfaces. Ugh, my little text file mapping is going all bonkers now. As I said, tedious!

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 28, 2020

So first quick result, firing off each benchmark one by one:

  1. 626 Mbps
  2. 612 Mbps
  3. 608 Mbps
  4. 606 Mbps
  5. 614 Mbps

Total: 3.06 Gbps

Then I tried just hitting three interfaces on the NIC only, and got:

  1. 935 Mbps
  2. 942 Mbps
  3. 941 Mbps

Total: 2.82 Gbps

Then hitting all four interfaces on the NIC:

  1. 768 Mbps
  2. 769 Mbps
  3. 769 Mbps
  4. 768 Mbps

Total: 3.07 Gbps

Hitting three on the NIC and one on the Pi:

  1. 714 Mbps
  2. 709 Mbps
  3. 709 Mbps
  4. 709 Mbps

Total: 2.84 Gbps

So it seems like there's an upper ceiling around 3 Gbps for total throughput you can get through a Compute Module 4's PCIe slot... and when you couple that with the onboard network interface, it seems like there must be a tiny bit more overhead (maybe the Broadcom Ethernet chip isn't quite as efficient, or maybe having the kernel have to switch between the Intel chip and the Broadcom chip results in that 8% bandwidth penalty?).

I ran all of these sets of tests twice, and they were extremely close in each case.

Now I'm interested to see if I'd be able to pump any more bits through this thing with a 10GbE adapter, or if 2.5 GbE over any individual interface is about as high as it'll go before we hit limits.

@paulwratt
Copy link

paulwratt commented Oct 28, 2020

[ 0.931374] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5 GT/s x1 link at 0000:00:00.0 (capable of 16.000 Gb/s with 5 GT/s x4 link)

So yeah, there is overhead loss somewhere (3.1 Gbps limit atm). To improve this, you might look at those cards that offload from kernel to card driver (see next paragraph). Or it might just be that the drivers are not optimised when working together (on ARM). Do you get any connection over 940-ish Mbps (that seems to be about the limit per connection), which seems pretty good under the circumstances (and on par with other platforms).

I predict 6 months worth of work for actual real-world use (kernel and driver patches/updates), would have this running reliably at max speeds. But you would obviously need a reason for this real-world use case (and probably an income at the end :) - eg High Performance Dramble Cluster 5, 1xCM4 + 4xRPi4 with 4x1Gb PCIe ethernet kit (and no need for a switch).

I am wondering what sort of reliability comes from sustained-use-testing (24/48 hours) particularly thermals, ie can the CM4 and host-board handle it under sustained high-load conditions, or does something slowdown or heatup too much

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 29, 2020

I predict 6 months worth of work for actual real-world use (kernel and driver patches/updates), would have this running reliably at max speeds.

Heh, don't tempt me!

I've definitely considered building myself a custom Pi switch / router with this card... though I have some other much more pressing projects right now, especially after the response from my last video.

I am wondering what sort of reliability comes from sustained-use-testing (24/48 hours) particularly thermals, ie can the CM4 and host-board handle it under sustained high-load conditions, or does something slowdown or heatup too much.

In the few hours that I was testing it today, it got slightly warm, but not hot (fan blowing over the whole rig throughout). The SATA card I'm testing got much hotter, though I keep forgetting to pull out my Seek thermal cam to take a few pictures on the front and back of the board.

@geerlingguy
Copy link
Owner Author

Another note on the build: if running the 64-bit beta of Pi OS, it seems that you might run into:

$ make install
common.mk:82: *** Kernel header files not in any of the expected locations.
common.mk:83: *** Install the appropriate kernel development package, e.g.
common.mk:84: *** kernel-devel, for building kernel modules and try again.  Stop.

And that seems to be because even if you install the headers with sudo apt install -y raspberrypi-kernel-headers, they are in a nonstandard location (I had the same issue with compiling the Nvidia graphics card drivers).

@markbirss
Copy link

@theofficialgman
Copy link

iperf can be quite cpu limited since it is a single threaded process. You might be running into a bottleneck because of lacking cpu performance on the pi cm4. The client in iperf has to do more cpu work than the server so you are getting as good of performance as you can get in terms of your setup with the cm4 being the server. I find iperf3 to be more performant than iperf in general so you might want to try that.

Also, the -Z, --zerocopy of iperf3 can allow for better performance as well (because it uses less cpu cycles)
(copied from my youtube comment)

@theofficialgman
Copy link

theofficialgman commented Oct 30, 2020

one more thing: pcie 2 at 1X is limited to 500MB/s (or 4gb/s) in each direction. might be interesting to do a role reversal (-R) on a couple of the clients to see what happens in terms of total bandwidth utilized (RX+TX). since right now all the bandwidth is in one direction

@geerlingguy
Copy link
Owner Author

@theofficialgman - Good suggestions! I have the rig running currently and I'm going to do a few more tests with some suggestions I've gotten in the comments.

@geerlingguy
Copy link
Owner Author

geerlingguy commented Oct 30, 2020

Aha! We might be getting closer. The CPU itself still seems to have headroom, but I noticed the process ksoftirqd was hitting 99%-100% CPU the whole time, and I'm guessing it's single-threaded.

I just created a new Ansible playbook to run these tests a lot more quickly/easily so I can better observe the board while the tests are running (I'll add it to an 'extras' dir in this repository soon), and I'm now seeing that running everything at exactly the same time (I had a small lag when I wasn't using Ansible's immediate forks) gets me:

  • 559 Mbps
  • 560 Mbps
  • 560 Mbps
  • 561 Mbps
  • 573 Mbps

...which is still 2.81 Gbps total. In the words of the young'ns playing Among Us, that ksoftirqd process looks a little 'sus':

Screen Shot 2020-10-30 at 3 26 19 PM

As good an answer as any from @luciang:

Your computer communicates with the devices attached to it through IRQs (interrupt requests). When an interrupt comes from a device, the operating system pauses what it was doing and starts addressing that interrupt.

In some situations IRQs come very very fast one after the other and the operating system cannot finish servicing one before another one arrives. This can happen when a high speed network card receives a very large number of packets in a short time frame.

Because the operating system cannot handle IRQs as they arrive (because they arrive too fast one after the other), the operating system queues them for later processing by a special internal process named ksoftirqd.

If ksoftirqd is taking more than a tiny percentage of CPU time, this indicates the machine is under heavy interrupt load.

@geerlingguy
Copy link
Owner Author

geerlingguy commented Nov 3, 2020

Ooh... I finally successfully cross-compiled Raspberry Pi OS Linux from my Mac (inside VirtualBox) over to one of the Pi 4s. Adding a Vagrantfile and README to assist others with that process very soon... should probably also do a video on it, or talk about the process in the follow-up networking video.

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq state DOWN group default qlen 1000
    link/ether dc:a6:32:02:6f:de brd ff:ff:ff:ff:ff:ff

Edit: But it seems like it might not be working — plugging it direct into the CM4 I get DOWN still. Might have to do a little more digging, was hoping for a quick win, but it's never easy, is it?

Edit 2: Hahaha, it helps if you plug in the network card, doesn't it?

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 203.0.113.7  netmask 255.255.255.0  broadcast 203.0.113.255
        inet6 fe80::7f85:35b4:5263:1b54  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:02:6f:de  txqueuelen 1000  (Ethernet)
        RX packets 266  bytes 49777 (48.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 181  bytes 30761 (30.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

@geerlingguy
Copy link
Owner Author

Latest result with MTU 9000: 3.36 Gbps

@mayli
Copy link

mayli commented Nov 4, 2020

Does that number includes the onboard NIC? Quite impressive since there folks pointing out it could be the bottleneck of the pcie x1

@geerlingguy
Copy link
Owner Author

geerlingguy commented Nov 4, 2020

Oops, MTU was still 1500 on the Intel side. Must've reverted after a few reboots and re-plugs today. Had to run:

sudo ip link set dev eth1 mtu 9000
sudo ip link set dev eth2 mtu 9000
sudo ip link set dev eth3 mtu 9000
sudo ip link set dev eth4 mtu 9000

Ran the benchmark playbook again, and what do you know?

Interface Bandwidth
eth0 (built-in) 942 Mbps
eth1 804 Mbps
eth2 799 Mbps
eth3 802 Mbps
eth4 803 Mbps
TOTAL: 4.15 Gbps

Testing just the four interfaces on the card, I get:

Interface Bandwidth
eth1 801 Mbps
eth2 805 Mbps
eth3 806 Mbps
eth4 803 Mbps
TOTAL: 3.22 Gbps

Testing just three of the card's interfaces:

Interface Bandwidth
eth1 990 Mbps
eth2 991 Mbps
eth3 991 Mbps
TOTAL: 2.97 Gbps

And testing three of the card's interfaces plus the onboard:

Interface Bandwidth
eth0 (built-in) 941 Mbps
eth1 990 Mbps
eth2 989 Mbps
eth3 989 Mbps
TOTAL: 3.91 Gbps

So, seems logical that PCIe 2.0 x1 lane is maxing out right around 3.2 Gbps. Also confirmed that with jumbo packets / MTU 9000, the irq CPU usage was hovering around 50% maximum with all 5 interfaces going full throttle. It was 99% before, causing the slowdown.

And also, I can confirm the Pi Compute Module 4 can be overclocked to 2.20 GHz, just like the Pi 400. Though it needs better cooling to stay running that fast ;)

4.15 Gbps ain't too shabby on a single Pi. I remember back in my early Pi cluster days when I salivated over getting 200-300 Mbps... 😂

@geerlingguy
Copy link
Owner Author

Posted a new video: 4+ Gbps Ethernet on the Raspberry Pi Compute Module 4

@JulyIghor
Copy link

JulyIghor commented Nov 7, 2020

Ooh... I finally successfully cross-compiled Raspberry Pi OS Linux from my Mac (inside VirtualBox) over to one of the Pi 4s.

Using VM is always slower than run under host.
You can compile gcc to cross-compile any target architecture directly on a macOS.
Most important thing that you have to use case-sensitive file system to compile a linux kernel.
I do have cross compilers for various target CPUs on macOS and that is working great with no VMs and with gdb support.
Let me know if you wish to know more, I'll be happy to share instructions.

@chinmaythosar
Copy link

chinmaythosar commented Dec 13, 2020

2.5

So about this STH has this adapter reviewed (https://www.servethehome.com/syba-dual-2-5-gigabit-ethernet-adapter-review/) that could make it possible to do two 2.5Gbps ports. I don't know how much the CPU can handle but that would effectively give you two 2.5Gbps ports for routing with a cheap switch (https://www.anandtech.com/show/15916/at-last-a-25gbps-consumer-network-switch-qnap-releases-qsw11055t-5port-switch) and the original port for ISP ... In fact I actually would be interested in making a board with just that. Compute module, the ASMedia PCI switch connected to two Intel 2.5 NICs, the third gigabit port, a Micro SD slot for those without EMMC, and a barrel connector so that you can find cheap power adapters. Currently same can be achieved with that adapter and compute module board but would be great to fit all that in size of EdgeRouterX box.

@geerlingguy
Copy link
Owner Author

FYI I'm testing a 2.5GbE adapter in #40.

@chinmaythosar
Copy link

FYI I'm testing a 2.5GbE adapter in #40.

Just checked that thread ... awesome thanks ...

@geerlingguy
Copy link
Owner Author

@chinmaythosar - So... I also decided it would be fun to give the 2-port 2.5 GbE NIC a try; see #46

@geerlingguy
Copy link
Owner Author

Closing issues where testing is at least mostly complete, to keep the issue queue tidy.

@jordibiosca
Copy link

So first quick result, firing off each benchmark one by one:

1. 626 Mbps

2. 612 Mbps

3. 608 Mbps

4. 606 Mbps

5. 614 Mbps

Total: 3.06 Gbps

Then I tried just hitting three interfaces on the NIC only, and got:

1. 935 Mbps

2. 942 Mbps

3. 941 Mbps

Total: 2.82 Gbps

Then hitting all four interfaces on the NIC:

1. 768 Mbps

2. 769 Mbps

3. 769 Mbps

4. 768 Mbps

Total: 3.07 Gbps

Hitting three on the NIC and one on the Pi:

1. 714 Mbps

2. 709 Mbps

3. 709 Mbps

4. 709 Mbps

Total: 2.84 Gbps

So it seems like there's an upper ceiling around 3 Gbps for total throughput you can get through a Compute Module 4's PCIe slot... and when you couple that with the onboard network interface, it seems like there must be a tiny bit more overhead (maybe the Broadcom Ethernet chip isn't quite as efficient, or maybe having the kernel have to switch between the Intel chip and the Broadcom chip results in that 8% bandwidth penalty?).

I ran all of these sets of tests twice, and they were extremely close in each case.

Now I'm interested to see if I'd be able to pump any more bits through this thing with a 10GbE adapter, or if 2.5 GbE over any individual interface is about as high as it'll go before we hit limits.

Hey Jeff!

Very interesting and inspiring. Actually, this Ethernet Server Adapter allows for HW timestamping and therefore more precise values when looking at latency performance, will maybe be another use-case where this setup could be interesting. But my question is, if it would be possible for the raspberry to also handle at the same time traffic coming from the USB3.0 port?

Jordi

@geerlingguy
Copy link
Owner Author

@jordibiosca - Unfortunately, when you go through USB 3.0, the bus overhead slows things down and you get a lot less bandwidth/throughput.

@maruohon
Copy link

I'm currently debating changing my current home server setup, which is just one Intel i7-7700K based PC, to a combination of a "main server" of a Pi 4 Compute 8 GB RAM, with the i7-7700K being a secondary server only used for some heavier loads (game servers), which would be in sleep most of the time and only woken up when it's actually needed.

Towards this goal I would need the Pi to have 4 Ethernet ports (1 to connect to the outside internet, 2 to share the connection to the existing other PCs, and the fourth for the i7-7700K which would join the "inside network"), which is why this Intel board is interesting to me.

But for this change to actually make any sense for me, what I'm mostly interested in is the power consumption of

    1. the Pi 4 Compute including the i/o board
    1. how much does the 4-port Intel Ethernet board take on top of that?

And how much does that consumption change between idle and full load, bot for the Pi's CPU and also for the Intel Ethernet card when under heavy network load. I don't really remember seeing power consumption being featured in your Youtube videos for the Pi based systems, but that is one thing that would be interesting at least for me.

If you were to do some power consumption testing, then also be aware of some (cheap?) power meters not really taking into account the power factor, which might throw off the results at least if the measured power supply does not do much or any power factor correction. (I've gotten some super funky results from some PC systems with certain power meters like the PM-300).

@geerlingguy
Copy link
Owner Author

@maruohon - I haven't done a power meter with this card installed, but typically for other devices (I tested with 2.5G and dual 2.5G), the Pi uses a maximum of 15-20W (10-15W at idle, or 5-10W without a PCIe card). Only hard drives and more intense storage-related cards seem to really push that up higher.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests