Vraag


  • dutch-guy
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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)

Beste antwoord (via dutch-guy op 28-10-2022 09:23)

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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.

Alle reacties


  • SpecialJ
  • Registratie: Maart 2010
  • Laatst online: 08:17
Welke encryptie heb je op je IPSEC tunnel? de encryptie kan de snelheid beïnvloeden namelijk!

  • dutch-guy
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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
  • Registratie: Juni 2008
  • Laatst online: 04-02 23:14

Midas.e

Is handig met dinges

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.

Hacktheplanet.nl


  • dutch-guy
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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]


Acties:
  • Beste antwoord
  • 0Henk 'm!
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • dutch-guy
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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
  • Registratie: Februari 2008
  • Laatst online: 12:33
@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
  • Registratie: Juli 2006
  • Laatst online: 03-02 11:35

M2M

medicijnman

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
  • Registratie: Mei 2010
  • Laatst online: 14:24
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
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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:
1
2
3
4
5
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
  • Registratie: Februari 2008
  • Laatst online: 12:33
@vj_slof oops, niet goed gelezen (ik) !

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


  • com2,1ghz
  • Registratie: Oktober 2004
  • Nu online
Kan je een iperf runnen op beide apparaten?
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • dutch-guy
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • dutch-guy
  • Registratie: November 2012
  • Laatst online: 29-10-2022
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)
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • M2M
  • Registratie: Juli 2006
  • Laatst online: 03-02 11:35

M2M

medicijnman

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
  • Registratie: November 2012
  • Laatst online: 29-10-2022
@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
  • Registratie: Mei 2002
  • Laatst online: 17:06
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]

CISSP! Drop your encryption keys!

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]

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • M2M
  • Registratie: Juli 2006
  • Laatst online: 03-02 11:35

M2M

medicijnman

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
  • Registratie: April 2009
  • Niet online
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
  • Registratie: Mei 2002
  • Laatst online: 17:06
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 8)7

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]

CISSP! Drop your encryption keys!


  • gastje01
  • Registratie: Oktober 2005
  • Laatst online: 15:52
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
  • Registratie: Mei 2002
  • Laatst online: 17:04
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.

Roomba E5 te koop

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee