EEPROM wear, skall man oroa sig?

[Oortone]

När jag läste om minneshanteringen firmware till Nava stötte jag på något jag inte kände till:

I think Vincent decided to use a Save button because the TR909 uses static RAM to store patterns while the Nava uses an EEPROM to store patterns. EEPROM has a limit to the amount of times it can be rewritten.

Men hur många gånger klarar ett EEPROM att skrivas över?

The write endurance of EEPROM is typically specified by the manufacturer and is often expressed in terms of "cycles" or "bits." For example, a manufacturer might specify a write endurance of 100,000 cycles, which means the EEPROM can be reliably written to and erased up to 100,000 times before it starts to degrade.

https://en.giantec-semi.com/blog/how...ing-the-limits

Databladet till det EEPROM som sitter i Nava anger däremot 1 miljon cykler. Fast jag hittar inget datablad till exakt det som sitter i (AT24CP, det är 'P' som jag inte hittar i något datablad)...

Antag att man klickar [ENTER] 100 ggr per dag när man har kul. Det blir 1000 eller 10 000 dagar tills det går sönder. I ena fallet 3 års kontinuerlig Navaprogrammering i andra 30. Det lägre värdet tycker jag känns på marginalen (vissa dagar kanske man trycker mycket mer än 100 ggr) så...

Man kanske borde ha lite reserv EE-PROM till maskiner som på detta sätt skriver till EEPROM ofta? Men jag undrar hur pass vanligt det är med den lösning som sitter i Nava? Det verkar rätt ogenomtänkt så det kanske mest är i DIY-maskiner? Hur är det med x0xb0x t.ex? Det är ju likartade system.

Någon som varit med om när EEPROM lägger av?

[ricard]

E-Mu:s Command Stations (XL-7, MP-7, PX-7) har samma problem. De har visserligen inte EEPROM utan Flashminne som är en i princip likadan teknologi.

Det var någon PC-editor som så fort man gjorde någon parameterändring skrev ner programmet i minnet, vilket efter ett tag slet ut minnena.

Det som händer efter det antal cykler som tillverkaren har specat är att de inte kan garantera sina specar, t ex att det som skrivits skall hålla i 10 år eller vad som nu står i databladet. Så när man går över det specade antalet skrivningar så märks det till en början inte alls, utan det är ett utnötningsfenomen.

Jag har förstört ett flashminne genom att med vilje skriva miljontals gånger, när det var specat för mycket mindre. Det som hände var att förmågan att lagra data blev nedsatt, dvs om man skrev något och läste det tillbaka efter några sekunder så hade det förändrats. Det var inte så att det gick sönder helt.

I stort sett alla moderna instrument sparar data på motsvarande sätt, inkluderande SSD-drivar till datorer och USB-minnen. Man kan till viss del lösa problemet genom att med operativsystemets hjälp inte alltid skriva data på samma ställe i minnet ("wear levelling"). Men det är upp till tillverkaren hur effektivt det är gjort.

[Oortone]

This quote is hidden because you are ignoring this member.

E-Mu:s Command Stations (XL-7, MP-7, PX-7) har samma problem. De har visserligen inte EEPROM utan Flashminne som är en i princip likadan teknologi.

Det var någon PC-editor som så fort man gjorde någon parameterändring skrev ner programmet i minnet, vilket efter ett tag slet ut minnena.

Det som händer efter det antal cykler som tillverkaren har specat är att de inte kan garantera sina specar, t ex att det som skrivits skall hålla i 10 år eller vad som nu står i databladet. Så när man går över det specade antalet skrivningar så märks det till en början inte alls, utan det är ett utnötningsfenomen.

Jag har förstört ett flashminne genom att med vilje skriva miljontals gånger, när det var specat för mycket mindre. Det som hände var att förmågan att lagra data blev nedsatt, dvs om man skrev något och läste det tillbaka efter några sekunder så hade det förändrats. Det var inte så att det gick sönder helt.

I stort sett alla moderna instrument sparar data på motsvarande sätt, inkluderande SSD-drivar till datorer och USB-minnen. Man kan till viss del lösa problemet genom att med operativsystemets hjälp inte alltid skriva data på samma ställe i minnet ("wear levelling"). Men det är upp till tillverkaren hur effektivt det är gjort.

Mycket intressant.

