Acties:
  • 0 Henk 'm!

  • HollowGamer
  • Registratie: Februari 2009
  • Niet online
Ik ben niet goed met hardware, vooral op het gebied van draadloze-netwerken, maar zijn dit goede snelheden:
code:
1
$ rsync -av --progress --delete /path/to/source/ -e ssh user@host:/path/to/destination

Gemiddeld kom ik tussen de 14-17MB/s uit, dit op een 802.11ax netwerk.
Soms zakt hij weer helemaal in, na 3-4MB/s, maar het herstelt zich vrij snel.
Gemiddeld duurt het ~5min. per bestand (afhankelijk van de grootte)

Mijn hardware:
ASUS RT-AX58U met de nieuwste Merlin
Intel Corporation Wi-Fi 6 AX200 (Linux - Fedora) - Tx/Rx rates liggen gemiddeld op 1700Mbps

Ik backup van mijn desktop, naar mijn rPi4 die draait op ZFS, die weer verbonden is met USB 3.1C closure.

Is dit normaal? Kan het sneller?
Ik heb geprobeerd met en zonder compressie, maar dat maakte niet veel verschil.

Thanks!

Acties:
  • +1 Henk 'm!

  • Aragnut
  • Registratie: Oktober 2009
  • Laatst online: 22:51
Wat doet de performance op de rPI4 tijdens de overdracht? Je doet alles via encryptie/decryptie met ssh, en mogelijk dat ZFS ook nog een steentje bij draagt (in cpu en/of memory usage).

Als je wat beter de snelheid wil meten dan moet je naar /dev/null schrijven (scheelt je je disk subsystem als vertraging). Ook test met ftp in plaats van ssh/scp sluit andere bottlenecks uit.

Acties:
  • +1 Henk 'm!

  • Minitrooper
  • Registratie: December 2013
  • Laatst online: 11-06 14:03
Als ik het goed zie: dit is een rsync over ssh. Een rPi4 is ook geen "volwaardige" server, ZFS geeft ook overhead.

Toon eens een "top" van jouw rPi4.

Spuit11

-Edit: back in the days gelijkaardige bottlenecks gezien. Wat je kan doen:
- hang USB enclosure aan jouw pc en doe de rsync eens "lokaal". Kijk hoe snel dit gaat. Doe ook eens met een "cp".
- doe het dan eens opnieuw zonder ZFS op de rPi4
- vergelijk beide waarden met jouw initiële resultaten.

[ Voor 48% gewijzigd door Minitrooper op 03-03-2023 16:38 ]


Acties:
  • 0 Henk 'm!

  • HollowGamer
  • Registratie: Februari 2009
  • Niet online
@Minitrooper
Afbeeldingslocatie: https://tweakers.net/i/GYJncXTGCbRO8lRC3wP05UgLvnI=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/e1gJpq51MnviVdhMHBWHLcTp.png?f=user_large

Hmm, zie ook dat z_wr_iss flink wat CPU cycles vraagt, denk dat dit ook komt doordat ik daar schrijf naar een geencrypte dataset.

[ Voor 25% gewijzigd door HollowGamer op 03-03-2023 16:39 ]


Acties:
  • +1 Henk 'm!

  • Minitrooper
  • Registratie: December 2013
  • Laatst online: 11-06 14:03
Ja da's duidelijk: de ssh daemon kan niet volgen en gooit een bottleneck.

Acties:
  • 0 Henk 'm!

  • HollowGamer
  • Registratie: Februari 2009
  • Niet online
Minitrooper schreef op vrijdag 3 maart 2023 @ 16:39:
Ja da's duidelijk: de ssh daemon kan niet volgen en gooit een bottleneck.
Denk ook ZFS, die ligt gemiddeld ook op 70% CPU cycles zo te zien.

Acties:
  • 0 Henk 'm!

  • HollowGamer
  • Registratie: Februari 2009
  • Niet online
Aragnut schreef op vrijdag 3 maart 2023 @ 16:35:
Wat doet de performance op de rPI4 tijdens de overdracht? Je doet alles via encryptie/decryptie met ssh, en mogelijk dat ZFS ook nog een steentje bij draagt (in cpu en/of memory usage).

Als je wat beter de snelheid wil meten dan moet je naar /dev/null schrijven (scheelt je je disk subsystem als vertraging). Ook test met ftp in plaats van ssh/scp sluit andere bottlenecks uit.
Een ftp server heb ik al heel lang niet meer gedraaid, maar kan het eens checken.

Zal eens proberen te schrijven naar /dev/null, kan je dat gewoon als destination meegeven aan het rsync commando?

Acties:
  • 0 Henk 'm!

  • HollowGamer
  • Registratie: Februari 2009
  • Niet online
Minitrooper schreef op vrijdag 3 maart 2023 @ 16:36:
Als ik het goed zie: dit is een rsync over ssh. Een rPi4 is ook geen "volwaardige" server, ZFS geeft ook overhead.

Toon eens een "top" van jouw rPi4.

Spuit11

-Edit: back in the days gelijkaardige bottlenecks gezien. Wat je kan doen:
- hang USB enclosure aan jouw pc en doe de rsync eens "lokaal". Kijk hoe snel dit gaat. Doe ook eens met een "cp".
- doe het dan eens opnieuw zonder ZFS op de rPi4
- vergelijk beide waarden met jouw initiële resultaten.
Die tests wordt wel moeilijk.. daarom moet ik het over mijn LAN doen.

Ik heb Fedora Silverblue en daar draait geen ZFS op, dat is wel jammer. :/

Acties:
  • +1 Henk 'm!

  • Minitrooper
  • Registratie: December 2013
  • Laatst online: 11-06 14:03
Tip: als dit is voor een backup, dan doe ik graag rsync met een checksum voor md5 hashing over en't weer (moest er een bit achter de kast vallen bij overzetten). Dit léést dus ook een berg in aan de destination kant voor hij iets delete (archiveert) aan de source kant.

Acties:
  • +1 Henk 'm!

  • Minitrooper
  • Registratie: December 2013
  • Laatst online: 11-06 14:03
Laatste tip, gezien beide OS'en toch ook linux zijn is dit een makkie: kijk even naar een iperf setup (rPi4 als server met jouw pc als client én omgekeerd): https://www.reddit.com/r/..._your_network_with_iperf/

Acties:
  • 0 Henk 'm!

  • Minitrooper
  • Registratie: December 2013
  • Laatst online: 11-06 14:03
HollowGamer schreef op vrijdag 3 maart 2023 @ 16:42:
[...]

Die tests wordt wel moeilijk.. daarom moet ik het over mijn LAN doen.

Ik heb Fedora Silverblue en daar draait geen ZFS op, dat is wel jammer. :/
Dat laatste klopt, maar dan weet je tenminste dat die USB disk niet de bottleneck is (maar gezien sshd en zfs al bovenaan top dartelen, vermoed ik niet dat de disk de oorzaak is)

Acties:
  • +1 Henk 'm!

  • Aragnut
  • Registratie: Oktober 2009
  • Laatst online: 22:51
ook nog disk encryption? Dat zal ook load leggen ja. Heb in het verleden dat eens gedaan met een atom CPU uit 2010 : 1 (van de 2) cores 100% belast en niet vooruit te branden (rPi4 zal wel betere cpu hebben overigens).

Voor tests maak ik vaak een bestand met dd, die gooi je dan 1-op-1 naar /dev/null inderdaad. Alternatief is met netcat (google staat er vol mee).
Pagina: 1