NiGeLaToR schreef op dinsdag 18 april 2017 @ 16:11:
De cache functie is voor mij vooral een leuke bijkomstigheid / noviteit, maar ik weet dus even niet zeker hoe dat zit met die 1-2 SSD's die nodig zijn. Heb je dus voor read/write cache altijd 2 SSD's nodig?
Ja, staat ook
hier mooi in uitgelegd.

(pagina 5, onderaan)
Zijn er verder nog bijzonderheden om rekening mee te houden als je caching wilt gebruiken? Ik weet dat er geheugen vs caching berekeningen zijn en dat je moet nadenken wát je wilt cachen.
Een belangrijk punt waar ik niet op had gerekend, en waarvan ik niet snap waarom ze het niet fixen; (Ja ik heb er destijds een ticket voor aangemaakt, meer requests helpen misschien.

)
- Read-only cache (1 SSD of meer) wordt gewist bij een reboot.
Elke nache je NAS uit = elke dag je cache op 0..
- Read-Write cache (2 SSD's) blijft behouden bij een reboot.
Qua instellingen hoef je nergens over na te denken. Je kunt het alleen aan of uitzetten.

(O en je kunt kiezen of je sequentiele I/O wilt cachen ja of nee.. Over het algemeen wordt sequentiele I/O qua snelheid toch gelimiteerd door de Gbit snelheid van je netwerk en niet door je HDD's, dus deze kun je waarschijnlijk net zo goed uitzetten..)
100% Confirmed. (zojuist getest, na enkele seconden shiet je RAM Cache gebruik met 1GB omhoog.

)
Tortelli schreef op dinsdag 18 april 2017 @ 22:21:
Kortom maakt niets uit...... qua access time zou de SSD wat sneller moeten zijn. Alleen meet Crystalmark dat nu net niet.
Ik weet niet zeker hoe slim Synology omgaat met het up en down spinnen van de HDD's. Misschien dat de SSD cache hier een goeie invloed op heeft... not sure.
Volgens mij komt het voordeel van een SSD cache er echt uit als je met veel gebruikers erop zit.
Beide screenshots zijn geen resultaten komend van een (of meerdere) HDD's.
Die 4k read/write zijn op gewone HDD's echt een factor 10 a 100 lager.
Mijn ervaring is ook dat ALLES wat wordt ingelezen standaard in het RAM gecached wordt.
Deze bestanden blijven, afhankelijk van welke bestanden het vaakst worden benaderd, hier in principe altijd gecached zolang een ander proces/app dit geheugen niet nodig is.
Staat ook wel weer mooi uitgelegd in de
White Paper, met-en-zonder SSD Cache.
Of up-en downspinnen invloed heeft; ik denk het eigenlijk niet.
Ik denk dat het zo gaat:
Voordat de benchmark de read-test doet, wordt er 1GB aan testdata naar de schijf geschreven.
Als deze er op staat, pas DAN wordt deze gelezen/gebenchmarked.
Tussen het initiële wegschrijven en het benchmarken zit zo weinig tijd dat de HDD's niet gaan downspinnen. Sterker nog: Ik denk zelfs dat de HDD's hierdoor juist vanaf de start al op hun maximale toeren draaien.

Was er zelf al mee bezig voordat jij het postte.

Ik heb de test eerst enkele malen gerund (RAM loopt per test op) net zo lang totdat de 8GB gevuld is (~150MB 'Free', dit is standaard en vult hij simpelweg 'nooit'.
Hierna nog 2x laten draaien zodat ik zeker wist dat hij echt vol zat.
Nieuwe test --> Zelfde resutlaten: 70 a 90 MB/s op de 4k Q=32 read/write, en 12 á 13 MB/s op de 4k read/write.
Dat zijn gewoon geen HDD snelheden..
Ik denk dat je er niet onderuit komt dat alle nieuwe data standaard naar het RAM gaat. (misschien is het mogelijk als je deze vol laat lopen met data, welke je daarna 20x opvraagt.. zodat deze de daarop volgende benchmarkdata 'overruled'.
[
Voor 6% gewijzigd door
SmiGueL op 19-04-2017 01:25
]
Delidded 4770K 4.7GHz @ H220 || Gigabyte Z87X-UD4H || 16GB @ 2400MHz || Gigabyte GTX 760 || 2x128GB Samsung 830 @ RAID-0 & WD 3 TB || Iiyama XB2483HSU-B1 || Synology DS916+ 3x6TB + 120GB SSD Cache || Synology DS213+ 6TB backup