Onverwacht lage snelheid site-to-site media stream

[dutch-guy]

Hoi tweakers,

Mijn vraag
Ik heb twee locaties, op de ene staat mijn nas en op de ander woon ik zelf.
Recent heb ik de locatie waar mijn nas staat naar glasvezel geupgrade omdat ik thuis graag de media wil kunnen streamen vanaf de nas. Mijn huis locatie heeft enkel ziggo.

nas locatie: 400 up / 400 down
thuis locatie: 35 up / 350 down

ipc gebruik ik plex voor het streamen van media maar toen ik glas had aangesloten dacht ik toch eens kijken wat de snelheden zijn. Dat viel mij eigenlijk best tegen. Vanaf de nas komt de up snelheid eigenlijk niet hoger dan 7,5 mb (via smb file kopieren tussen de sites)

Het streamen via plex gaat dus best ok, als ik dezelfde file probeer te streamen (tussen de twee sites) via smb met vlc bijvoorbeeld loopt de playback ook niet soepel.

De twee sites zijn via een site-to-site vpn aan elkaar verbonden (Manual IPsec)

Ik verwacht dat er best wat overhead zit in bestanden via smb kopieren, maar zoveel klinkt meer alsof er ergens anders een issue zit. De performance van een site-to-site vpn heb ik nog geen ervaring mee omdat ik nooit zoveel bandbreedte had aan de andere kant, dus misschien dat daar het probleem zit ?

Relevante software en hardware die ik gebruik
Nas: synologie DS1815+

Netwerk nas locatie:
nas
US-24-G1
USG-3P
glas

Netwerk aan de thuis locatie:
ziggo
UDMPRO
US-24-G1
computer/laptop/tv

Voor het managen van het netwerk gebruik ik de unifi software, via een unifi cloudkey gen 2 aan de nas kant en de udmpro aan de thuis kant.

Wat ik al gevonden of geprobeerd heb
Op de nas een bond geconfigureerd op twee vd vier netwerk poorten, ik had gevonden dat dit kon helpen meer bandbreedte/connecties te alloceren. maar ik vond dit al een vreemd oplossing omdat de brandbreedte bij lange na niet wordt gehaald. switch aggregation is geconfigureerd op de switch.

Bij de nas locatie staan nog andere computers, als ik daar een file over het netwerk heen kopieer (via smb) krijg ik gewoon 100mb (gigabit)

[SpecialJ]

Welke encryptie heb je op je IPSEC tunnel? de encryptie kan de snelheid beïnvloeden namelijk!

[dutch-guy]

SpecialJ schreef op dinsdag 25 oktober 2022 @ 09:58:
Welke encryptie heb je op je IPSEC tunnel? de encryptie kan de snelheid beïnvloeden namelijk!

AES-256

[Midas.e]

Je kan tijdens een transfer eens inloggen op de USG-3P via ssh en met top kijken wat de cpu doet. Sterker nog, ik zou het op beide locaties doen tijdens een transfer.
Probeer anders een keer site to site te testen via iperf en daarmee smb uit te sluiten.

Check ook even of offloading op beide locaties aanstaat.

[dutch-guy]

Midas.e schreef op dinsdag 25 oktober 2022 @ 10:45:
Je kan tijdens een transfer eens inloggen op de USG-3P via ssh en met top kijken wat de cpu doet. Sterker nog, ik zou het op beide locaties doen tijdens een transfer.
Probeer anders een keer site to site te testen via iperf en daarmee smb uit te sluiten.

Check ook even of offloading op beide locaties aanstaat.

Nas als server en thuis als client
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 40.9 MBytes 34.3 Mbits/sec sender
[ 5] 0.00-10.00 sec 40.8 MBytes 34.2 Mbits/sec receiver

op de usg3p staat hardware offloading aan. op de udmpro kan ik die optie niet vinden, maar ik geloof dat die default aan staat.


Edit:
op usg3p en udmpro top gedraaid via ssh, maar dat ziet er helemaal niet spannend uit. de usg3p blijft onder de 5% cpu en de udmpro zit onder de 20%

[ Voor 9% gewijzigd door dutch-guy op 25-10-2022 11:37 ]

[Ben(V)]

Bij smb wordt de snelheid bepaalt door het langzaamste pad.
Met andere woorden die 35 MBps upload snelheid van je thuis locatie is de bottleneck.

Ook al worden de datablokken met 400 MBps verstuurt, de protocol data blokken worden teruggestuurd met 35MBps dus het volgende datablok moet daar op wachten.

[dutch-guy]

Ben(V) schreef op dinsdag 25 oktober 2022 @ 11:44:
Bij smb wordt de snelheid bepaalt door het langzaamste pad.
Met andere woorden die 35 MBps upload snelheid van je thuis locatie is de bottleneck.

Ook al worden de datablokken met 400 MBps verstuurt, de protocol data blokken worden teruggestuurd met 35MBps dus het volgende datablok moet daar op wachten.

Crap, is er een andere manier om toch van de volle netwerksnelheid gebruik te maken ?

[W1ck1e]