När det gäller hur det är gjort i Nava så är marginalerna rätt ok och det är ju ingen superkatastrof om det skulle börja strula. Men SSD-diskar... Det kände jag inte till. Det betyder att de är rätt olämpliga som "scratchdisks" alltså? Däremot säkra för långtidslagring om man skriver ett fåtal gånger, typ backup då och då? Men med tanke på hur mycket man skriver till inbyggd disk på en dator måste väl en SSD hålla för mycket mer än en miljon gånger eller? Funderar på om man kan se antal skrivcykler i någon slags statistiklogg. Man kan såklart inte se antalet skrivningar till en specifik adress men någon slags genomsnitt vore ju bra att se.

[SPX]

This quote is hidden because you are ignoring this member.

Mycket intressant.

När det gäller hur det är gjort i Nava så är marginalerna rätt ok och det är ju ingen superkatastrof om det skulle börja strula. Men SSD-diskar... Det kände jag inte till. Det betyder att de är rätt olämpliga som "scratchdisks" alltså? Däremot säkra för långtidslagring om man skriver ett fåtal gånger, typ backup då och då? Men med tanke på hur mycket man skriver till inbyggd disk på en dator måste väl en SSD hålla för mycket mer än en miljon gånger eller? Funderar på om man kan se antal skrivcykler i någon slags statistiklogg. Man kan såklart inte se antalet skrivningar till en specifik adress men någon slags genomsnitt vore ju bra att se.

I praktiken är det bara ett problem om du köper billiga kinesiska piratkopior från Amazon. Bra diskar och moderna operativsystem hanterar detta.

[Oortone]

This quote is hidden because you are ignoring this member.

I praktiken är det bara ett problem om du köper billiga kinesiska piratkopior från Amazon. Bra diskar och moderna operativsystem hanterar detta.

Låter lite för tvärsäkert. Hur vet du säkert att du inte får problem i framtiden med viktiga backuper? Själv har jag varit med om strul med rullband, strul med datband (mycket stort problem på mitt jobb för ca. 15 år sedan), brända cd-backuper och strul med skvibaserade hårddiskar där både själva skivan havererat som att annat av mer oklar art (komponenter inuti?) gjort datat oåtkomligt för en normal användare.

Att döma av vad ricard sett i sina tester verkar det rimligt att anta att inte heller denna omgång teknik är riktigt att lita på.

[slirak]

Det går bara att skriva till NAND-cellerna, som lagrar datat på en SSD, ett visst antal gånger. Så SSD:er har definitivt en begränsad livslängd. Men det delar de ju med mekaniska diskar.

Jag försökte Googla en stund, men det visar sig svårt att få fram bra fakta. Väldigt många hänvisar till en och samma studie som visade att SSD:er är tillförlitligare än mekaniska diskar, men den var gjord i ett specifikt användningsfall och jämförde dessutom diskar designade för datacenter och såna har vi ju sällan hemma.

Men det måste finnas åtskilliga miljoner laptops därute, som bara har SSD som lagringsmedia och den massdöd som en del befarade när SSD:er började bli poppis verkar ha uteblivit.

Min förra jobb-Mac, som bara har SSD, använde jag i sju (!) år och jag drog just igång den för att kolla diskstatusen med ett analysverktyg, DriveDX.

DriveX rapporterar bl.a. att disken startats upp nästan 68.000 gånger och att jag skrivit totalt 26 TB till den (det är en 250 GB-disk). Rapporten hittar inga problem och disken har 79% kvar av sin "wear leveling count". Wear leveling ser till att sprida skrivandet jämnt över alla NAND-cellerna och är en nyckelfaktor för att hålla en SSD vid liv.

Jag har alltså skrivit över hela disken mer än 1000 gånger och än verkar den ha mycket liv kvar i sig. Det förekommer olika typer av SSD:er, med olika hållbarhet: MLC (håller för c:a 10.000 fullständiga överskrivningar), TLC (c:a 3.000) och QLC (c:a 1.000). Eftersom den här SSD:n passerat 1.000 med viss marginal och rapporteras ha max hälsa och 79% wear leveling kvar, så säger väl matten att den snarare är rankad för runt 5.000 överskrivningar. 3.000, 5.000 eller 10.000 - alla alternativen torde räcka långt för de allra flesta användningsfall.

Alltså: vid "normalt" bruk så behöver man knappast vara särskilt orolig de första 5-10 åren, om man inte snikat och köpt en QLC-disk. Med det sagt så är ju alla såna här siffror bara medeltal, så man ska kanske inte vänta med med att ta första backupen till år fem.

[SPX]

Fast disken räknar ju själv hur många skrivningar den har kvar och stänger ner sektorer för skrivning över den specade gränsen. Så risken att förlora data på det här sättet är ju fortfarande liten. Samma regler som alltid gällt gäller fortfarande: Är datan viktig för dig, använd säkra backups. Och köp aldrig diskar av skumma märken eller skumma säljare. Under inga förhållanden är det lönt att oroa sig för att "skriva sönder" disken.

[slirak]

Ja, den håller koll, så förhoppningsvis blir man varnad i tid. Men livslängden är fortfarande begränsad. Dock, som mitt exempel ovan visar, så krävs det en hel del för att nå den gränsen om man inte köper QLC-diskar och skriver data som en tokig. Och tokskrivande kan döda mekaniska diskar också.

För att återgå till frågan om EEPROM, så kan man ju tycka att vafanken, kan de klara 1.000.000 skrivningar?! Det är ju mycket bättre än SDD? Nja. För en SSD kan radera och skriva över enstaka block (ofta 512 KB), men en EEPROM måste radera och skriva över rubbet, varje gång, hur lite man än sparar. Men om NAVA fixar 1 miljon gånger, så är det nog inte osannolikt att nåt annat i burken pajar långt innan EEPROM:et.

[Oortone]

This quote is hidden because you are ignoring this member.

Ja, den håller koll, så förhoppningsvis blir man varnad i tid. Men livslängden är fortfarande begränsad. Dock, som mitt exempel ovan visar, så krävs det en hel del för att nå den gränsen om man inte köper QLC-diskar och skriver data som en tokig. Och tokskrivande kan döda mekaniska diskar också.

För att återgå till frågan om EEPROM, så kan man ju tycka att vafanken, kan de klara 1.000.000 skrivningar?! Det är ju mycket bättre än SDD? Nja. För en SSD kan radera och skriva över enstaka block (ofta 512 KB), men en EEPROM måste radera och skriva över rubbet, varje gång, hur lite man än sparar. Men om NAVA fixar 1 miljon gånger, så är det nog inte osannolikt att nåt annat i burken pajar långt innan EEPROM:et.

Är du säker på att den måste skriva över hela minnet varje gång? jag har tittat på firmwarekoden lite i Nava och det ser inte ut som anropen är på allt varje gång, men själva detajerna kring minnehanteringen är inte av en typ som jag är bra på att förstå.

Det som jag tycker är lurigt med just SSD jämfört med hårddiskkrash är att det inte garanterat kommer märkas, mer förrädiskt. Min dator har SSD och har använts flitigt i 7 år nu. Jag har faktiskt varit med om två konstiga filproblem. Vem vet? Det är nog dags att byta maskin snart...

[slirak]

This quote is hidden because you are ignoring this member.

Är du säker på att den måste skriva över hela minnet varje gång? jag har tittat på firmwarekoden lite i Nava och det ser inte ut som anropen är på allt varje gång, men själva detajerna kring minnehanteringen är inte av en typ som jag är bra på att förstå.

Det som jag tycker är lurigt med just SSD jämfört med hårddiskkrash är att det inte garanterat kommer märkas, mer förrädiskt. Min dator har SSD och har använts flitigt i 7 år nu. Jag har faktiskt varit med om två konstiga filproblem. Vem vet? Det är nog dags att byta maskin snart...

Jag var långt ute i dikesrenen och cyklade där! Tänkte ju på EPROM. Man kan radera valda delar av EEPROM. Vore rätt vansinnigt att använda EEPROM för annat än typ firmware annars.

Men jag vet inte om jag håller med om att en SSD:s död är så mycket mer förrädisk än en mekanisk disk. Den håller som sagt reda på antalet gjorda överskrivningar och stöder liksom mekaniska diskar S.M.A.R.T. Sen är det förstås upp till operativet om det larmar när statusen börjar rapportera problem. Jag vet faktiskt inte hur det ligger till med det, vare sig med Windows eller macOS.

Jag har haft fem eller sex mekaniska diskar som dött och i inget fall fick jag nån förvarning från OS:et. När raset kom så gick det fort och bara i ett fall lyckades jag rädda nån data alls och det var inte mycket.

Det finns åtminstone tredjepartsverktyg som kan monitorera och larma om det t.ex. börja dyka upp läs- eller skrivfel, eller om man närmar sig gränsen för antalet överskrivningar, så det kan nog vara läge att skaffa ett sånt när man har en disk med några år på nacken.

[Oortone]

This quote is hidden because you are ignoring this member.

