SBC-baserad LAN-cache i hemmanät

Permalänk
Medlem

SBC-baserad LAN-cache i hemmanät

Har precis satt upp en Lan-cache www.lancache.net (med prefill) i vårt 2.5 Gbit hemmanätverk, men hastighetsökningen vid nedladdning i Steam blev inte riktigt så stor som jag hoppats på... Snarare "bara" en fördubblad överföringshastighet (typ 500-700 MBit/s) mot förhoppningen på 8-10 ggr ökning (ie 2.5 GBit/s).

Servern som skall serva 2-3 st andra datorer är en liten SBC, Orange Pi 5 plus, med NVMe-disk och dubbla 2.5-Gbit nätverk ihopkopplade med Link aggregation.

Nedladdning från internet fyller lätt vår internetlina på 250 Mbit, men överföring från Lan-cache till speldator med Steam över 2.5 GBit-nätet går inte alls så fort som man skulle önska. CPU-användning är låg, disken klarar också hastigheten om man kör nedladdning av ett cachat spel från prefill lokalt... MEN om man laddar hem "på riktigt" så verkar Steam efterfråga så många små slattar att lan-cache startar ett 50-tal nginx worker process på SBC'n vilket förmodligen gör att disken inte hinner leverera tillräckligt snabbt. Speldatorn har också NVMe-disk så den borde också klara snabbare överföring.

Finns det något sätt att förbättra hastigheten(?) Få Steam att hämta större chunks, eller att få lan-cache/Nginx att cacha pågående överföringar i RAM?

Permalänk
Medlem

I och med att du kör linux så cachar den så mycket den bara orkar som standard. Du kan trimma beteendet med dessa parametrar. Man kan säga att det är tre delar som balanserar i minnet, rena sidor, ändrade sidor och fil-data (VFS fil- och katalog-data i minnet). Om du har få filer och mycket data så kan du prioritera ned VFS. Om du har mycket ändrade sidor så kan du öka trycket så att de skrivs ner till disk snabbare, och därmed frigöra plats för nya inkommande sidor. Allt efter hur just din situation ser ut. (Finns hur mycket som helst skrivet om detta, men inga färdiga recept p.g.a. oändliga situationer.)

https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-...

/proc/sys/vm/swappiness /proc/sys/vm/vfs_cache_pressure /proc/sys/vm/dirty_ratio /proc/sys/vm/dirty_background_ratio

Permalänk
Medlem

Din skärmdump (från Pi:n) visar en överföringshastighet på runt 190 MiB/s, så ca 1,5 Gbit/s?

Jag hade nog gissat att PCIe-linorna skulle bli problematiska på en sådan processor. Men det verkar ändå rätt OK:

Enligt databladet har processorn PCIe 3.0, uppdelat i 1x4, 2x2 eller 4x1. Jag gissar att 2,5 Gbit-NICen behöver linor. Dessutom sitter det en E-key M.2 för WiFi. CPU:n listar ”2xGiga-ethernet” och USB3 så jag gissar att det förstnämnda inte används och det sistnämnda inte behöver använda PCIe-linor, trots att brädan har ett externt chip av något slag.

Men jag får inte ihop CPU-databladet med marknadsföringen av OrangePi 5 plus som säger att disken ska få fyra PCIe-linor själv. Jag skulle inte bli förvånad vare sig om jag missat något eller om en kinesisk tillverkare helt enkelt råljuger om specarna.

Hittar inget blockschema eller liknande, men om det inte sitter något muxaktigt på brädan så borde disken ha en lina? Vilket ändå skulle ge 1 GB/s, så rätt gott om marginal?

Permalänk
Medlem
Skrivet av KAD:

Men jag får inte ihop CPU-databladet med marknadsföringen av OrangePi 5 plus som säger att disken ska få fyra PCIe-linor själv. Jag skulle inte bli förvånad vare sig om jag missat något eller om en kinesisk tillverkare helt enkelt råljuger om specarna.

