Belang van CPU en RAM in een NAS?

[Oscar Whiskey]

Allen

Ik overweeg om een NAS aan te schaffen. Het primaire doel zal zijn data opslag waarvan een groot deel filmbestanden zal zijn. Het secundaire doel is SABnzbd laten werken vanaf de NAS zonder tussenkomst van een PC. Middels een HTPC zal ik deze bestanden willen afspelen. Decoden zal dus plaatsvinden op de HTPC, de NAS dient echter een goede stream te kunnen faciliteren.

Nou weet ik bij een gaming rig wel wat ik mij kan voorstellen bij de prestaties van een bepaalde CPU en een bepaalde hoeveelheid RAM. Maar hoe zit dit bij een NAS? Wat kan ik verwachten bij een single core met 512MB, en wat kan een quad core met 4GB dan meer/beter? Ik heb hier geen gevoel bij..

Uiteraard vraag ik dit vanwege het prijsverschil tussen de 4 bay NASen, daar ik er een wil aanschaffen met RAID5 ondersteuning.

[418O2]

Data transfer en uitpakken kost veel power. Met weinig Power duurt dat dus langer.

[Anoniem: 759877]

Een NAS van deze dagen kan een pak meer dan enkel data opslaan. Dat is op zich weinig cpu-intensief. Echter zijn er velen die een plex media server op hun nas draaien en het transcoden op hun nas laten plaatsvinden, waarvoor je dus wel een degelijke cpu nodig hebt.
Je kan zelfs een webserver op je NAS laten draaien.

Als je in jouw geval enkel en alleen je nas voor data-opslag gaat gebruiken en het transcoden, uitpakken enzo op een secundair toestel gaat doen heb je weinig power en ram nodig ;-) Denk nu ook niet dat dat SABnzbd veel resources nodig heeft.

[Oscar Whiskey]

Ah.. Nou uitpakken en PARren (waar nodig) wil ik zeker wel op de NAS laten doen. En ik wil ook niet het risico lopen dat de NAS de overdrachtsnelheid trager maakt dan de HDDs aankunnen.

Ik overweeg WD RED 4TB schijven te gebruiken.

[albatross]

Voor puur streamen heb je uiteraard niet veel geheugen nodig. SABnzb, en Spotweb e.d. hebben echter wat meer nodig (vooral CPU, maar als je je MariaDB ook een beetje lekker wil laten draaien, dan kan ook een beetje extra geheugen geen kwaad).

Zelf heb ik nu een XPenology NAS, draaiend op ESXi; die heb ik 2 virtuele CPU's gegeven (van een i7 980X), en 2G geheugen. Dat loopt als een zonnetje.

[Mijzelf]

Oscar Whiskey schreef op zaterdag 11 juni 2016 @ 15:18:
En ik wil ook niet het risico lopen dat de NAS de overdrachtsnelheid trager maakt dan de HDDs aankunnen.

daar ik er een wil aanschaffen met RAID5 ondersteuning.

De NAS zal sowieso trager zijn dan de schijven aankunnen. Een moderne schijf haalt makkelijk 100MB/sec, en vier in RAID5 kunnen dus theoretisch 300MB/sec of meer.
Ondertussen hangt hij aan een netwerktouwtje, waar het wel ophoud bij 110MB/sec.

Overigens is het mijn ervaring dat als een NAS door nevenactiviteiten traag wordt als data opslag, dat niet zozeer aan de processor belasting ligt, maar meer aan de disk belasting. De snelheid van een harde schijf zakt dramatisch in als hij veel dingen tegelijk moet doen. In sommige gevallen werkt het dan om een sloot geheugen te hebben, waardoor veel gecached kan worden. Maar niet bij downloaden, denk ik.

Bij het downloaden van NZB's maakt het nogal uit of je dat encrypted wilt doen, en hoe dik je internetpijp is. Encryptie is duur. Een budget NAS met een Marvell Kirkwood kan ongeveer 2MB/sec halen met NZBget. Met SABnzb is dat minder, aangezien die downloader zelf duurder is. Als je een 100Mbit pijp wenst dicht te trekken met encrypted data, heb je dus een veel steviger processor nodig.

[Oscar Whiskey]

OK, ik begin een beeld te krijgen, al vindt mijn portemonnee dat denk ik niet zo leuk..

