Da da, vidija sam te na PcE, kako si lijepi zalizani :D.
Stavljam i ovo na listu praćenja, hvala obojici.

Nastavio sam dalje sa testiranjima, cisto iz znatizelje...

Napravio sam 2x2GB RAID0 RAMDisk NTFS baziran na DDR5-5200 RAMu i gledam gdje cu naletiti na bottleneck... Koristio sam RAID0 od Windowsa jer je to jedini nacin za napraviti ovaj eksperiment... U ovom slucaju ne mogu koristiti FAT32, tako da sam koristio NTFS sa defaultnim block sizeom...

Naravno, rezultati su bezvezni i ne mogu dobiti vece brzine nego sto sam jucer dobijao sa jednim 2GB RAMDisk NTFS... Zapravo, dobijam cak i manje brzine sto je i razumljivo s obzirom na overhead koji Windowsi ubacuju zbog softRAID polja...

Sve u svemu, rezultat je takav da slaganje softRAID0 polja na RAMDisku nema nikakvog smisla... Napominjem, ovo je bio eksperiment i ideja je bila pokazati sto se moze ocekivati... Drugim rijecima, ukoliko treba doci do poboljsanja, to nije na ovaj nacin...

Side by side, jednostruki RAMDisk vs softRAID0 RAMDisk...

https://i.postimg.cc/SNRvRstd/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/0js2HZdc/2025-0...-01-0f1-75.png

https://i.postimg.cc/JzBY3F8B/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/QCJxL5fs/2025-0...-01-0f1-75.png

Isao sam dalje testirati, ovaj puta allocation unit size na razlicitim filesystemima... Testirao sam default 4kB vs 16kB na FAT32 i isto tako default 4kB vs 16kB na NTFS... Za NTFS sam napravio jos dodatni test sa 64kB allocation unitom da vidim kuda to ide...


Kod FAT32 testiranja je vidljivo povecanje i bandwidtha i throughputa u slucaju veceg allocation unita, sto je bilo i za ocekivati... Dokazano je da je 16kB velicina allocation unita na FAT32 bolji izbor za performanse nego defaultnih 4kB, no to onda vuce druge probleme vezane za jako neefikasno koristenje diskovnog prostora...

FAT32 allocation unit test side by side - 4kB (default) vs 16kB

https://i.postimg.cc/0NRWVC5X/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/TPf0fX26/2025-0...-01-0f1-75.png

https://i.postimg.cc/SK6Z3zJS/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/HLz2LPj7/2025-0...-01-0f1-75.png


Kod NTFS testiranja je situacija malo skliska, tako da je na 16kB vidljivo povecanje bandwidtha i throughputa na nizim IO blokovima, onda malo pada tamo prema velicini bloka od 1MB i onda je do najvecih velicina blokova od 64MB i dalje u prednosti nad 4kB default allocation sizeom... Sto kako i zasto se to desava, ne znam... Na kraju je prikazano ponasanje sa 64kB allocation size da se vidi kuda sve to vodi, a izgleda da ne vodi nikud... Konacni zakljucak - 4kB sweet spot za NTFS...

NTFS allocation unit test side by side - 4kB (default) vs 16kB

https://i.postimg.cc/SNRvRstd/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/25GsfGD0/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/MZgVD8QY/2025-0...-01-0f1-75.png

https://i.postimg.cc/JzBY3F8B/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/Y9SJ2F2M/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/zXWW2PwY/2025-0...-01-0f1-75.png

Zanimljive rezulate sam dobio sa ReFS, default 4kB allocation unit size...

https://i.postimg.cc/tJJkVd8C/2025-0...-01-0f1-75.png https://i.postimg.cc/fyPK7th7/2025-0...-01-0f1-75.png

Ako nekog zanima malo vise o ReFS vs NTFS...

Cluster size recommendations for ReFS and NTFS

Jebotepas calypso, na stranu sad projekt sam po sebi, ali odakle ti toliko vremena:D. Odakle ti ta sloboda da do pola 3 ujutro testiraš razlike između ntfsa i fata32 i razlike po ramdisk cluster size-u :roller:
Otkrij mi tajnu :D

