[ Ivan Dimkovic @ 12.12.2013. 20:58 ] @
Posto mi treba prilicno puno RAM memorije za mali kucni projekat razmisljao sam o jeftinijim alternativama.

Razlog je vrlo jednostavan - 1 TB RAM memorije je danas i dalje skupo, sa Xeon EP (Ivy Bridge EP) sistemom najjeftinije sto covek moze da prodje je 768 GB RAM-a preko 48 16 GB DIMM-ova, i to mu dodje ~6K EUR - preskupo za kucni projekat. Sve vise od toga ide u nebesa, zato sto su 32 GB RDIMM-ovi preskupi (1.5 TB bi izaslo ~25 hiljada EUR, sto je vec suludo).

Posto mogu da prihvatim usporenje - alternativa je da se napravi virtuelna memorija uz pomoc brzih SSD-ova.

I - zbog toga sam zapoceo mali projekat :)

Prva stvar koje sam se dokopao je Intel® RAID Controller RS25AB080.

Regularna cena ovog kontrolera je 700-800 EUR, ali sam uspeo da se dokopam istog za 1/5 cene preko nekog likvidatora firmi - otprilike izasao me je kao najjeftiniji SAS kontroler :-)

Sta pruza ovaj kontroler?

- PCIe 3.0 x8 (!) - dakle, do 8 GB/s protoka
- 1 GB DDR3 kesa
- 8x SAS i SATA III 6 Gb/s konektora (2x SFF8087)
- Baterijski backup

Evo kako kontroler izgleda:



Ideja je sledeca - na ovaj kontroler ustekati niz jeftinih SSD-ova (ne bas najjeftinijih, vec IOPS optimizovanih sa MLC flash-om - dakle ), i povezati sve to u jedan RAID0 niz.

Ocekujem da sa tim dobijem bar 3 GB/s protoka kada popunim sve SATA III konektore, a nadam se i preko toga (teoretski sa danasnjim SATA III SSD-ovima maksimum bi bio ~4.4 GB/s). Takodje, ocekujem i bar nekoliko stotina hiljada IOPS-ova.

Dodatna pogodnost je sto moj projekat moze da koristi 2 MB memorijske stranice umesto 4 KB, sto ce se lepo odraziti na I/O performanse.

Sve u svemu - cilj je da se dobije nesto sto je drasticno brze od HDD swap memorije, i mozda 100x sporije od RAM memorije. Nije idealno, ali je ukupna cena ovog kucnog projekta 6-16x jeftinija od RAM memorije. Stavise, nije nikakav problem ako treba kasnije male SSD-ove zameniti sa, recimo, 1 TB SSD-vima, sto moze drzati 8 TB za cenu koja je verovatno onda par stotina puta manja nego za 8 TB fizicke memorije i, jos bitnije, sistem koji bi mogao da primi 8 TB :-)

Sama arhitektura je interesantna: 128 GB RAM-a (8 DIMM-ova povezano na 2 Xeon procesora, sa 4 kanala po procesoru) ce biti korisceno kao jedan veliki kes (fizicka memorija), a 1-2 TB virtuelne memorije ce ici preko PCIe 3.0 x8 magistrale, 1 GB kesa na kontroleru - i, verovatno, bar 512 MB kesa po SSD-u, znaci 4 GB kesa kada popunim svih 8 SATA III konektora.

Sledeci korak su SSD-ovi - verovatno cu prvo uzeti 4 komada, da ispitam teren, pa cemo videti za dalje :)
[ ventura @ 12.12.2013. 21:06 ] @
Tu memoriju planiraš da koristiš direktno iz koda ili ćeš nešto 'elegantnije'?
[ the_tosic @ 12.12.2013. 21:10 ] @
A jel ce izdrzati to MLC diskovi, ipak ce biti premnogo upisa? I sta je bilo sa SLC diskovima
@Ventura zar ne bi trebalo samo page file da prebaci na tu djuntu? Mozda sam i lupio :)
[ ventura @ 12.12.2013. 21:21 ] @
Pa nemam pojma i meni je tako nešto palo na pamet.. Zato sam i napisao 'elegantnije' :)
[ Ivan Dimkovic @ 12.12.2013. 21:27 ] @
@ventura,

I Windows i Linux bez problema mapiraju swap kao virtuelni adresni prostor - tako da nije potrebno pisati rucno "swap" rutine. Jedina stvar na koju treba obratiti paznju je kada se alocira memorija, da se traze 2 MB stranice.

Pretpostavljam da je, mozda, moguce dobiti jos malo performansi pisanjem rucnog sistema za swap-ovanje - recimo, dodatak neke minimalne kompresije bi verovatno doneo jos dobitaka jer su sinapticki podaci pogodni za kompresiju... ali to mozda izvedem kasnije.

@the_tosic,

Pa izracunao sam da u principu za ono sto meni treba ovolika memorija, SLC je overkill. Neke velike eksperimente koji zahtevaju 1 TB ili 2 TB memorije cu i ovako i onako raditi jednom max dva puta mesecno i verovatno po nekoliko sekundi simulacije max, sto znaci mozda par stotina TB mesecno (iliti mozda 50-tak TB po disku) , dakle. Samsung 840 Pro od 128 GB (najmanji model) je uspesno izdrzao preko > 3 PiB upisa, tj. >3000 TB.

Tako da ocekujem da cela ta stvar radi bar nekoliko godina.

SLC bi verovatno trajao "zauvek" - ali na zalost, SuperSSpeed nudi samo 128 GB modele, sto max. virtuelnu memoriju limitira na 1 TB.

Videcu da odradim jos kalkulacija o procenjenim upisima, pa cemo videti kako to izgleda.
[ Ivan Dimkovic @ 12.12.2013. 21:36 ] @
Inace, nakacio sam neki matori Samsung 830 disk i poterao ATTO cisto da vidim koliko maksimalno moze kontroler da "izvuce" kada su podaci kesirani:

Maksimalno citanje izvlaci 2.8 GB/s (naravno, iz kesa):



Pretpostavljam da se to moze jos optimizovati uz pomoc drajvera i podesavanja kontrolera. Ali nije lose ni ovako :-)

[ the_tosic @ 12.12.2013. 21:48 ] @
Citat:
Tako da ocekujem da cela ta stvar radi bar nekoliko godina.

Pa onda je to ok. Ja sam krenuo pesimisticno sa prepisivanjem cele memorije x000 puta za jednu simulaciju, pa sam dosao do cifre od nedelju, dve igranja sa jednim kompletom diskova :).
[ Ivan Dimkovic @ 12.12.2013. 22:27 ] @
To je bilo tako ranije, dok su sve sinapse bile procesirane u svakom time-stepu.

Medjutim, od kada sam presao na tzv. "event-driven" update sinapsi, sinapsa biva "touched" samo kada do nje dodje AP (spajk).

U normalnim simulacijama prosecno ~1-2% neurona spajkuju u bilo kom momentu, sto znaci da se, grubo receno, apdejtuje par % memorije.

Hajde da kazemo i da je 2% - imamo sledecu racunicu:

1. Sve sinapse moraju biti inicijalizovane, dakle to je 1 TB upisa (ako imamo 1 TB virtuelne memorije)
2. U svakom vremenskom koraku se upise ~20 GB

Znaci za simulaciju od 10 sekundi imamo: 1 TB (inicijalizacija) + 10000 * 20 GB = ~ 200 TB

Tih 200 TB ce biti rasporedjeno na 8 diskova (kada popunim ceo RAID niz) - sto znaci 25 TB po disku.

Hajde da pomnozimo to i sa faktorom 4 zbog write-amplification efekata, burst-ova aktivnosti i sl... to je 100 TB po disku.

Najmanji Samsung 840 od 128 GB bi verovatno izdrzao 30-tak takvih simulacija, znaci 2.5 godine ako se rade 2 simulacije mesecno.

U principu, ja bih i ovako i onako radije uzimao 256 GB diskove - sto znaci da se vreme duplira, na oko 5 godina.

--

SLC bi tu drasticno promenio stvari - SLC diskovi dozvoljavaju 100 hiljada upisa po celiji, sto znaci da, recimo, SuperSSpeed disk od 120 GB verovatno moze da izdrzi preko 10 PB upisa, sto znaci da bi u ovom gore rezimu izdrzao bar 8 godina (vs. 2.5 za MLC disk) u najgorem slucaju, a verovatno i mnogo vise ako se uzme u obzir i inteligentan menadzment kontrolera. Takodje, ovo su grube cifre - 100 hiljada upisa je ono na sta je memorija testirana, a u realnosti sigurno moze da se postigne vise (SuperSSpeed koristi kvalitetan Intel NAND).




[ Ivan Dimkovic @ 12.12.2013. 22:50 ] @
Evo nekih interesantnih podataka:

- Samsung 840 Pro 128 GB (21 nm MLC NAND), izdrzao je 3 PB pre nego sto je otisao bogu na istinu: http://www.vojcik.net/samsung-ssd-840-endurance-destruct-test/ sto znaci kada bi podelili taj broj podataka sa velicinom diska, dolazimo do preko 20 hiljada P/E ciklusa po celiji. To samo govori o tome koliko je kvalitetan Samsung-ov NAND.

- Cak i Samsung-ov 21nm TLC NAND nije los (mada ne za mene, ali za desktop upotrebu je skroz OK): http://us.hardware.info/review...clusion-final-update-20-6-2013 - disk je izdrzao 3187 P/E ciklusa, tj. 764 TB, a zvanicno je rangiran na 1000 P/E ciklusa - opet, vidi se koliko je dobra Samsung-ova memorija

- Intel-ov 25-nm enterprise MLC (HET MLC) je na testu izdrzava 27.5 hiljada P/E ciklusa - interesantno, nije prakticno mnogo bolje od Samsung-ovog "obicnog" MLC-a, tj. Samsung bi verovatno izdrzao vise P/E ciklusa kada bi se particionisao tako da ima headroom kao Intel.

- Na linku iznad, imate i testove za Seagate 600 Pro koji je izdrzao 4879 P/E ciklusa - u pitanju je "obican" 19nm MLC

Na osnovu ovoga gore, pretpostavljam da bi Intel-ov 25nm SLC NAND koji se koristi u SuperSSpeed diskovima izdrzao bar 200 hiljada P/E ciklusa.

--

U principu, IMHO, jedine 2 kombinacije vredne pomena za mene (NAPOMENA - integritet podataka na duze staze mi nije bitan!):

- Samsung 840 Pro (21 nm Samsung MLC), koji ima stvarno fenomenalan endurance za consumer SSD - izdrzava preko 20 hiljada P/E ciklusa na testovima (!)

- SuperSSpeed SLC (25 nm Intel SLC), koji je verovatno 10-tak puta izdrzljiviji od Samsungovog 21nm MLC-a. Jedina mana je sto nemaju veci kapacitet od 128 GB

Sa Samsung-om se, u principu, dobija disk koji je verovatno izdrzljiviji od konkurentskih Enterprise MLC diskova, a i po pitanju performansi ne zaostaje. Takodje, cena je OK - daleko od toga da je to najjeftiniji MLC disk, ali je u odnosu na Enterprise diskove definitivno jeftin.

SuperSSpeed SLC, sa druge strane, daje neuporediv write-endurance - ali za to se placa cena malog kapaciteta (128 GB) i cene koja je ~2.5x veca od MLC diska istog kapaciteta
[ Ivan Dimkovic @ 12.12.2013. 23:28 ] @
Inace, kome treba jeftin SSD i moze da poruci iz UK - od ovog ne moze jeftinije:

http://geizhals.at/eu/ocz-vert...-oczssd3-2vtx480g-a550643.html

480 GB za 178 EUR (tj. 0.371 EUR po GB)

Naravno, u pitanju je OCZ - firma koja je bankrotirala i poznata po skrndelj hardveru. Mada, ako vam to nije bitno za 0.371 EUR po gigabajtu ne mozete proci jeftinije, sledeci najjeftiniji SSD je 0.439 EUR/GB. Doduse, limitiran je na SATA2, znaci 250/240 MB/s max sekvencijalni I/O, a i moze da izvuce samo 18000 random 4K write IOPS-a (interesantno, manje verzije istog SSD-a navodno mogu da izvuku 50000 random 4K write IOPS-a, verovatno zato sto koriste brzi 34nm NAND)

Ovaj model koristi IMFT (Intel/Micron) 25 nm MLC NAND, rangiran na 3000 P/E ciklusa.

Sve u svemu, ako vam treba jeftin SSD kao nekakav kes za podatke koji nisu kriticni tj. nije vam problem ako disk vrisne za koji mesec - ovo je vrlo jeftin disk.


--

@edit - mada sad nesto razmisljam, mozda SSD sa SandForce kontrolerima nisu losa ideja, posto ce ta sinapticka memorija biti laka za kompresiju...
[ Branimir Maksimovic @ 13.12.2013. 03:26 ] @
Preporucio bih ti Linux za ovu gimnastiku posto ima u kernelu (od 3.11) implementirano zswap,
koji je bash namenjen korisnicima koji hoce SSD da koriste za swap.

