FS mounten over WAN

[zzattack]

Ik wil graag vanaf mijn ouders content uit mijn elders ondergebrachte media library kunnen afspelen met XBMC. Bandwidth zou geen probleem hoeven vormen, maar de praktijk blijkt anders. Misschien mis ik ergens een essentiele tweak of zoek ik geheel in de verkeerde richting.

Ik heb de volgende opties reeds geprobeerd:
- Samba over VPN. Beste optie, maar file copies gaan ~2MB/s. Te weinig voor bluray rips.
- SSHFS. Veel te traag.
- NFS (v3) over VPN. Trager dan Samba.
- FTP gemount. File copies halen volledige WAN speed (~6MB/s), maar afspelen in XBMC werkt nog altijd erg slecht. Seeken blijft dramatiscvh.
- WebDAV. Hoogstwaarschijnlijk doet Apache hier iets fout, want ik haal sowieso maar erg lage transfer speeds over HTTP (~2MB/s). Valt wellicht nog te tweaken.

Heeft iemand hier suggesties?

[DJSmiley]

Wat zijn de pingtijden tussen de 2 verbindingen?


Je kunt prima een 1Gbit kabel naar China leggen (bij wijze van) maar als je pingtijden hebt van 300ms ga je gewoon geen snelle response/doorvoer krijgen (immers, je ack pakketjes moeten ook weer terug).

Pas bij meerdere sessies krijg je hogere doorvoer.

Zelfde als je vlakbij zit maar met tig routers enz ertussen waardoor je pingtijden omhoog gaan.

[zzattack]

Zo'n 8-12ms. FTP transfers halen zodra het TCP Window gevestigd is ruim 6MB/s. Edit: over VPN dus. Dus TCP over UDP.

[Voor 19% gewijzigd door zzattack op 02-06-2011 11:34]

[leuk_he]

DJSmiley schreef op donderdag 02 juni 2011 @ 11:26:
Wat zijn de pingtijden tussen de 2 verbindingen?

het probleem is waarschijnlijk inderdaad dat de ping tijd hoog is. Als je vervolgens protocollen probeerd die voor LAN geoptimaliseerd zijn dan zul je of een setting moeten vinden die met grote buffers kan werken, of een protocol wat geoptimaliseerd is voor streamen.

Dan zou ik het toch zoeken in de http/unnp sfeer (al dan niet over vpn)

http://wiki.xbmc.org/index.php?title=Streaming

[CAPSLOCK2000]

Hoe zit je in je CPU gebruik. Zo'n VPN kost best wat rekenkracht en dat zou wel eens te veel kunnen zijn voor een HTPC.
Ik gebruik zelf regelmatig sshfs via internet om bij m'n eigen films te komen en dat werkt vrij goed (met een 10mbit inet-verbinding).

PS. Je schijft 6 MB/s. Ik neem aan dat je 6Mb/s (megaBIT) bedoelt, want want 6 MegaByte/s is behoorlijk snel. 6 megabit/s zou ook al ruim voldoende moeten zijn om films te kijken.

[zzattack]

Ik bedoel daadwerkelijk 6 MB/s over FTP (over VPN), alleen haal ik verre van dat over SSHFS/SMB. De CPUs in kwestie zijn een Opteron 6128 (server) en een i3 2100 (htpc), die de VPN encryptie dus gemakkelijk aankunnen. De content die moet worden afgespeeld is wel van vrij hoge bitrate overigens.

[Voor 16% gewijzigd door zzattack op 02-06-2011 17:14]

[dion_b]

Het zou duidelijker zijn om Mb/s te gebruiken ipv MB/s, netwerkverbindingen worden nu eenmaal standaard in b en niet B uitgedrukt. Maar goed, als je echt MB/s bedoelt is het uiteraard even accuraat

Nu de vraag wat voor bitrate (of Byterate als je het echt wilt ) de content heeft. 6MB/s is 48Mb/s. De meeste broadcast-quality HD (1080i) is rond de 20Mb/s. Dat zou dus twee keer moeten kunnen met 48Mb/s.

Twee mogelijkheden:
1) je hebt echt lomp hoge bitrates (>BluRay)
2) je content zou prima in 48Mb/s moeten passen, en je probleem is dus niet bandbreedte maar iets anders.

Het verhaal van ping vind ik niet overtuigend - latency is voor gaming relevant, maar een constante stream kun je met willekeurig welke latency in stand houden. Jitter is een groter probleem, maar een beetje buffer kan dat opvangen.