Ja, överallt där den säljs står det att den har 4st PCIe-3.0-lanes till NVMe-disken, och i schemat på Orange pi's webplats står det något motsägelsefullt att det är 2st PCIe-3.0-lanes till NVMe-disken... *klurigt*, MEN om man tittar närmare på schemat och studerar vad som faktiskt är framdraget, så ser man, om man förstår elscheman, att det verkligen är 4st Rx-par och 4st Tx-par framdragna... Dvs 4st PCIe-3.0-lanes!!! Benchmarks visar dock att man på sin höjd, i bästa fall, snarare når max hälften av förväntad diskprestanda... Dvs motsvarande 1-2 st PCIe-3.0-lanes. Enligt pibenchmarks.com verkar Samsungs NVMe-diskar vara snabbast, och övriga något långsammare... Jag har en Crucial P3 Plus och når inte över 2000 MByte/s.

Övriga gränssnitt då? Till nätverkskretsen med 2st 2.5 GBit (Realtek RTL8125BG) går 1st PCIe 2.0 lane...(!) Till NVMe-porten för Wifi går 1st PCIe 2.0. USB-portarna verkar integrerade i kretsen.

Jag tror dock grundproblemet till att OPI5+ inte orkar fylla nätverksanslutningen fullt ut, är att disk-IO blir överbelastat när Steam-klienten efterfrågar en massa utspridda småslattar av ett spel vid nedladdning...

Mina benchmarks...

hdparm

> sudo hdparm -t /dev/nvme0n1p3
Timing buffered disk reads: 3338 MB in 3.00 seconds = 1112.05 MB/sec
> sudo hdparm -T /dev/nvme0n1p3
Timing cached reads: 8480 MB in 2.00 seconds = 4244.16 MB/sec

Dold text

rpi-benchmark

Raspberry Pi Benchmark Test
Author: AikonCWD
Version: 3.0

Running InternetSpeed test...
Ping: 50.487 ms
Download: 225.64 Mbit/s
Upload: 144.60 Mbit/s

Running CPU test...
total time: 10.0002s
min: 0.15
avg: 0.15
max: 1.01

Running THREADS test...
total time: 10.0022s
min: 2.00
avg: 2.24
max: 16.87

Running MEMORY test...
3072.00 MiB transferred (7916.92 MiB/sec)
total time: 0.3858s
min: 0.00
avg: 0.00
max: 0.16

Running HDPARM test...
/dev/mmcblk0: No such file or directory

Running DD WRITE test...
536870912 bytes (537 MB, 512 MiB) copied, 0.787199 s, 682 MB/s

Running DD READ test...
536870912 bytes (537 MB, 512 MiB) copied, 0.281721 s, 1.9 GB/s

AikonCWD's rpi-benchmark completed!

Dold text
Permalänk
Medlem

Testa att köra en iperf3 mellan SBC:n och din dator för att se hur mycket trafik SBC datorns CPU orkar driva. Håll koll på CPU load via htop, eller glances om du föredrar en snyggare resursvisare.

Starta iperf3 server på SBC:n
iperf3 -s

Starta iperf3 klient på din dator och anslut mot SBC:n
iperf3 -c <IP till SBC> -P <antal strömmar, förslagsvis 1 eller 4 för att testa enkel och parallell överföring> (-R för att vända på överföringen så att klienten skickar och servern tar emot)

Meddela gärna vad du får för resultat då det vore intressant att se.

Visa signatur

Also found as @piteball@mastodon.rockhost.se
XCP-ng Node - Dell PowerEdge R720xd, Xeon E5-2690, 272GB, 3TB SSD, Nvidia Tesla P4
XCP-ng Node - Dell PowerEdge R720xd, Xeon E5-2697v2, 256GB, 2TB SSD
Xpenology Storage - SuperMicro X10SLL-F/SC825TQ, Xeon E3-1231 v3, 16GB, 90TB HDD
Xpenology Backup - Dell PowerEdge R230, Xeon E3-1220v6, 16GB, 12TB HDD

Permalänk
Medlem
Skrivet av Pitr-:

Testa att köra en iperf3 mellan SBC:n och din dator för att se hur mycket trafik SBC datorns CPU orkar driva. Håll koll på CPU load via htop, eller glances om du föredrar en snyggare resursvisare.

Kör ju egentligen 2x2.5 Gbit/s link aggregation på SBC'n, men jag har inget snabbare än 2.5 Gbit/s att benchmarka ifrån... Fick ca 2.3 Gbit/s, i vardera riktning och det är ju riktigt bra.

root@orangepi5plus:~# iperf3 -c 192.168.XXX.XXX
Connecting to host 192.168.XXX.XXX, port 5201
[ 5] local 192.168.XXX.XXX port 35496 connected to 192.168.XXX.XXX port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 281 MBytes 2.36 Gbits/sec 0 221 KBytes
[ 5] 1.00-2.00 sec 275 MBytes 2.31 Gbits/sec 0 221 KBytes
[ 5] 2.00-3.00 sec 280 MBytes 2.35 Gbits/sec 0 221 KBytes
[ 5] 3.00-4.00 sec 281 MBytes 2.35 Gbits/sec 0 221 KBytes
[ 5] 4.00-5.00 sec 280 MBytes 2.35 Gbits/sec 0 221 KBytes
[ 5] 5.00-6.00 sec 277 MBytes 2.33 Gbits/sec 0 221 KBytes
[ 5] 6.00-7.00 sec 280 MBytes 2.35 Gbits/sec 0 221 KBytes
[ 5] 7.00-8.00 sec 280 MBytes 2.35 Gbits/sec 0 221 KBytes
[ 5] 8.00-9.00 sec 278 MBytes 2.33 Gbits/sec 0 221 KBytes
[ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec 0 221 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.73 GBytes 2.34 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 2.73 GBytes 2.34 Gbits/sec receiver

iperf Done.
root@orangepi5plus:~# iperf3 -c 192.168.X.XXX -R
Connecting to host 192.168.XXX.XXX, port 5201
Reverse mode, remote host 192.168.XXX.XXX is sending
[ 5] local 192.168.XXX.XXX port 56672 connected to 192.168.XXX.XXX port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 273 MBytes 2.29 Gbits/sec
[ 5] 1.00-2.00 sec 272 MBytes 2.28 Gbits/sec
[ 5] 2.00-3.00 sec 275 MBytes 2.31 Gbits/sec
[ 5] 3.00-4.00 sec 276 MBytes 2.32 Gbits/sec
[ 5] 4.00-5.00 sec 273 MBytes 2.29 Gbits/sec
[ 5] 5.00-6.00 sec 277 MBytes 2.32 Gbits/sec
[ 5] 6.00-7.00 sec 273 MBytes 2.29 Gbits/sec
[ 5] 7.00-8.00 sec 273 MBytes 2.29 Gbits/sec
[ 5] 8.00-9.00 sec 274 MBytes 2.30 Gbits/sec
[ 5] 9.00-10.00 sec 274 MBytes 2.30 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.68 GBytes 2.30 Gbits/sec sender
[ 5] 0.00-10.00 sec 2.68 GBytes 2.30 Gbits/sec receiver

iperf Done.
root@orangepi5plus:~#

Dold text
Permalänk
Medlem

Gjorde förmodligen misstaget att mäta processorbelastningen inuti dockercontainern för lancache ovan... När jag mätte igen utanför ser man att processorn får jobba riktigt hårt när den servar en nedladdning från en Steamklient...

Permalänk
Medlem
Skrivet av pny:

Gjorde förmodligen misstaget att mäta processorbelastningen inuti dockercontainern för lancache ovan... När jag mätte igen utanför ser man att processorn får jobba riktigt hårt när den servar en nedladdning från en Steamklient...

<Uppladdad bildlänk>

Ja det ät väl ändå inte så otippat. ARM-kärnorna är bara stark under vissa förutsättningar, i alla andra lägen faller de kort. Men så drar de ju också bråkdelen av den energi som en Xeon CPU i en fullsize server drar. 😁

Visa signatur

Also found as @piteball@mastodon.rockhost.se
XCP-ng Node - Dell PowerEdge R720xd, Xeon E5-2690, 272GB, 3TB SSD, Nvidia Tesla P4
XCP-ng Node - Dell PowerEdge R720xd, Xeon E5-2697v2, 256GB, 2TB SSD
Xpenology Storage - SuperMicro X10SLL-F/SC825TQ, Xeon E3-1231 v3, 16GB, 90TB HDD
Xpenology Backup - Dell PowerEdge R230, Xeon E3-1220v6, 16GB, 12TB HDD