https://www.kernel.org/doc/Documentation/vm/zswap.txt
Some potential benefits:
* Desktop/laptop users with limited RAM capacities can mitigate the
performance impact of swapping.
* Overcommitted guests that share a common I/O resource can
dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
throttling by the hypervisor. This allows more work to get done with less
impact to the guest workload and guests sharing the I/O subsystem
* Users with SSDs as swap devices can extend the life of the device by
drastically reducing life-shortening writes.

Benchmarci:
https://www.ibm.com/developerw...ression_functionality7?lang=en

*Edit: Aplikaciju dok ne portujes mozes pokrenuti pod 64 bitnim wine-om
[ Tyler Durden @ 13.12.2013. 09:22 ] @
E sad si našao kome ćeš da predložiš linux :-(
[ Ivan Dimkovic @ 13.12.2013. 09:35 ] @
Sto da ne, ako radi posao - nemam problem sa tim.

@Branimir, hvala za ideju - probacu je definitivno. Moram da vidim kako se Wine ponasa ako pokusam da alociram large-page-size memoriju sa VirtualAllocEx() API-jem, tj. da li cu dobiti zaista memoriju sa npr. 2 MB stranicama ili ce Wine alocirati standardnu memoriju sa 4 KB stranicama.

Pretpostavljam da velicina stranica jos vise utice na performanse swap-a, posto su 2 MB I/O vidno brzi kada su SSD-ovi u pitanju.
[ Dexic @ 13.12.2013. 09:51 ] @
Ako stavis 8 SSD-ova u RAID0 (sto verovatno hoces? zbog sekvencijalnih performansi), imaces 2MB/8 po SSD-u za tako nesto, sto je 256KB, sto je manje od bloka SSD-a. Mislim da ces veci plus u performansama (i u izdrzljivosti) videti ako gledas da po SSD-u upises po blok, sto, ako se ne varam za Samsung 830 iznosi 512KB.

Za SSD je skoro nebitno da li se alocira 4KB ili 2MB stranica u memoriji, bitno je kako se swappuje - ako se uradi scatter-gather u velicini od 2MB (nebitno sto je to 4KB*512), imace iste performanse kao i sekvencijalni upis od 2MB (posto na SSD-u posle jednog prelaska nista vise nije sekvencijalno).
[ Ivan Dimkovic @ 13.12.2013. 11:14 ] @
Da u pravu si za RAID0 i 2MB/8...

Mada, izgleda koliko vidim cela stvar pada u vodu sa velikim stranicama, posto i Windows i Linux large/huge stranice tretiraju kao non-pageable.

U principu mogao bih da napravim neki svoj memory manager koji bi mogao da ima konfigurabilnu velicinu swap stranice + i kompresiju podataka i koristi SGIO za citanje/upis pa da se onda to istestira i podesi da bude najbrze za odredjenu SSD RAID konfiguraciju. Ali mi se ne mili da pisem to sad, posto bi to sigurno zahtevalo bar nekoliko dana posla da se "zapne".

Tako da za sada ostaje da probam zswap koji je Branimir predlozio.
[ Dexic @ 13.12.2013. 11:33 ] @
Ako SSDovi mogu da upisu 2GB/s (vise od toga ne znam da li stvarno moze taj kontroler, barem ne odrzivo), tebi treba kompresija koja bi smanjila te podatke recimo na pola, a da radi 4GB/s (mora preci 2GB/s inace gubis, ma koliko dobro kompresovalo). Ako ih kompresuje na 10%, onda treba oko 2.22GB/s da ima brzinu kompresije.

Imas algoritam koji moze toliko brzo da kompresuje??
[ Aleksandar Đokić @ 13.12.2013. 11:34 ] @
Super ideja, ja sam razmisljao o swap-u na velikom flashu na USB3.
[ Ivan Dimkovic @ 13.12.2013. 11:54 ] @
Citat:
Dexic:
Ako SSDovi mogu da upisu 2GB/s (vise od toga ne znam da li stvarno moze taj kontroler, barem ne odrzivo), tebi treba kompresija koja bi smanjila te podatke recimo na pola, a da radi 4GB/s (mora preci 2GB/s inace gubis, ma koliko dobro kompresovalo). Ako ih kompresuje na 10%, onda treba oko 2.22GB/s da ima brzinu kompresije.

Imas algoritam koji moze toliko brzo da kompresuje??


Evo nekih kandidata - Google Snappy je najbrzi, ali kao sto se vidi - i to je i dalje dosta resursa:

http://encode.ru/threads/1266-...S-(QuickLZ-Snappy)-compressors

Single-core Xeon X5355:

Code:

benchmark 0.1 (c) Dell Inc.  Written by P.Skibinski
memcpy           = 97 ms (1055 MB/s), 104854004 -> 104854004
fastlz 0.1 -1    = 545 ms (187 MB/s), 104854004 -> 45614322, 308 ms (332 MB/s)
fastlz 0.1 -2    = 557 ms (183 MB/s), 104854004 -> 43986331, 249 ms (411 MB/s)
lzf 3.6 vf       = 502 ms (203 MB/s), 104854004 -> 44890314, 229 ms (447 MB/s)
lzf 3.6 uf       = 495 ms (206 MB/s), 104854004 -> 47089435, 233 ms (439 MB/s)
lzjb 2010        = 600 ms (170 MB/s), 104854004 -> 52693883, 315 ms (325 MB/s)
lzo 2.04 1x      = 774 ms (132 MB/s), 104854004 -> 42726420, 217 ms (471 MB/s)
lzrw1            = 596 ms (171 MB/s), 104854004 -> 51296084, 379 ms (270 MB/s)
lzrw1-a          = 546 ms (187 MB/s), 104854004 -> 50630870, 302 ms (339 MB/s)
lzrw2            = 491 ms (208 MB/s), 104854004 -> 47950899, 295 ms (347 MB/s)
lzrw3            = 535 ms (191 MB/s), 104854004 -> 46384103, 351 ms (291 MB/s)
snappy 1.0       = 303 ms (337 MB/s), 104854004 -> 46155676, 186 ms (550 MB/s)
tornado 0.666 -1 = 540 ms (189 MB/s), 104854004 -> 47432525, 406 ms (252 MB/s)
tornado 0.666 -2 = 674 ms (151 MB/s), 104854004 -> 40500470, 464 ms (220 MB/s)
quicklz 1.5.0 -2 = 880 ms (116 MB/s), 104854004 -> 38965498, 479 ms (213 MB/s)
quicklz 1.5.0 -1 = 383 ms (267 MB/s), 104854004 -> 42816655, 410 ms (249 MB/s)
quicklz 1.5.1 -1 = 371 ms (276 MB/s), 104854004 -> 42816655, 418 ms (244 MB/s)
all              = 17871 ms


Teorijski, ako pretpostavim da Snappy radi 20% brze na IvyTown arhitekturi, to je i dalje 660/404 MB/s po jednom jezgru.

Znaci morao bih da mu dam bar 5-6 jezgara samo da Snappy trci na njima.

Nisam siguran da ce to leteti... problem je sto je potrebno suvise cimanja da bi se samo to moglo istestirati :(
[ Ivan Dimkovic @ 13.12.2013. 12:09 ] @
Gledajuci ove benchmarke, mislim da to sa CPU kompresijom tesko moze da zasiti PCIe x8 kontroler sa 8 RAID SSD-ova koji mogu verovatno da izdrze 500 MB/s sekvencijalnog upisa svaki, sve i da uzmemo 2 GB/s kao maksimalni prakticni throughput.

Potrazicu na netu da li postoji nesto jos brze od te Google Snappy kompresije, mada sumnjam - pre nekoliko meseci sam gledao sta postoji posto mi je trebala brza lossless kompresija za kompresiju spike-ova iz neurona.

Alternativa je da se napravi neka kompresija specificna za podatke koja bi onda bila jos brza od Snappy-ja (tako sto bi se iskoristilo a priorno znanje o podacima), ali to sve postaje onda suvise veliki cim za malo dobitka. Tu je, takodje, steta sto IvyBridge EP nema integer AVX instrukcije.

Ako se gadja kompresija, mislim da je onda bolje resenje SSD sa SandForce kontrolerom, koji radi hardversku "on the fly" kompresiju.

E, sad, koliko vidim Samsung SSD 840 Pro ubija sve te SandForce diskove (naravno pricamo o diskovima sa MLC NAND-om) - mada, moze da se desi da je test materijal takav da kompresija nije velika. Videcu da iskopam neki SSD sa SF kontrolerom pa da isprobam I/O sa visoko-kompresibilnim podacima.
[ Dexic @ 13.12.2013. 12:17 ] @
memcpy koji daje samo 1GB/s???? To je Xeon iz doba Core 2 Quad procesora.

SF SSD kompresija, barem za probu, je sigurno bolja ideja ;)
[ Ivan Dimkovic @ 13.12.2013. 13:19 ] @
Nope to je Nehalem/Westmere generacija, sa sve QPIjem.

Neces puno vise dobiti ni na najnovijim procesorima sa memcpy-jem, ako hoces da zasitis memoriju moras imati vise niti i, eventualno, koristiti AVX na novim procesorima.
[ Dexic @ 13.12.2013. 13:25 ] @
Kakav Nehalem??

http://ark.intel.com/Products/Spec/sl9ym
Launch Date Q4'06
[ Ivan Dimkovic @ 13.12.2013. 13:31 ] @
Sorry pogresan benchmark mislim da sam video nege drugi sa nehalemom.

Ali u svakom slucaju neces dobiti puno vece rezultate ni na IvyBridge-u zato sto memcpy u jednom threadu ne moze da zasiti memorijski kontroler. Probaj uostalom pa ces videti da dobijas par GB/s iako memorija moze da servisira mnogo vise.
[ Zlatni_bg @ 13.12.2013. 17:19 ] @
Je l' moze da se zna cemu sluzi tih ~1TB swapa? :)
[ Branimir Maksimovic @ 13.12.2013. 18:16 ] @
Citat:
Ivan Dimkovic:
Gledajuci ove benchmarke, mislim da to sa CPU kompresijom tesko moze da zasiti PCIe x8 kontroler sa 8 RAID SSD-ova koji mogu verovatno da izdrze 500 MB/s sekvencijalnog upisa svaki, sve i da uzmemo 2 GB/s kao maksimalni prakticni throughput.


Nemoj da brines. SSD ne moze da pise sekvencijalno brze od SATAIII diska. Tajna je naprosto u ogromnom write-back cache-u
koji SSD-ovi imaju. Cim se cache prepuni brzina pada i do 40-80mb/s.
Prednost SSD-a nad HDD-om je zato sto u random read/write-u HDD brzina pada na oko 4mb/s.
Prednost zswap-a je u tome sto cachira write-ove pa u zavisnosti od kompresije write mozda nikad
ni ne stigne do diska, te sama kompresija omogucava da se daleko manje podataka snimi
na disk sto povecava brzinu i zivotni vek SSD-a.
[ Dexic @ 13.12.2013. 20:15 ] @
Citat:
Branimir Maksimovic: Nemoj da brines. SSD ne moze da pise sekvencijalno brze od SATAIII diska. Tajna je naprosto u ogromnom write-back cache-u
koji SSD-ovi imaju. Cim se cache prepuni brzina pada i do 40-80mb/s.

Ne.
[ Ivan Dimkovic @ 13.12.2013. 21:22 ] @
Citat:
Branimir Maksimovic:
Citat:
Ivan Dimkovic:
Gledajuci ove benchmarke, mislim da to sa CPU kompresijom tesko moze da zasiti PCIe x8 kontroler sa 8 RAID SSD-ova koji mogu verovatno da izdrze 500 MB/s sekvencijalnog upisa svaki, sve i da uzmemo 2 GB/s kao maksimalni prakticni throughput.


Nemoj da brines. SSD ne moze da pise sekvencijalno brze od SATAIII diska. Tajna je naprosto u ogromnom write-back cache-u
koji SSD-ovi imaju. Cim se cache prepuni brzina pada i do 40-80mb/s.
Prednost SSD-a nad HDD-om je zato sto u random read/write-u HDD brzina pada na oko 4mb/s.
Prednost zswap-a je u tome sto cachira write-ove pa u zavisnosti od kompresije write mozda nikad
ni ne stigne do diska, te sama kompresija omogucava da se daleko manje podataka snimi
na disk sto povecava brzinu i zivotni vek SSD-a.


Kao sto Dexic vec pomenu, ovo definitivno nije slucaj danas sa bilo kojim iole kvalitetnim SSD-om.

Brzina od 500+ MB/s se postize ne write-back kesom, vec multi-kanalnim interfejsom ka NAND memoriji.

[ Branimir Maksimovic @ 13.12.2013. 21:39 ] @
Hm, pogledaj onda ovo:
http://ssdendurancetest.com/
http://techreport.com/review/2...durance-experiment-22tb-update

Kako god, mislim da cache igra veliku ulogu tu.

Po ovim testovima, sustained brzina citanja/pisanja nije bas impresivna ;)