Als je content >48Mb/s is, is het ook een flinke hap om te decoderen. Zou het kunnen dat je daar in de problemen komt, dat je CPU het gewoon niet trekt?

[TrailBlazer]

voor een tcp connectie is je TCP windowsize/rtt je maximale bandbreedte voor die connectie. Dus ja een hoge latency is wel degelijk van invloed.

[zzattack]

Nee, afspelen is ook geen enkel probleem. De transfer speeds over Samba zijn gewoon laag, en dat lijkt me de voornaamste oorzaak. De bitrate is inderdaad vrij hoog, maar niet >bluray maar gewoon rips, zeg 40GB per 2 uur ~5-6MB/s. Onder goede omstandigheden en met een flinke buffer zou afspelen dus mogelijk moeten zijn, maar met slechts 2MB/s sequential transfer over samba lijkt me duidelijk wat de culprit hier is.

Afspelen over WebDAV met XBMC lijkt voldoende aardig te gaan. Ik denk dat ik het hier gewoon bij laat zitten.

[Voor 11% gewijzigd door zzattack op 03-06-2011 13:37]

[dion_b]

TrailBlazer schreef op vrijdag 03 juni 2011 @ 09:23:
voor een tcp connectie is je TCP windowsize/rtt je maximale bandbreedte voor die connectie. Dus ja een hoge latency is wel degelijk van invloed.

Zie hier waarom streaming doorgaans met UDP gedaan wordt

Dat gezegd: vergroten van de TCP receive window zou prima kunnen werken om verhoogde latency op te vangen.

[Voor 14% gewijzigd door dion_b op 03-06-2011 23:49]

[TrailBlazer]

Streaming wordt over udp gedaan omdat retransmits toch geen zin hebben. Als je een pakket mist heb je even wat blokjes en weer verder.

[dion_b]

TrailBlazer schreef op vrijdag 03 juni 2011 @ 23:51:
Streaming wordt over udp gedaan omdat retransmits toch geen zin hebben. Als je een pakket mist heb je even wat blokjes en weer verder.

Dat ook, maar het niet afhankelijk zijn van latency en minder van jitter (zolang het maar binnen de afspeelbuffer past is het OK) speelt zeker ook mee in eenrichtingsstreams. Bij twee richtingen (VoIP etc) moet die buffer noodgedwongen kleiner om de overall latency te beperken en geldt het weer niet, maar dat is duidelijk niet waar we het hier over hebben.

[johnkeates]

Wat dacht je van QTSS of DSS gebruiken met RTMP achtige protocollen? En iSCSI? GVFS2? Je hoeft ook niet multipath/heartbeat/parllell achtige situaties op te zetten, maar deze systemen werken al gewoon via WAN. Gebruik je trouwens windows? Want met linux zijn er nog een tal van andere opties. AFP is trouwens ook supersnel over WAN.

[mace]

Over SSHFS: Zet de encryptie eens op Blowfish ipv AES. Of als je het aandurft gewoon uit, zou ook moeten schelen.

(In wezen weinig anders dan FTP, dat is ook niet versleuteld)

[johnkeates]

SSHFS is niet echt nuttig zonder SSH. Gebruik dan ook gewoon SSHFS niet als je een remote fs wil mounten zonder ssh

[jvanhambelgium]

dion_b schreef op vrijdag 03 juni 2011 @ 23:47:
[...]

Zie hier waarom streaming doorgaans met UDP gedaan wordt

Dat gezegd: vergroten van de TCP receive window zou prima kunnen werken om verhoogde latency op te vangen.

Heb even je gegevens door een bandwidth-delay product calculator gehaald:
(heb 10ms als gemiddelde RTT genomen, 50Mbits/sec required)
Mischien nog wat de buffers tunen ?


Bandwidth-delay Product and buffer size
BDP (50 Mbit/sec, 10.0 ms) = 0.06 MByte
required tcp buffer to reach 50 Mbps with RTT of 10.0 ms >= 64.0 KByte
maximum throughput with a TCP window of 64 KByte and RTT of 10.0 ms <= 50.00 Mbit/sec.
Further readings about network performance in GN2 PERT knowledge base

[leuk_he]

jvanhambelgium schreef op zaterdag 04 juni 2011 @ 15:49:
[...]