Jag var långt ute i dikesrenen och cyklade där! Tänkte ju på EPROM. Man kan radera valda delar av EEPROM. Vore rätt vansinnigt att använda EEPROM för annat än typ firmware annars.

Men jag vet inte om jag håller med om att en SSD:s död är så mycket mer förrädisk än en mekanisk disk. Den håller som sagt reda på antalet gjorda överskrivningar och stöder liksom mekaniska diskar S.M.A.R.T. Sen är det förstås upp till operativet om det larmar när statusen börjar rapportera problem. Jag vet faktiskt inte hur det ligger till med det, vare sig med Windows eller macOS.

Jag har haft fem eller sex mekaniska diskar som dött och i inget fall fick jag nån förvarning från OS:et. När raset kom så gick det fort och bara i ett fall lyckades jag rädda nån data alls och det var inte mycket.

Det finns åtminstone tredjepartsverktyg som kan monitorera och larma om det t.ex. börja dyka upp läs- eller skrivfel, eller om man närmar sig gränsen för antalet överskrivningar, så det kan nog vara läge att skaffa ett sånt när man har en disk med några år på nacken.

Nä, på sätt och vis har du nog rätt. Det kanske är lite fobi, känns mer creepy med ett hus som möglar långsamt utan att det syns än en rejäl eldsvåda, men eldsvådan är nog värre trots allt.

[oljud]

Ni får börja använda FERAM-teknik. Datan fina kvar i något hundratal år och de ska klara uppemot 10^15 skrivningar

[johey]

SRAM med batteri är väl det mest slitstarka. Med nackdelen att, batteri…

[slirak]

This quote is hidden because you are ignoring this member.

Ni får börja använda FERAM-teknik. Datan fina kvar i något hundratal år och de ska klara uppemot 10^15 skrivningar

Om jag (eller snarare miniräknaren) räknar rätt, så torde man kunna skriva en gång i sekunden i knappt 32 miljoner år, så även om det också är något begränsat, så känns det väl ganska OK.

[oljud]

This quote is hidden because you are ignoring this member.

Om jag (eller snarare miniräknaren) räknar rätt, så torde man kunna skriva en gång i sekunden i knappt 32 miljoner år, så även om det också är något begränsat, så känns det väl ganska OK.

En grej är att den måste skriva över varje gång man läser, läsningen är destruktiv. Men ja, håller ändå ett tag!

[Oortone]

This quote is hidden because you are ignoring this member.

SRAM med batteri är väl det mest slitstarka. Med nackdelen att, batteri…

Jag halkade in på detta eftersom jag tittade lite på hur minneshanteringen i Nava funkar och det som faktiskt fascinerar mig mest av allt, nu när jag fått lite grepp om det, är att gammal RAM-teknik med batteri egentligen är mycket bättre än den tämligen idiotiska metodiken med EEprom som t.ex. Nava använder. Detta eftersom minnesaccesserna tar för lång tid för att funka optimalt ihop med en springande trummaskin. Det tar längre än en 16-delsnot i 120 bpm och ställer därmed till knepiga logikproblem vid patternbyten. Ibland vinner gammal teknik över ny.

This quote is hidden because you are ignoring this member.

Om jag (eller snarare miniräknaren) räknar rätt, så torde man kunna skriva en gång i sekunden i knappt 32 miljoner år, så även om det också är något begränsat, så känns det väl ganska OK.

Jamen då så. Där var lösningen. Jag byter omgående.

[SPX]

This quote is hidden because you are ignoring this member.

SRAM med batteri är väl det mest slitstarka. Med nackdelen att, batteri…

Kostnaden per byte blir ju svinhög också. Men gör inget för ett patch-minne eller liknande.

[Oortone]

This quote is hidden because you are ignoring this member.

Ni får börja använda FERAM-teknik. Datan fina kvar i något hundratal år och de ska klara uppemot 10^15 skrivningar

Fascinerande hur ofta saker är uppfunna för evigheter sedan:

Ferroelectric RAM was proposed by MIT graduate student Dudley Allen Buck in his master's thesis, Ferroelectrics for Digital Information Storage and Switching, published in 1952.

https://en.wikipedia.org/wiki/Ferroelectric_RAM

[Oortone]

This quote is hidden because you are ignoring this member.

Kostnaden per byte blir ju svinhög också. Men gör inget för ett patch-minne eller liknande.