[ Dexic @ 13.12.2013. 22:25 ] @
Mislim da nijedan SSD nema write-back cache uopste. Imaju cache - koji koriste za svoje interne podatke, ali ne i za podatke koji se upisuju na celije.

Kazem mislim, jer odavno nisam gledao specifikacije SSDova, u doba 50nm i 34nm NANDova nije postojao write cache uopste.


Ne vidim sta zelis reci iz linka, vecina SSDova gazi preko 200MB/s, ne 40-80MB/s, i to nakon nekoliko dana rada?
[ Branimir Maksimovic @ 17.12.2013. 03:55 ] @
Prilicno sam siguran da imaju write cache. Ovi samsung EVO sigurno jer im je write brzina ocajna kada se
popuni cache.

Ne znam gde si video da vecina gazi preko 200mb/s:

Samsung EVO:
Average speed Last two reported
Read Speed 132 MB/s 82 MB/s 92 MB/s
Write Speed 23 MB/s 25 MB/s 19 MB/s

Intel SSD:
Average speed Last two reported
Read Speed 68 MB/s 135 MB/s 133 MB/s
Write Speed 73 MB/s 65 MB/s 94 MB/s

sandisk:
Average speed Last two reported
Read Speed 121 MB/s 89 MB/s 95 MB/s
Write Speed 51 MB/s 49 MB/s 40 MB/s

