SSD beställning

Intel 320 target markets: "Datacenter, Corp IT, OEM, Reseller, bVAR, System Integrator",

Intel 330 target markets: "E-Tail and Retail",

Intel 520 target markets: "E-Tail, Retail, Corp IT, OEM, Reseller, bVAR, System Integrator".

Sen är det inte många som bara skriver okomprimerbara 4kB-block med ködjup 32 hela dagarna, så Sweclockers tortyrtest är inte representativt för serveranvändning heller (och gör man det är nog 830 inte rätt ändå, den fick ju kritik för att den bara kör GC när den inte har något att göra).

Men visst ska man veta vad man håller på med, tror dock att många "företagsfiler" går bättre att komprimera än sånt folk har hemma (spel, musik, filmer).

Fast även när man låtit diskarna vila ett tag så kvarstod ju prestandaproblemen för intel, i och med att de kör sandforce. Tortyrtest eller ej så kommer ju rimligtvis samma sak att inträffa när man skrivit till disken ett antal gånger, bara det att det tar längre tid. Visserligen fixade secure erase saken, men hur ofta vill man köra secure erase på en SSD som t. ex sitter i en databasserver? Noterade även att 320 har "datacenter" med, vilket inte 520 har, men jag har för mig att 510 har det.

Fast det inträffar ju bara om man skriver över hela disken med slumpmäsisg 4kB okomprimerbar data och sen fortsätter skriva ännu mer okomprimerbar data, det är inget som någonsin kommer inträffa för de flesta (det händer definitivt inte om man har sitt OS på samma disk). Är det ett fall som kommer inträffa så behöver man ändå räkna och mäta på att lösningen kommer hålla, att då bara köra in en SSD och hoppas på det bästa kommer vara en riktigt dålig idé oavsett vilken kontroller SSDn har.

Sen hade det förstås varit bättre att det gick att skriva hela disken med okomprimerbar data utan prestandförluster, men det är inget jag kommer bli påverkad av i min användning.

Fast data skrivs jämt fördelat över hela disken, även "statisk" data flyttar på sig, det är det som är "wear leveling". Det finns inga "statiska" sektorer på en SSD. Så Sweclockers test stämmer väl överens med verkligheten, det är bara det att det tar lite längre tid att komma upp i det antalet "program erase cycles", men det kommer så småningom att hända.
Dessutom spelar det ingen som helst roll om det är okomprimerbar eller komprimerbar data som skrivs i längden, SSD'n slits bara långsammare om datan går att komprimera, eftersom mindre mängd data "faktiskt" skrivs, vilket sänker write amplification något.

Jag tycker i alla fall som många andra att det är tråkigt att det verkar som dem slutar med sina egna styrkretsar som sitter i 320 120 gb gick att fynda nyligen för 740kr

Intel har inte sagt att de slutar med egna styrkretsar eller ens att de slutar med 320-serien, men 320 kommer inte längre marknadsföras mot konsumenter. Sen så hade de inte så mycket val om de för tillfället vill vara relevanta i prestanda-segmentet. Gamla 510 var alldeles för dyr och hade vissa tveksamheter i prestandan.

Nja, du har missuppfattat, detta har inget med att SSDn slits, wear leveling eller erase cycles att göra. Skriver man komprimerbart data kommer det alltid finnas ledigt utrymme och då är det inget problem. Nästan ingen kommer drabbas av detta problem oavsett hur lång tid det går. Se t.ex.

http://www.anandtech.com/show/5508/i...to-sandforce/7

Wear leveling innefattar även "extra" utrymme och är anledningen till att en SSD som t. ex använder kretsar som är validerade för 3000P/E cykler kan skriva säg 4500 cykler innan minnena blir "read only". Det gäller även sandforce, men du har rätt i att det tar, i vissa fall, betydligt längre tid eftersom mindre data FAKTISKT skrivs om det är komprimerat. Men förr eller senare hamnar man där. Om det nu inte är så att Sandforce på något magiskt sett fysiskt bygger till minneskretsar på PCB'n "on the fly", och visst har tekniken kommit långt, men inte så långt.

Du påstod om Sweclockers tortyr-test att det "troligen mer simulerar tung användning i en server än ett typiskt "hemanvändarmönster", så tappar 520 hastighet" och att "Fast även när man låtit diskarna vila ett tag så kvarstod ju prestandaproblemen för intel, i och med att de kör sandforce". Men man gör exakt det test som beskrivs i Anandtech-artikeln om du nu läste den. Man tappar prestanda för att man skriver okomprimerbar data över hela disken upprepade gånger under längre tid utan att radera något eller att någon data går att komprimera.

Man tappar inte prestanda på det viset bara genom att använda disken på vanligt sätt. Detta har inget med antal P/E-cykler att göra, och som jag skrev redan i förra svaret, det står väldigt tydligt i Anandtech-artikeln, läs den nu! Men jag får väl kopiera in slutsatsen ändå: "Again, I don't see most end users backing themselves into this corner but it's worth pointing out.".

Man måste alltså "backa in ett hörn" på precis det sättet som beskrivs på Anandtech eller i Sweclockers-artikeln. Det är inte så att om datan går att komprimera 50% kommer samma sak att inträffa efter dubbelt så lång tid utan då kommer det inte inträffa alls.

När väl data har skrivits till ett block så kvittar det om datan är komprimerad eller inte, oavsett kontroler.
Jag har läst artikeln, men blir fortfarande inte klokare av vad du menar med att data som komprimeras innan den skrivs inte sänker prestandan. Att skriva 100MB okomprimerbar data är exakt samma sak som att skriva 200MB data som kan komprimeras till 50%, så vad är det som i så fall gör att komprimerad data inte sliter på disken, annat än det att det i "verkligheten" skrivs mindre data och därför inte sliter lika hårt? Jag får det inte att gå ihop.

Det har att göra med hur sandforce rensar tidigare använda block. Om pressar man disken genom att konstant skriva små okomprimerade block i maxfart och fylla disken med detta ett antal ggr så klarar inte disken längre av att återhämta sig. Har du ett mer normalt användningsmönster (som inte skriver 200+ gb små okomprimerade skrivningar på minsta möjliga tid) så klarar kontrollern av att hålla uppe prestandan oavsett hur mycket data du skriver totalt. Det är det som Anand medar när har skriver att man kan backa in disken i ett hörn. GC mm hinner helt enkelt inte med när man tortyrtestar disken och klarar inte heller av att återhämta prestandan när man väl hamnat där. Detta är som sagt inget problem för en normalanvändare då det bara åstadkoms med väldigt extrema användarmönster där man ändå bör använda en disk som är mer lämpad för serveraktivitet, tex en slc disk.

Kör på Corsairs Force GT serie och de fungerar hur bra som helst. Kör med 3x SSD diskar 2x 120gb och 1x 90gb för OS.

OS så väl som spel/program laddar snabbare, helt klart värt pengarna enligt min mening

Aha, OK, men då borde de göra om och göra rätt. Hela idén med TRIM är ju att man inte ska kunna köra disken i botten.

Men Sandforce har väl valt en annan affärsmodell generellt. Det är bra prestanda vid "normalanvändning" och tillräckligt stryktåliga minnen vid "normalanvändning", så som du säger så är det kanske inget problem för de flesta.