I en enklare maskin som en 909-kopia kunde man ju tänka sig ett RAM som läser in alla patterns och tracks från EEprom när man slår på. Mitt överslag ger att det upptar max. 100 kb. Sedan skriver man enbart till EEprom vid fåtal tillfällen, t.ex. då man trycker stop. Den sniklösning som Nava använder är rätt korkad och ställer till det med sina ständiga långsamma minnesaccesser. Man blir lite nyfiken på hur de gör i kommersiella maskiner av det här slaget numera.

[oljud]

This quote is hidden because you are ignoring this member.

Fascinerande hur ofta saker är uppfunna för evigheter sedan:

https://en.wikipedia.org/wiki/Ferroelectric_RAM

Oj jisses, 1952. Starkt jobbat ändå.

[buffo]

This quote is hidden because you are ignoring this member.

Jag halkade in på detta eftersom jag tittade lite på hur minneshanteringen i Nava funkar och det som faktiskt fascinerar mig mest av allt, nu när jag fått lite grepp om det, är att gammal RAM-teknik med batteri egentligen är mycket bättre än den tämligen idiotiska metodiken med EEprom som t.ex. Nava använder. Detta eftersom minnesaccesserna tar för lång tid för att funka optimalt ihop med en springande trummaskin. Det tar längre än en 16-delsnot i 120 bpm och ställer därmed till knepiga logikproblem vid patternbyten. Ibland vinner gammal teknik över ny.

Ouch.. Tar det alldeles för lång tid eller bara lite? Tittade snabbt på koden och funderar på om det vore intressant att öka i2c-hastigheten från 100khz till 400khz som ett test. Både eeprom:et och atmegan verkar åtminstone stödja detta på papperet. Sorry OT

[knarr]

Ett NOR flash med SPI interface är väl det bästa designvalet? (om det är möjligt) Förhållandevis gott om plats, hyffsad hastighet och tillförlitligt.

[Oortone]

This quote is hidden because you are ignoring this member.

Ouch.. Tar det alldeles för lång tid eller bara lite? Tittade snabbt på koden och funderar på om det vore intressant att öka i2c-hastigheten från 100khz till 400khz som ett test. Både eeprom:et och atmegan verkar åtminstone stödja detta på papperet. Sorry OT

Inte superofftopic: Hur gör man det?
Om jag begriper hur systemet funkar i övrigt med interruptklocka för sequencern så förstör ju inte de långsamma accesserna timingen i sequencern (inget tyder på det, ingen hicka vi accesserna) utan det är bara logiken som blir onödigt krånglig om man vill ha liveprogrammering med snabba taktbyten/kedjor av takter.

[buffo]

This quote is hidden because you are ignoring this member.

Inte superofftopic: Hur gör man det?
Om jag begriper hur systemet funkar i övrigt med interruptklocka för sequencern så förstör ju inte de långsamma accesserna timingen i sequencern (inget tyder på det, ingen hicka vi accesserna) utan det är bara logiken som blir onödigt krånglig om man vill ha liveprogrammering med snabba taktbyten/kedjor av takter.

Aha, kanske inte riktigt förstår problemet. Men ifall det skulle kunna hjälpa med något snabbare läsningar så styr TWBR-registret klocktakten på i2c på Avr (https://onlinedocs.microchip.com/pr/GUID-EF6FA2F3-5345-4829-9F5D-75388E2EF0C9-en-US-4/index.html?GUID-3BBC8619-26AF-4885-BB0C-D234E30426BD)

I nava-koden jag kikade på räcker det nog att bara ändra TWI_FREQ här till 400000 https://github.com/e-licktronic/Nava-v1.0/blob/master/libraries/WireN/utility/twiN.h

Observera att jag inte provat detta själv, det finns ju en risk att det blir instabilt. Ifall det medför att det skrivs skräp till eeprom:et kanske man behöver kunna nolla det, men det verkar det ju finnas en funktion för.

[Oortone]

This quote is hidden because you are ignoring this member.

Aha, kanske inte riktigt förstår problemet. Men ifall det skulle kunna hjälpa med något snabbare läsningar så styr TWBR-registret klocktakten på i2c på Avr (https://onlinedocs.microchip.com/pr/...C-D234E30426BD)

I nava-koden jag kikade på räcker det nog att bara ändra TWI_FREQ här till 400000 https://github.com/e-licktronic/Nava...utility/twiN.h

Observera att jag inte provat detta själv, det finns ju en risk att det blir instabilt. Ifall det medför att det skrivs skräp till eeprom:et kanske man behöver kunna nolla det, men det verkar det ju finnas en funktion för.

OK, tack för tipset.