Ik download namelijk met 300MBit (35MB/s netto) via 20 SSL usenetlijnen. Moment dat mijn NAS dit niet trekt zal ik direct overschakelen naar mijn gewone box om te downloaden. Maar dat is natuurlijk niet het idee..

[albatross]

Oscar Whiskey schreef op zaterdag 11 juni 2016 @ 16:07:
OK, ik begin een beeld te krijgen, al vindt mijn portemonnee dat denk ik niet zo leuk..

Ik download namelijk met 300MBit (35MB/s netto) via 20 SSL usenetlijnen. Moment dat mijn NAS dit niet trekt zal ik direct overschakelen naar mijn gewone box om te downloaden. Maar dat is natuurlijk niet het idee..

Waarom denk je dat je NAS schijven geen 35MB/s aankunnen?! (Tenzij je van plan was totale rotzooi te kopen). Unpacken kost iig ook CPU, en dat zal op een echte Synology NAS, wat een zielige Celeron, waarschijnlijk wel de bottleneck worden dan.

[Mijzelf]

albatross schreef op zaterdag 11 juni 2016 @ 16:28:
Waarom denk je dat je NAS schijven geen 35MB/s aankunnen?!

Het gaat niet om de schijven, het gaat om de SSL.

[haarbal]

vroeger sabnzbd gedraaid op m'n ds210j, met een paar MB/s was de cpu al wel vol, unpacken duurde ook wel even.

gewoon netwerkverkeer is geen probleem natuurlijk.

[albatross]

Mijzelf schreef op zaterdag 11 juni 2016 @ 16:31:
[...]
Het gaat niet om de schijven, het gaat om de SSL.

Vandaar dat ik ook zei dat zijn CPU dan waarschijnlijk wel de bottleneck gaat worden. Maar ook zonder SSL, als je met 35MB/s downloadt, dan moet er toch een hoop unpacked worden (en vaak). Dat ga je met een Celeron gewoon niet meer trekken.

[Oscar Whiskey]

OK, dus voor regulier netwerkverkeer op de snelheid die schijven aankunnen zou een 1Ghz single/dual core met 1GB RAM voldoende zijn?

Maar met mijn lijn en SABnzbd wordt het dus een ander verhaal..

[albatross]

Oscar Whiskey schreef op zaterdag 11 juni 2016 @ 16:49:
OK, dus voor regulier netwerkverkeer op de snelheid die schijven aankunnen zou een 1Ghz single/dual core met 1GB RAM voldoende zijn?

Maar met mijn lijn en SABnzbd wordt het dus een ander verhaal..

Inderdaad. Gewoon streamen kost nauwelijks CPU; noch geheugen. Maar als je met 20 SSL lijnen tegelijk gaat downloaden (en ook op wicked snelheid wil unpacken), dan als je denk ik toch een zwaarde CPU nodig hebben. Ter vergelijk, mijn 2x virtuele i7 980X CPU's staan op zijn 16-20% te burnen wanneer SABnzb flink te keer gaat (realiseer me eigenlijk nu pas dat SABnzb eigenlijk niet zo CPU-vriendelijk is).

[albatross]

^^ Over 20 SSL lijnen gesproken, je zou het natuurlijk ook gewoon met de helft kunnen doen. Scheelt weer bakken CPU-cycles. Voor mij (giganews) ligt het optimum ergens rond de 6 lijnen tegelijkertijd. Met veel meer extra lijnen ga je erg weinig extra winst halen (en soms zelfs wat verliezen), terwijl je CPU cycles aanmerkelijk oplopen (voor iedere established SSL connectie).

[Oscar Whiskey]

Ik vermoed dat ik nu verder moet in de sectie CAA waarbij ik een split ga maken tussen een NAS die usenet afhandelt zoals ik dat nu op mijn gewone bak doe, en een NAS die dat niet doet. Als er namelijk drastisch prijsverschil is laat ik mijn gewone bak usenet doen en wegschrijven op de NAS array.

Ik ben mijn 300MBit en 20 SSL lijnen inmiddels gewend en ik heb eerlijk gezegd geen behoefte om e.e.a. nu te moeten gaan micro managen omdat het nieuwe systeem dit niet trekt op deze manier.

[ Voor 24% gewijzigd door Oscar Whiskey op 11-06-2016 17:24 ]

[albatross]

Oscar Whiskey schreef op zaterdag 11 juni 2016 @ 17:23:

Ik ben mijn 300MBit en 20 SSL lijnen inmiddels gewend en ik heb eerlijk gezegd geen behoefte om e.e.a. nu te moeten gaan micro managen omdat het nieuwe systeem dit niet trekt op deze manier.

Begrijpelijk. Maar mijn punt was meer, dat je je af kunt vragen of je daadwerkelijk winst behaalt met 20 pipes (als in: je kunt een taart in zo veel stukjes opdelen als je wilt, maar daar wordt het totale volume niet groter van). Je ziu het voor de lol gewoon eens met 10 pipes moeten proberen, en kijken of je dan echt langzamer bent. Maar goed, ik heb zelf nog nooit op die snelheid gedownload.

[Oscar Whiskey]

Net gedaan. Bij mijn huidige usenetaanbieder haal ik de max met 17 lijnen, bij minder ga ik op de totale snelheid inleveren.

[albatross]

Oscar Whiskey schreef op zaterdag 11 juni 2016 @ 18:14:
Net gedaan. Bij mijn huidige usenetaanbieder haal ik de max met 17 lijnen, bij minder ga ik op de totale snelheid inleveren.

Hmm, lijkt erop of ze dan de 'per-connectie' download snelheid gelimiteerd hebben of zo. Ja, dan maar verder met 20.

[technorabilia]

Als je optimaal wilt uitpakken kun je beter zelf bouwen i.p.v. Synology kiezen.
[Synology] RAR unpacking performance
Aan de andere kant is het idee met een nas natuurlijk dat je alles automatisch laat downloaden zodra het beschikbaar is en dan maakt de uitpaktijd niet zo gek veel uit.

Edit:
RAM > 1-2 GB is belangrijk als je bv. met VM's of Docker gaat werken of als je er bijzondere dingen mee wilt doen.

Edit2:
Tip: als je een Synology kiest neem dan er eentje met een Intel processor. Dan alleen kun je Docker draaien en VirtualBox.

[ Voor 29% gewijzigd door technorabilia op 11-06-2016 18:23 ]

[Oscar Whiskey]

Hmm.. Vind de resultaten nogal tegenvallen vergeleken bij mijn i7/16GB. Nooit gerealiseerd dat dit een bottleneck gaat worden.

[technorabilia]

Klopt, dat valt in het niet als je ^^^ bent gewend. Maar zoals gezegd heeft een nas andere kwaliteiten en kun je kijken of je i.p.v. ala minute downloaden beter verspreid kunt downloaden waar je dan niet direct op zit te wachten. Een nas is voor veel toepassingen 24/7 inzetbaar met laag verbruik.

[Tortelli]

Hoe vaak zit je werkelijk te wachten op een download?. Bijna nooit volgens mij.... zeker niet met 300Mbit. Een gemiddelde serie in 720p download je in 30 seconden .

Heb zelf een DS1815+ met 16GB ram en 300 / 30 verbinding (Ziggo). De 300Mbit kan de DS1815 (of DS415+ of 916+) probleemloos dicht trekken op SSL. Wat minder connecties kan snelheid opleveren (vooral door lagere cpu load) maar is verder niet zo boeiend.

Heb op beide apparaten een SSD als download (incomplete) locatie, pakt uit naar HDD (of mijn 6 disc SHR volume in het geval van mijn DS1815+). Vooral de IO's maken een single HDD traag, door hier ramgeheugen (1GB) en SSD voor te gebruiken win je veel snelheid.



Voornaamste wat me opvalt (maar Sabnzbd helaas niet weergeeft) is het controleren van bestanden, dat lijkt op de DS1815+ relatief lang te duren.

Repair tijd klopt niet, op een of andere manier heb ik op de Synology repairs terwijl ze op mijn PC probleemloos binnen komen (zie reactie hieronder voor de oplossing).

[ Voor 78% gewijzigd door Tortelli op 11-06-2016 20:28 ]

[Oscar Whiskey]

Tortelli, jouw methode in mijn geval zou dus een een kleine (64GB ofzo) SSD zijn plus mijn 9netto/12bruto TB RAID5 array zijn. Wellicht iets om te overwegen..

En ja, ik zit de helft van de keren wel met spoed op een download te wachten die ik dan het liefst 10 min. na het klikken wil zien

[Tortelli]

Ik zou (als je hem toch nieuw koop) een wat grotere disc pakken. Ik had 2 discs "over", een 180GB Intel 520 (?) uit mijn werk laptop en een 60GB Intel 320 uit een IPC waar mobo van kapot was (ook werk). 60GB is in sommige gevallen te klein, en die 60GB SSD is vrij traag (200MB read, 80 write oid).