@Ben(V) @dutch-guy Maar de protocol data is veel minder in volume dan de data blokken. Daarom is een assymmetrische verbinding vaak objectief voldoende. Dus neen.

[ Voor 3% gewijzigd door W1ck1e op 25-10-2022 11:48 ]

[M2M]

Inderdaad, de upload van de ziggo verbinding zou geen issue moeten zijn. Daar gaat veel minder verkeer overheen bij een downstream van een "server".

Is de kale internet snelheid wel voldoende? speedtest.net ofzo, voor upload en downloadtest van beide machines?

*edit: Wellicht een goed idee om MB/s en Mb/s te gebruiken. Ik twijfel hier en daar wat tussen megabit en megabyte. Dat scheelt een factor 8

[ Voor 21% gewijzigd door M2M op 25-10-2022 11:51 ]

[vj_slof]

dutch-guy schreef op dinsdag 25 oktober 2022 @ 11:46:
[...]


Crap, is er een andere manier om toch van de volle netwerksnelheid gebruik te maken ?

Ja, via iSCSI maar dat is niet heel erg stabiel over een netwerk. Het verbreken van de netwerkverbinding kun je dan zien als het abrupt ontkoppelen van een harde schijf. Niet altijd gezond voor je filesystem.

[dutch-guy]

dutch-guy schreef op dinsdag 25 oktober 2022 @ 11:25:
[...]


Nas als server en thuis als client
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 40.9 MBytes 34.3 Mbits/sec sender
[ 5] 0.00-10.00 sec 40.8 MBytes 34.2 Mbits/sec receiver

op de usg3p staat hardware offloading aan. op de udmpro kan ik die optie niet vinden, maar ik geloof dat die default aan staat.


Edit:
op usg3p en udmpro top gedraaid via ssh, maar dat ziet er helemaal niet spannend uit. de usg3p blijft onder de 5% cpu en de udmpro zit onder de 20%

Nog een toevoeging hierop:

Hmm maar er is wel iets anders dat interesant is. als ik die ssh sessie open laat staan en ik ga vervolgens een file kopieren via smb dan krijgt de usg3p flink op zijn donder:

code:

PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                 
   15 root      20   0     0    0    0 R  43.8  0.0  40:40.25 ksoftirqd/1                                                             
    3 root      20   0     0    0    0 R  43.2  0.0  53:47.11 ksoftirqd/0                                                             
   13 root      20   0     0    0    0 R  19.6  0.0  29:34.85 rcuc/1                                                                  
   10 root      20   0     0    0    0 R  18.7  0.0  36:50.75 rcuc/0

Als ik probeer te streamen zie ik deze hoge cpu usage helemaal niet, maar op een moment begint de stream te stotteren en dan zie ik nog steeds geen verschil in gebruik.

[W1ck1e]

@vj_slof oops, niet goed gelezen (ik) !

[ Voor 63% gewijzigd door W1ck1e op 25-10-2022 11:53 ]

[com2,1ghz]

Kan je een iperf runnen op beide apparaten?

[Ben(V)]

Geloof niet dat jullie het begrijpen.
SMB is niet asynchrone.
Het is niet zo dat er eerst een paar Kbyte data verstuurt wordt en dan een acknowledge.
Het gaat gewoon per smb pakketje

Elk smb pakketje moet beantwoordt worden en dus is de throughput gewoon die van de laagste snelheid.

[dutch-guy]

M2M schreef op dinsdag 25 oktober 2022 @ 11:50:
Inderdaad, de upload van de ziggo verbinding zou geen issue moeten zijn. Daar gaat veel minder verkeer overheen bij een downstream van een "server".

Is de kale internet snelheid wel voldoende? speedtest.net ofzo, voor upload en downloadtest van beide machines?

*edit: Wellicht een goed idee om MB/s en Mb/s te gebruiken. Ik twijfel hier en daar wat tussen megabit en megabyte. Dat scheelt een factor 8

Speedtest aan de nas kant:
DOWNLOAD Mbps
391.98
UPLOAD Mbps
365.32

Speedtest aan de thuis kant:
DOWNLOAD Mbps
356.06
UPLOAD Mbps
35.73

[Ben(V)]

Je kunt ftp proberen maar dan wel aynchrone gebruiken.
WebDav zou ook kunnen werken.

Maar met smb ben je echt beperkt tot de upload snelheid.

[dutch-guy]

Ben(V) schreef op dinsdag 25 oktober 2022 @ 12:02:
Je kunt ftp proberen maar dan wel aynchrone gebruiken.
WebDav zou ook kunnen werken.

Maar met smb ben je echt beperkt tot de upload snelheid.

Is dat dan ook de reden waarom die stream op een moment gaat stotteren ? (en dan bedoel ik de stream die ik start via bv vlc)

[Ben(V)]

35Mbps zou echt meer dan voldoende voor elke stream moeten zijn.

Maar als je een smb verbinding gebruikt zou vlc er wel eens vanuit kunnen gaan dat je lan snelheden haalt en niet of nauwelijks buffert en dan merk je dus elke hikup, tenslotte ga je over het internet.

[M2M]