Kada sam imao razgovor za posao u Infortrendu, zakljucili smo da imam prilicno izrazen 'passion for storage'... A i dosadno mi je... :D


Nemam radno vrijeme... Radim kad mi se radi ili kada imam posla ili kada trebam biti na sastaku...

S obzirom da radim za storage vendora, svi ovi rezultati su mi korisni kod smisljanja novih produkata ili use caseova za postojece produkte... A i dobro dodje da si malo ponovim koristenje ATTO Disk Benchmarka...

Cilj ovog eksperimenta sa RAMDiskom je bio pronaci nacin kako prebaciti cache/temp foldere (dakle potpuno nebitne stvari) na RAMDisk... Ujedno, zelio sam provjeriti da li ce se ista ubrzati... Odokativno, osjetim da su neke stvari malo brze, ali ne znam sa cime bih to izmjerio... Ivo_Strojnica je predlozio da provjeri da li mu se brze ucitavaju web stranice pa eto, kada on to rijesi ce valjda i dati neke rezultate... Ja sam odlucio ici na hardcore rezultate koristeci ATTO Disk Benchmark koji je u storage industriji de facto standard za testiranje performansi diskovnih sustava...

Dalje sam nastavio sa eksperimentom da vidim sto sve mogu dobiti i kolike cu brzine dobiti u citanju/pisanju na razlicitim memorijskim tehnologijama (DDR4 i DDR5)... Recimo, DDR5 moduli po defaultu rade u dual-channel modu pa se vide velike razlike u odnosu na DDR4... Dalje sam isao usporediti FAT32 vs NTFS po pitanju performansi... Pa sam otisao korak dalje i provjerio sto cu dobiti uz razlicite velicine allocation unita na oba filesystema... U mix sam dodao i ReFS cisto da vidim kako to radi i sta se sa time moze...

Svjestan sam da je NTFS puno bolji filesystem, no za nebitne stvari (ephemeral data) poput TEMP/Cache/Scratch gluposti uopce te napredne stvari ne dolaze do izrazaja, vec se traze najbolje performanse... Mislim, koji ce mi djavo journaling, kompresija i ostale gluposti ako trebam scratch file za Photoshop ili Audacity sa kojim cu zavrsiti za 15 minuta? Eno, trenutno kolega pokusava istestirati kako ce mu DeepSeek AI raditi sa 4GB RAMDiskom jer mu se sve vuce preko NVME diska...

Sto se moje malenkosti tice... 25 godina se bavim proucavanjem storage sustava, filesystema, backupa, arhiviranja, storage virtualizacijom... Od 2006 se bavim dizajnom i prodajom diskovnih sustava, radio sam za EMC i Veritas distributere i partnere u Hrvatskoj... Imao sam pristup dokumentaciji kojima normalni korisnici nemaju pristup, nacitao sam se whitepapera, tech guideova, Veritasovih Yellowbookova... Zadnjih 6 godina radim za storage vendora (ne, nije Infortrend) koji u portfelju ima produkte za storage virtualizaciju, davno smo bili partner od Violin Systems... EMC i Hitachi su koristili nase tehnologije u svojim specijaliziranim diskovnim sustavima, itd... To je samo storage dio price, a o virtualizaciji i cloudu ima jos veci dio price s obzirom da jos od pocetka 2000tih proucavam virtualizaciju kao koncept... Od 2007. sam se bavio prodajom VMware produkata, digao jednog lokalnog partnera na VIP Premier level jos tamo 2009 godine (800.000 EUR VMware prodaja 2008 godine), nakon toga 2010. presao u cloud vode, vodio IT odjele u firmama od 1200 i 3000 ljudi gdje se vrtilo par tisuca VMova u AWSu, odradio preko 50 cloud migracija u AWS i VMware vCloud (to je kada uzmes servere iz datacentra, virtualiziras ih i prebacis u cloud)... Tada se jos nije znalo niti sto je to cloud, a jos manje kako se prebaciti u cloud... Odradjivali smo online migracije, offline migracije, realtime migracije sa alatima koji su tada bili dostupni... Odradio vjerojatno jednu od prvih cloud migracija u VMware vCloud ikad o kojoj je napisan customer use case svojedobno, to je bilo 2010... Trazili smo od AWSa da prime diskove koje im saljemo pa su morali osmisliti za nas nacin kako da prime diskove, iz cega je kasnije nastao AWS Snow-family servis koji sluzi za slanje velike kolicine podataka u AWS... Rekao sam prije - zaboravio sam vise stvari nego sto su mnogi forumasi ikad znali o storage tehnologijama...

