If you need the dual 10gbit it's an absolute steal. I hear varying things about the nvme and mini pcie slots but neither need nor use them.
Not sure what thermal issues you allude to, TBH.
1 Like
I think this is the only choice if you need 10Gbit capabilities at this price point. As a reference platform for MT7988a, it pretty much allows you to utilize the full potential of the SoC.
I use the official metal case with a small fan on the heatsink. The CPU temperature is around 52C with full hardware offload. That's in an airconditioned room and I also installed RM500Q-GL (a 5G modem, internal sensors show 50~55C) if it matters.
The only caution, I would say, is don't insert the SIM trays in the wrong orientation. There's no guard against that and it's tricky not to damage the slots if you want to pull them out afterwards.
So far, I'm quite impressed with it and may add an SSD later.
4 Likes
Even if you install them strictly (e.g. when using the official enclosure) in the correct direction, the third (rightmost) slot seems to have some components inside that do not have the right dimensions. Thus I need to be very careful on two BPI-R4 copies when pulling out the trays. (To be updated once I opened my third)
Second this. I pulled the contacts out of my rightmost slot when swapping to the official case. Good thing I probably won't need them!
1 Like
+1 broke the slot contacts by inserting the tray upside down
1 Like
me too, lucky as only in SIM slot not used by my 5G modem 
for me, it should be somehow protected but it doesn't
1 Like
Could all please test their slots? Question is if this is a design failure on the trays or the boards.
In my first board copy it damaged the rightmost SIM slot because of using the tray upside down just as @DroZDi and @ListerWRT reported. The second copy showed the same behaviour even though I inserted the tray in the correct orientation but I worked around that by really really carefully pulling it out. I do not know whether this would work better (because the SIM puts down the contacts) or worse (because the tray cannot be pulled out gently any more) when a SIM is actually inserted, I will try and report later.
Regarding the power consumption:
First users have received their WIFI7-cards and one did a throughput-test while measuring the consumption (thanks to @TheServer201):
Those 14W maximum consist of:
- idle power + DAC 4W
- SFP+ copper module +3W
- WIFI-7-module idle +3W
- Transmission maximum (3,8Gbit/s) +4W
This is absolutely impressive compared to the AsiaRF WIFI6/6E cards:
- WIFI-6-module idle +4W
- Transmission maximum +5W
And this is only for two frequencies (2+5 or 2+6GHz), for covering all three frequencies, one need to add a second card, which doubles the consumption!
3 Likes
I broke 2 slots by inserting the SIM trays upside down but was able to get the slots replaced by the seller. If sending the board back is not an option due to shipping costs, going to your local electronics/cellphone shop may help.
The seller told me that if it happens again, just carefully lift the pins/contacts using a toothpick to remove the tray. It's definitely a design oversight of the SIM slots as it's so easy to make that mistake.
2 Likes
Yeah, but there is a video of how to assemble the case and also everyone clearly can see how to insert those trays...
everyone clearly can see
Excuse me, but please don't speak for everyone.
I'm pretty sure 5 of us making the same mistake is no coincidence and we are not alone. If you don't see how that's a design issue, then I refer you to https://en.wikipedia.org/wiki/Poka-yoke
3 Likes
To avoid further breaking the community guidelines, I invite you to continue this discussion in private with me if you so desire.
@eladwf @daniel
guys one observation. when hw offload is enable. I get datagrams received out of order when doing a udp receive. this is from a iperf3 host on another subnet being routed on the bpi-r4.
When only sw offload is enable or all offload is disabled. no out-of order packet.
22 datagrams received out-of-order
example:
iperf3 -c xx.xx.xx.xx -u -b 500M -R
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.01 sec 59.9 MBytes 500 Mbits/sec 0.010 ms 0/43393 (0%)
[ 5] 1.01-2.01 sec 59.6 MBytes 500 Mbits/sec 0.029 ms 0/43133 (0%)
[ 5] 2.01-3.01 sec 59.7 MBytes 500 Mbits/sec 0.031 ms 0/43207 (0%)
[ 5] 3.01-4.01 sec 59.6 MBytes 500 Mbits/sec 0.028 ms 0/43171 (0%)
[ 5] 4.01-5.00 sec 59.5 MBytes 500 Mbits/sec 0.010 ms 0/43099 (0%)
[ 5] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec 0.005 ms 0/43188 (0%)
[ 5] 6.00-7.01 sec 59.6 MBytes 499 Mbits/sec 0.032 ms 0/43148 (0%)
[ 5] 7.01-8.01 sec 59.6 MBytes 500 Mbits/sec 0.030 ms 0/43167 (0%)
[ 5] 8.01-9.01 sec 59.7 MBytes 500 Mbits/sec 0.042 ms 0/43200 (0%)
[ 5] 9.01-10.01 sec 59.6 MBytes 500 Mbits/sec 0.009 ms 0/43177 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 597 MBytes 500 Mbits/sec 0.000 ms 0/432030 (0%) sender
[SUM] 0.0-10.0 sec 11 datagrams received out-of-order
[ 5] 0.00-10.01 sec 596 MBytes 500 Mbits/sec 0.009 ms 0/431883 (0%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.01 sec 59.9 MBytes 500 Mbits/sec 0.023 ms 0/43371 (0%)
[ 5] 1.01-2.01 sec 59.5 MBytes 499 Mbits/sec 0.025 ms 0/43113 (0%)
[ 5] 2.01-3.01 sec 59.7 MBytes 501 Mbits/sec 0.013 ms 0/43216 (0%)
[ 5] 3.01-4.01 sec 59.5 MBytes 499 Mbits/sec 0.024 ms 0/43072 (0%)
[ 5] 4.01-5.00 sec 59.7 MBytes 501 Mbits/sec 0.031 ms 0/43207 (0%)
[ 5] 5.00-6.01 sec 59.6 MBytes 500 Mbits/sec 0.024 ms 0/43186 (0%)
[ 5] 6.01-7.01 sec 59.6 MBytes 500 Mbits/sec 0.036 ms 0/43173 (0%)
[ 5] 7.01-8.01 sec 59.6 MBytes 500 Mbits/sec 0.032 ms 0/43165 (0%)
[ 5] 8.01-9.01 sec 59.6 MBytes 500 Mbits/sec 0.008 ms 0/43151 (0%)
[ 5] 9.01-10.01 sec 59.4 MBytes 498 Mbits/sec 0.006 ms 0/42991 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 597 MBytes 500 Mbits/sec 0.000 ms 0/431989 (0%) sender
[SUM] 0.0-10.0 sec 7 datagrams received out-of-order
[ 5] 0.00-10.01 sec 596 MBytes 500 Mbits/sec 0.006 ms 0/431645 (0%) receiver
it varies between 1-22. most of the time it's 2
2 datagrams received out-of-order
not high and i do not see see any negative impact.
but i am curious why it only happens when hw offload is enabled.
1 Like
That probably happens because the first packets received by the R4 before the hardware offloading rule is added need to traverse all Linux kernel network stack. The packets received after the offloading rule was added bypass all that in hardware and may hence be sent out before the first packets made it's way through the kernel...
2 Likes
make sense. sometime when i run the same test immediately after one. there are no out of order packets as the rules as still in effect.
any way to correct or mitigate?
Greetings everyone.
So as i have previously mentioned i have installed on my banana pi an nvme drive
The banana pi is running latest snapshot i have a 10gbit pppoe xgs-pon connection
i am running a container in docker with qbittorrent for torrenting
whatever i try to download the software is capped at approximately 1.3 gbit /s
(destination of the download is the mount point of the nvme drive)
when the download goes , the cpu load ramps up to 60 - 70%
no matter if i add other torrents the cpu stays fixed at that usage and the total sum of the download speed doesnt exceed 1.3 gbit /s
I tried running rtorrent not from docker. Similar result.
Benchmarked the nvme drive and that is not the bottleneck ( write speed of almos 900 MB/s - roughly 7.2 gbit /s , normal since it is pcie 3 1x lane)
If i try to download THE SAME TORRENT on a machine in the network behind the nat i can happily achieve 3-4 gbit /s without any cpu usage on the router processor.
can this be caused by some firewall rules that are not using the offloading ?
i have never run docker container on openwrt before so i am only guessing.
the container is running a bridged network on the openwrt host? if so do you have bridger running?
i dont have bridger running , the container yes is running in bridged network , but also if i run ANY executable from within openwrt i cant get past 1.3 gbit /s even high cpu usage.
attaching a screenshot of my network devices
So in order to access the internet i must have a vlan tagged on eth2 ( wan 10gbit copper fsp) with pppoe
eth1 (the other 10 gbit sfp cage) is added to br-lan along with the 1gbit ports lan1 lan2 lan3
on a lanX (dont remember which one) port there is also a 1gbit cable goin to an wifi AP
Docker is also in bridged as you see BUT i dont know tho what interface is bridged.
no matter what , whatever app i run from within openwrt or the banana pi , there is cpu usage and when reaching 1.3gbit sec the cpu usage is very high. If i use any client connected on br-lan (either the one connected over by sfp+ @ 10gbit or any other connected by wifi ap) whatever is the netusage cpu on the banana pi stays to 0% , MAX 1% because btop designs the graph
For example i can happily run a speedtest @ 8.1gbit down 2.1 gbit up (maxing out my provider link) OR i can download the same torrent that i would download on the banana pi either by docker or by the openwrt os without using containers. openwrt or container will use a lot of cpu, machines on the lan no . (infact the machine on the lan can download a torrent at 2-5gbit happily , the same torrent will have capped 1.3 gbit if app runs on cpu of the banana pi)
i did read extensively the other posts about bridger and ppes but , theoretically i should use bridger , but i am not using it and on the lan bridge everything is ok
MAYBE if a soft is running bound to an interface INSIDE the openwrt , that is part of the bridge , all packets are passing on the cpu , while if the app generating traffic is OUTSIDE the router , but still on the bridge , then the packets are offloaded to the npu ?
offload = hw flow offload
only forwarding flows are offloaded. bridger is suppose to detect forwarding flows in bridged devices. give it a try
bridger is not needed on the switch ports as the switch driver detects the flows and offloads them.
packets destined or originating from the r4 localhost are not offloaded as there is no forwarding flows.
there was a post by daniel some time back on bridger and offfload in this topice search for it.
2 Likes
so basically bridger should allow to offload also the "internal packages" am i correct ?