Ben(V) schreef op dinsdag 25 oktober 2022 @ 12:02:
Je kunt ftp proberen maar dan wel aynchrone gebruiken.
WebDav zou ook kunnen werken.

Maar met smb ben je echt beperkt tot de upload snelheid.

R: 125MB/s W: 14.6KB/s

[dutch-guy]

@Ben(V) Ik heb de afgelopen dagen wat getest met ftp via de vpn tunnel en ftp via public. maar via beiden krijg ik rond de 7 MB snelheden. Opzich klinkt jouw uitleg logisch, maar ik snap niet hoe ik dan bijvoorbeeld wel 44 MB down krijg als ik een update via steam binnen haal, hoe is dat anders dan de scenarios die ik heb geprobeerd ?

[laurens0619]

Het asynchrone stuk van @Ben(V) klinkt voor mij onlogisch, nooit van gehoord ook.Ja er moeten pakketjes terug maar daarvoor is een lagere snelheid nodig.

@dutch-guy er zijn een aantal oorzaken van limiieten waar je tegenaanloop:
- Limiet van VPN
- Limiet van router
- Limiet van protocol
- Limiet van NAS
- Limiet van peering/transit

Nu heb je de limiet van VPN al weggestreept door het via port mapping te testen.
Ook protocol heb je weggestreept door te testen met FTP.
Limiet van NAS ook toch? Door interne speedtest die wel harder gaat

Dan blijft de limiet van de router en de limiet van "peering/transit" over.

Peering/Transit
Maximale upload/download snelheid is niet alleen wat de provider je geeft op het modem thuis naar de ISP, maar ook vanaf de ISP naar bepaalde verbindingen. Vaak investeren ze in snelle verbindingen naar diensten als speedtest maar kunnen de verbindingen naar een andere provider wat mager zijn.

Router
Soms heb je zaken als DPI die zwars zitten maar dat zou je dan ook met de download moeten zien.

Wat je kunt proberen is bv via een http server een 1GB.bin file open zetten en die vanaf verschillende locaties testen en kijken welke snelheid je haalt.

[ Voor 6% gewijzigd door laurens0619 op 28-10-2022 09:51 ]

[Ben(V)]

Ftp is standaard ook synchroon dus ook daar bepaalt de upload snelheid het maximum.
Maar ftp kun je ook asynchrone gebruiken, maar dan moet je wel ftp client en servers hebben die dat ondersteunen en je moet dat dan ook instellen.

Een stream is geen protocol, dat wordt gewoon verstuurd en er gaat geen data terug. (Vandaar ook de naam stream)
Als er wat pakketjes omvallen hebt simpel wat blokjes in je video beeld, dus dan is die lage upload geen probleem.
Net als bij een speedtest.

@laurens0619
De retour data van een smb verbinding is behoorlijk groot en dus bepaalt die lage upload snelheid wel degelijk het max.
Voor elk smb data pakketje dat verstuurt wordt wacht het protocol met het versturen van het volgende pakketje tot hij een acknowledge van de andere kant gekregen heeft voordat hij het volgende pakketje verstuurt.
Die acknowledge is wel minder data maar komt met de upload snelheid terug en dat houd de boel op.

Smb is een lan protocol en helemaal niet ontworpen voor internet verbindingen en al helemaal niet voor ongelijke snelheidlimieten.

Peer/Transmit
Dat zou het geval zijn als de ISP te weinig capaciteit naar het internet heeft ingekocht.
Kun je simpel testen door een speedtest van je provider (die blijft op het provider deel) te vergelijk met een publieke speedtest.

Router kan wel problemen geven met bepaalde security en/of firewall instellingen maar daar zou een speedtest ook last van hebben.

[ Voor 24% gewijzigd door Ben(V) op 28-10-2022 13:00 ]

[M2M]

Hey @Ben(V) waar haal je die synchrone info vandaan? Zoals de screenshot aangeeft gaat er maar 14kB/s terug als er een volledige gigabit/s naar beneden wordt getrokken...

[synoniem]

SMB is niet echt bedoeld voor internetverbindingen met alle mogelijk haperingen onderweg. IPsec is erg betrouwbaar maar ook geen snelheidsmonster. Voor een snellere verbinding zou je naar Wireguard kunnen kijken. En dan inderdaad media streamen met een protocol wat daar voor bedoeld is dus Plex, Icecast, MPD en dergelijke.

[laurens0619]

Smb is voor Gevoelig voor latency al dan niet gerelateerd aan retransmits. Upload opmerking van ben weet ik niet of het serieus of troll is

Echter ftp gaat ook traag bij TS dus daar is iets anders aan de hand. Ik gok toch op de verbinding van provider naar provider die tekort schiet maar meten is weten

[ Voor 37% gewijzigd door laurens0619 op 28-10-2022 21:05 ]

[gastje01]

Trek je niet gewoon de CPU van je USG helemaal vol? Ik zie de cpu bij mijn Site2site met een lagere snelheid ook pieken.

[sig69]

Als het alleen om video streamen gaat zou plex juist perfect moeten werken. Draait hier al jaren, zo goed als 0 problemen mee. Tenzij er getranscode moet worden, dat gaat een nas vaak niet redden.