Ako koga zanima sto sam 2010 pisao o Enterprise Flash SSDovima i TBw u vezi kojih me nedavno jedan forumas prozivao, evo tu je prezentacija... Mislim, ne razumijem zasto se mene proziva da ne znam osnove osnova...

https://www.slideshare.net/slideshow...drives/5455798



Tako da svo ovo prozivanje od strane doticnih je ispod svakog ljudskog nivoa... Srecom pa sam otkrio ignore i kako ih staviti na ignore...

Samo jedna napomena, ovisno o vrstu fajla, kompresija na nivou FS može (znatno) poboljšati performanse uz praktično zanemarivi CPU overhead. Pitanje što bi to značilo točno za 4k.

Calypso svaka cast na volji ali da nisi malo zaglibio u Burnout vode?

@tomek@vz malo offtopic pitanje za tebe...spominjao si da si radio u Linksu u Vž, jel si radio s Krunom i svojevremeno smo se "krzali" par puta u poslovnici?

A jesi naso temu :) Yep :P

Evo neću više majke mi :)

Vjerujem da moze poboljsati performanse na HDD i SSD diskovima (NVME i slicni) gdje su brzine CPU i RAM nekoliko redova velicine brze od samog diska... No pitanje je sto bi se desilo sa RAMDiskom koji ide do 24GB/s write, koliko bi tu CPU unio overheada jer ipak imas nekoliko IO operacija koje inace ne bi imao, tipa moras prvo dohvatiti podatak sa RAMDiska (IO), zatim zapisati ga u RAM (IO), pa onda CPU mora dohvatiti podatak (IO), raspakirati ga (CPU), zatim sve to dumpati nazad u RAM (IO), pa onda opet dohvat novog podatka u RAMu (IO) i onda obrada podatka (CPU) i opet pisanje natrag u RAM (IO), pa ako sve to ide na disk onda moras opet dohvacat, kompresirat, stavljat u RAM, pa onda bacat na disk... Tu se ubijaju IO operacije zbog kojih smo i odlucili koristiti RAMDisk... :) Trebalo bi to nekako istestirati, no nemam pojma jos na koji nacin... Idem bas probat ukljucit kompresiju na NTFS RAMDisku pa javim rezultate prije i nakon kompresije... Bas me zanima sta ce se desiti sa throughputom (IOPS)...

Po meni sve što ide u RAM disk i tako ide preko RAMa, pa ako usput bude još i komprimirano, ukupni write speed mora biti još viši.

Ajd bas budem zavrtio test pa cemo biti pametniji... :)

Zavrtio sam test... 2GB NTFS volume sa i bez kompresije... Testirano na DDR4-2400 baziranom RAMDisku... Rezultati su prilicno zanimljivi kod kompresije - read je doslovno 2x brzi, dok write bolje da ni ne spominjemo koliko je katastrofalno spor... Sutra cu zavrtit na DDR5-5200 pa da vidim kako se tamo ponasa...

Edit: Sad kad sam se malo naspavao sam vidio da je read uduplo brzi na malim velicinama bloka (block size), do 4kB... E nakon toga pada i read performanse...


https://i.postimg.cc/YqFL1RyH/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/g0zwbWcz/2025-0...-01-0f1-75.png