required tcp buffer to reach 50 Mbps with RTT of 10.0 ms >= 64.0 KByte

Wikipedia: TCP window scale option

Als je een recent OS(>=vista) gebruikt is de limiet dus geen 64 KByte meer voor je tcp windyow size. Hoe snel je tcp llayer de window vergroot heb je echter al applicatie geen invloed op.

[dion_b]

Nope, en daar kan het dus mis gaan als de scaling algoritme het niet goed inschat. Mijn ervaring is dat vanaf Vista SP1 het redelijk betrouwbaar was (voor SP1 een drama), maar ik zat dan ook niet met hoge latency te streamen.

Onder Linux werkt autoscaling prima maar kun je ook desgewenst harde onder- en bovengrenzen voor de scaling invoeren. Allicht dat zoiets ook onder Windows kan, dan kun je dit uitsluiten. Kenmerkend is dat zodra je window te klein is, je performance daalt, maar vergroten boven optimum voegt niets toe.

[raymonvdm]

Ik ken wel voorbeelden waar een windows machine een 100mbit glasvezel verbinding niet kan voltrekken. Een ubuntu machine daarin tegen kan het wel. Misschien gaat het ergens mis in windows i.v.m met mtu enz...

[mace]

johnkeates schreef op zaterdag 04 juni 2011 @ 13:48:
SSHFS is niet echt nuttig zonder SSH. Gebruik dan ook gewoon SSHFS niet als je een remote fs wil mounten zonder ssh

Hoe bedoel je dat precies. Niet nuttig zonder encryptie? Want het gaat sowieso over SSH.

[alex3305]

zzattack schreef op vrijdag 03 juni 2011 @ 09:50:
Nee, afspelen is ook geen enkel probleem. De transfer speeds over Samba zijn gewoon laag, en dat lijkt me de voornaamste oorzaak. De bitrate is inderdaad vrij hoog, maar niet >bluray maar gewoon rips, zeg 40GB per 2 uur ~5-6MB/s. Onder goede omstandigheden en met een flinke buffer zou afspelen dus mogelijk moeten zijn, maar met slechts 2MB/s sequential transfer over samba lijkt me duidelijk wat de culprit hier is.

Afspelen over WebDAV met XBMC lijkt voldoende aardig te gaan. Ik denk dat ik het hier gewoon bij laat zitten.

20GB per uur, is zo'n 5.5MB/sec, wat weer zo'n 44Mbit/s moet zijn. Dat is een vrij forse bitrate voor een BDRip. Kun je niet proberen de videos te transcoderen naar een meer acceptabel formaat, zoals h264 in een MKV container. Deze rips liggen meestal rond de 7GB per uur, wat een bitrate van ongeveer 2MB/s moet opleveren.

Daarnaast moet je er overigens ook de geluidsstream bij optellen. Deze ligt vaak rond de 2MB/s (8Mbit) en dan kun je inderdaad tekort gaan komen.

Als laatste zou je trouwens ook nog kunnen testen met een andere mediaspeler of door handmatig de buffergrootte omhoog te schroeven in XBMC. Ik weet namelijk dat de FTP buffergrootte vrij laag is (1MB oid).

Als eigen oplossing zou ik overigens een stream maken via UPnP bijvoorbeeld, zodat je veel gemakkelijker bij je media kan, en wat een techniek is welke opgezet is om te streamen.

[zzattack]

Nogal een non-solution. De movies zijn uiteraard al mkv met h.264 of VC-1, en het is zeker een forse bitrate, maar die zou niet de bottleneck moeten vormen. Als ik de moeite zou willen nemen om alles te transcoden naar een kleiner formaat dan zou ik net zo goed de hele rip lokaal kunnen overhengelen, dan is er ook geen probleem. Hoe dan ook, WebDAV benut vrijwel de gehele verbinding. XBMC draait prima, zeker met een flink grote buffer (cachemembuffersize in advancedsettings.xml).

[Anoniem: 88567]

Heb je toevallig al geprobeerd om NFS wat te optimaliseren?

Ik kwam het volgende tegen op mijn zoektocht: http://dev.n0ll.com/?p=420 en part2 http://dev.n0ll.com/?p=842

[GioStyle]

Zeker weten dat de uploadsnelheid wel hoger is dan ~ 50 Mbit/s? Lijkt mij vanzelfsprekend, maar je zou het toch maar even kunnen vergeten.