Zie mijn post hierboven trouwens, voeg zo resultaat toe van mijn DS1815+. Zal hem daarna herhalen waarbij ik bewust een file kapot gemaakt heb (en hij moet repairen).
Vooral het repairen gaat bij veel NASsen erg traag (ARM chip). Op de Intel C2538 heb ik dit nog niet getest...

[ Voor 33% gewijzigd door Tortelli op 11-06-2016 19:31 ]

[technorabilia]

Het ging om de uitpaktijd niet zozeer de downloadtijd.
Voorbeeld op een DS716+ hieronder. Niet zo snel als op een i7 computer maar het duurt ook geen eeuwigheid. Dat zal dus nog wat sneller kunnen op andere modellen. En misschien wil je wel een ander merk...

Finished at 2016-06-11 15:37:55
Downloaded 8.2 GB

Stage Unpack
[1335f1f040bfac27972487ae2acbba43] Unpacked 17 files/folders in 1 minute 57 seconds

Stage Repair
[1335f1f040bfac27972487ae2acbba43] Repaired in 1 minute 2 seconds

[ Voor 9% gewijzigd door technorabilia op 11-06-2016 19:33 ]

[Oscar Whiskey]

Ik wil sowieso een QNAP of Synology, niet iets anders. Dit vanwege de vele positieve reviews over beide merken, en het feit dat deze ongeveer de markt overheersen. Dan heb ik altijd voldoende support (hopelijk) wanneer nodig.

Dit is mijn shortlist:
http://tweakers.net/price...668;404669;462006;548723/

[Tortelli]

Mijn (beperkte) ervaring is dat de ARM cpu's niet erg snel zijn met uitpakken etc. Zie ook de scores van ARM chips in het [Synology] RAR unpacking performance topic waar kraades al heen linkte.

Paar tests gedraaid;


edit: Verificatie van 3,3GB bestand duurt relatief lang (49 seconden). Repair tijd volgens Sabnzbd 1.0 was 3 minuten en 54 seconden.
Daar is zelfs een vrij krachtige NAS gewoon veel minder snel in als een dikke i7. Komt ook deels omdat Sabnzbd dit op de Synology single core doet terwijl mijn pc op 100% zat te vlammen .

[ Voor 79% gewijzigd door Tortelli op 11-06-2016 20:27 ]

[Oscar Whiskey]

Dankje voor de moeite, top! Ziet er dus naar uit dat regulier binnenslurpen niet zo'n issue is, maar als er rekenwerk nodig is dan zie je dus waarom een i7 iets anders is dan de dual core uit een NAS

BTW, heb dezelfde CPU en ook 16GB. Loopt al 1,5jr stabiel op 4,7Ghz. Heerlijk geval, zeker de prijs/kwali vs. de 5th gen die toen uit gingen komen.

[Twazerty]

Heb zelf de Synology DS414j, geprobeerd daar SabNZBd te draaien, maar dat was zo traag dat ik het binnen 5 minuten weer verwijderd heb. Het geheugen en de cpu zijn dan gewoon zwaar gehandicapt, downloaden, repairen en extracten waren alle traag. Mijn goedkoop Q1900 systeem is daarin een heel pak rapper. Of de NAS met de j1900 dan even snel is als een standalone j1900 met 8GB weet ik niet, maar ben wel benieuwd.

[ Voor 15% gewijzigd door Twazerty op 11-06-2016 20:41 ]

[Tortelli]

Een J1900 verschilt amper van de C2538;
http://nl.hardware.info/r...benchmarks-cpu-benchmarks

C2550 is bijna identiek, hij overclocked iets verder geloof ik. Het is imo wel jammer dat de NAS fabrikanten gestoorde prijzen vragen voor modellen met een i3 of b.v G4400. QNAP is daar nog "enigszins" vriendelijk mee en vraagt ~€1000 voor de goedkoopste met i3 (b.v. deze). De Synology DS3615+ kost >€2k.
QNAP bied zelfs i7's aan; http://tweakers.net/product/420876/qnap-turbo-vnas-tvs-871/

Echt nodig heb je het als consument overigens niets, zelfs de Windows 7 installatie die ik via virtualbox draai is snel zat voor wat hij moet doen.

[ Voor 27% gewijzigd door Tortelli op 12-06-2016 09:56 ]