Kingston:
Average speed Last two reported
Read Speed 228 MB/s 385 MB/s 135 MB/s
Write Speed 104 MB/s 1 MB/s 5 MB/s
[ Dexic @ 17.12.2013. 11:06 ] @
Brkas :) Samsung koji si pomenuo koristi softverski cache, preko svog softvera. Sam SSD fizicki nema cache.

Nadji negde da SSD ima write cache. Mozda ima poneki, ali mislim skoro svi nemaju. Dok je bilo doba prvih koristljivih SSD-ova, znam da sam citao da Intel ima 64-256MB memorije, ali nista od toga nije za write cache. A odlicne brzine je imao.


Odakle tebi i koje su ovo brzine? Mislim da si pomesao previse. Bez problema SSDovi mogu da izvuku stalnih 500MB/s danas.
Nemam takve SSDove ali imam one koje izvlace >200MB/s upis stalno.
[ Branimir Maksimovic @ 25.12.2013. 01:53 ] @
Pa pazi, sad je norm da SSD-ovi kompresuju zapis koliko chitam. SandForce based SSD-ovi zasigurno
imaju write cache. Gde bi inache kompresovali pre upisa? ;)

Brzine ti pishu na sajtu http://ssdendurancetest.com/ i to su prosechne brzine dotichnih
SSD-ova pod konstantim read/write-om.
[ Dexic @ 25.12.2013. 07:47 ] @
SF ima neki RAM u kome kompresuje, ali od kud tebi ideja da je taj RAM preko (reda) 64KB (da KILObajta, ne megabajta) ili 1MB max.? Nece sigurno kompresovati 64MB u 64KB, takav algoritam im ne bi dao prihvatljive brzine.

To u svakom slucaju nije write cache - write cache bi vratio "OK", pre nego sto upise nesto na NAND celije - a "cache" tj. RAM koji SandForce uredjaji koriste nije to, vec je sami intermediate memorija.

(primeti da ne tvrdim da nemaju write cache, ali ovo sto si pomenuo nije write cache)


Za brzine vec si nasao pogresan izvor. Imam matori SSD trenutno, i on bez problema odrzava 200MB/s pri upisu nekolicine GB odjednom.
Sajt koji si naveo ima 4 SSD-a ukupno, nije merodavan.
[ Ivan Dimkovic @ 07.03.2014. 16:00 ] @
Izgleda konfiguracija nije bila optimalna - evo rezultata sa matorim 256 GB SSD diskom od Samsung-a (MLC, prve generacije) bez ikakvog RAID-a:



Dakle, maksimalni I/O koji kontroler moze da postigne je 3.4 GB/s citanje, ~3 GB/s pisanje.

Porucicu 4 SSD-a za vikend, tako da cu popuniti prvu granu, a onda jos 4 ako sve bude islo kako treba :)