https://i.postimg.cc/BnGLNFd1/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/bwHG5JhV/2025-0...-01-0f1-75.png

Testirao sam danas performanse 2GB NTFS volume sa i bez kompresije... Testirano na DDR5-5200 baziranom RAMDisku... Opet ista prica kada se kompresija ukljuci - kriminalno spor write, ali read je uduplo brzi nego bez kompresije do nekih 4kB block size, nakon toga pomaka nema...

https://i.postimg.cc/bwGdjvd4/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/ydKN9Xnz/2025-0...-01-0f1-75.png

https://i.postimg.cc/52Zy9MCy/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/7L06fQ3V/2025-0...-01-0f1-75.png

Sad si i mene zarazio s ovim glupostima :D Jučer sam htio vidjeti kako se ponaša tempfs vs ramfs. Koliko ja vidim na DDR4 3200 bi max trebalo biti teoretskih 25.6 GiB/s. Neki benchmark koji sam odradio kazuje da je to kod mene zapravo 17.4.

tempfs i ramfs daju max 2.8 GiB/s (sekvencijalno), tako da sve ovo i nije netko pretjerano mjerilo. Čitam da ta dva *fs nisu niti rađeni u svrhu maksimalnih performansi, što ima smisla. Približno iste performanse imam na NMVE, 2.5 GiB/s.

Sve te rezultate mi je dao dd, pretpostavljam da /dev/null nije usko grlo.

Kada u RAM napravim file i formatiram ga kao BTRFS i onda to mountam kao disk, dobijem max 1.1 GiB/s. Ako isti "disk" mountam sa kompresijom, brzina ode na 1.5 GiB/s. Pričamo sekvencijalno. Koliko to sve skupa ima smisla, vjerojatno nema niti najmanje :D

Budem kasnije napravio par rsync testova, zanima me kako se ponaša sa hrpom malih fajlova.

Xexe :D

Svidja mi se da cemo na ovoj temi imati hardcore rezultate raznih testova RAMDiska... Ovo sa rsync i ponasanjem na hrpi malih fajlica je zapravo jako zanimljivo...

Jos da Ivo_Strojnica odradi svoje Apache testove brzine ucitavanja web stranica... :)

Danas ili sutra kad ulovim vremena cu jos ponoviti testove sa 'Bypass write cache' ukljucenim da vidim kakvi ce onda biti rezultati...

Evo rezultati sa 'Bypass write cache' na DDR4-2400... FAT32 vs NTFS...


FAT32 vs NTFS Bandwidth / Bypass write cache

https://i.postimg.cc/prT983XB/2025-0...-01-0f1-75.pnghttps://i.postimg.cc/RVW60rYS/2025-0...-01-0f1-75.png


FAT32 vs NTFS Throughput / Bypass write cache

https://i.postimg.cc/wMG1kF1Y/2025-0...-01-0f1-75.png
https://i.postimg.cc/VsG01sDZ/2025-0...-01-0f1-75.png

Ček da probaš rsync s hrpom malih datoteka i puno hardlinkova :D
Naročito target FS se malo napati kod toga.

Kad vec volis zanimljive testove, evo jednog na Linux serveru.
Skaliranje throughputa ovisno o broju NVMe diskova.

Propusnost je u GBytes/sec, a dole je broj diskova. I graf 'idealno' vs 'realni svijet'.

112 GBytes/sec je bez obzira na to poprilicno impresivna brojka :D

https://i.postimg.cc/mrMG1NWS/throughput.png

Na kakvoj to masini imas toliko NVME diskova? I cem to sluzi, to ima smisla jedino za lokalnu primjenu...

Znam da je ogroman problem izbacit sve to van prema mrezi i da se radi na razoju NVMeOF za takve stvari, no i taj ima svojih problema... Prica se o 100Gbps, no to je Gigabita u sekundi, al kako izvuci jos 10x vise od toga, znaci 1Tbps, to nemam pojma... Infiniband? RoCE?

