A new dual 10G router based on Filogic 880 (Banana Pi BPi-R4)

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 :confused:
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:

  1. idle power + DAC 4W
  2. SFP+ copper module +3W
  3. WIFI-7-module idle +3W
  4. 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.

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 ?