Usput, vidim da se dosta mijesaju termini bandwidth i throughput od vendora do vendora... U mom slucaju, bandwidth je MB/s, dok se throughput mjeri u IOPS... To je EMC skolica i tako se u njihovom svijetu oznacavaju stvari... Vidim da drugi navode da je bandwidth teoretska brzina prijenosa, dok je throughput realna brzina prijenosa u MB/s...

EMC terminologija - https://www.dell.com/support/kbdoc/e...ce-terminology

IBM Cloud terminologija - https://cloud.ibm.com/docs/vpc?topic...ty-performance

Ima jedna stvar kod sekvencijalnog throughputa.

PC storage koristi DMA kontroler za prebacivanje podataka sa storagea preko PCI(e) sabirnice direkt u RAM i obrnuto. S druge strane RAM drive koristi CPU za prebacivanje podataka, opterećuje ga i može ga zakucati odnosno bar jedan core za jedan kontinuirani stream.

Zato brzi storage ekšli može imati veći throughput od RAM drivea.

Pa.. najzanimljivije (najtuznije?) je da je ovo namijenjeno da se vrti CEPH na tome.
Imao prilike za probati, pa probao koliko ide (nije da bas svaki dan imas server sa 20 x NVMe diskova) :D
Isto tako server je imao 2x dual-port 100GBps kartice. I koliko god da djeluje to fora, napuniti taj bandwidth izmedju dva servera je poprilicna nauka. Uspio natjerati kojih 70Gbps sa iperf-om na 100Gbps interface-u, ali vise nije htjelo...

Rekao bih da tebe hebe TCP overhead jer je iperf alat za testiranje mreznih (TCP/IP) performansi... A TCP i IP nekako bas i nisu low-latency protokoli... :) Cak i sa TCP offloadingom, unosis latencije koje su vidljive na tim brzinama...

Probaj sloziti NVMeOF ako mozes preko toga tako da sibas NVMe protokol preko te mreze nekako...

U svakom slucaju zanimljivo, iako ne znam sta ce ti takvo sto za Ceph... Vise bi smisla imalo uzeti malo vise manjih servera sa diskovima manjih kapaciteta i sloziti ih u Ceph cluster...


A i pitanje je sto mozes dobiti na Cephu ako ces ga koristiti kao block device... Ceph je primarno object storage preko kojeg se lijepi block storage ili file storage... Tako da i tu imas jos malo overheada...

Casna rijec, sad me bas zanima kako bi radio Ceph na RAMDisku... :D

Usudio bih se reci da je ideja RAMDiska bas throughput u smislu IOPSa, a manje bandwidth u smislu GB/s... :) Onako, baratanje sa sicusnim podacima, no tek to bi trebalo ubiti CPU onda...

Ajd budem izvrtio malo kasnije par testova bas da vidim sta se sa CPU desava...

Gledam CPU usage dok testiram sa ATTO Disk Benchmarkom, nema nikakvih spikeova niti mi zakucava jednu jezgru, malo podigne frekvenciju procesora (sa 1GHz na 1.5GHz u prosjeku) i to je to... Znaci doslovno nista se ne desava...

Jeli itko probao koristiti RAMDisk za lokalni AI deployment tipa DeepSeek ili nes slicno?

Postavio sam upit onom drugom statistickom pogadjalu (DeepSeek, jel...) za sto bi se dalo koristiti RAMDisk kod lokalne instalacije i ovo mi je napisalo...


What DeepSeek Can Use the RAMDisk For

Model Cache:
- Store frequently accessed model weights (if using llama.cpp or similar).

Temporary File Storage:
- Store intermediate files (logs, tokenized inputs).

Swap for Small-Batch Inference:
- If your system has limited RAM, a RAMDisk can help avoid SSD thrashing.

Faster Disk-Based KV Caching:
- Some inference engines allow offloading cache to disk - use RAMDisk for speed.



Best for:
- Small models (e.g., deepseek-coder-1.3b in 4-bit) that fit entirely in RAMDisk.
- Frequent disk I/O tasks (like caching prompts).