Så hurtigt at inden du har sluppet musetasten er det gemt.
--
1[Ci7 [email protected]|RTX 2080Ti SLi|X99|32GB 2666MHz] 2[Ci7 [email protected]|RTX 2080 SLi|X99|32GB 2666MHz] 3[R9 3900X|RTX 2070 Super|X570|32GB 3600MHz]

Skrevet kl 03:42.. er du okay ?
--
[I7 [email protected]|RTX 2080|ASUS Z270P|16GB 3200MHz]

#2 - check hans tidligere tråde - det lyder mest som om vi agerer lektiehjælp for et eller andet studie :) Det bliver tråden ikke mindre interessant af, men ja - man frygter for hans mentale helbred ;)
--
"ORK SATME!"

Svaret er: Rigtigt hurtigt.
--

--------- Så hurtigt!
--
i7-7700k 5ghz, Rog Strix 270F Gaming, Rog Strix 1080ti OC 11gb, m2 ssd 960 evo, Acer Predator Z1 32" 165hz G-Sync 1440p Curved

Et spørgsmål til panelet: Hvor hurtig er operativsystems mellemmand til fysisk at gemme denne fil på mandens SSD?
--
Gæstebruger, opret dit eget login og få din egen signatur.

Du kan faktisk ikke måle det, hvis spørgsmålet går på NAND niveau. Når man måler båndbredde og latency på en skrive-operation til en SSD, måler du ned til SSD-controller niveau. Når SSD-controlleren har modtaget data fra styresystemet scheduler, vil den give styresystemet besked om, at den har modtaget data, så styresystemet kan slette dataen fra dens oprindelse (USB, memory, andet drev etc). Så styresystemet opfatter en skriv operation som færdig, når den får besked på det, og ikke når den pågældende data reelt er lagret på NAND'en. Af samme årsag kan man stresse en SSD-controller, så den vil vise højere skrive hastigheder end læsehastigheder trods en read i praksis er hurtigere end en write. En SSD har en read latency på omkring 90-110us. Man går sjældent op i write latency (altså random latency på write i benchmark sprog), da du typisk vil gå efter write throughput - altså en sekvensiel operation som har til hensigt at sige noget om, hvornår opgaven er færdig frem for, hvor hurtigt vi kan starte den. Kan ikke lige komme på nogen som viser random write i latency i stedet for throughput. Håber det giver mening.
--
Mvh. Thomas Christensen.

#1 #4 #5 Kan I komme med et kvalificeret bud i milisekunder, eller hvor mange 0'er i nu kan sætte på.
--

#6 Det forstod jeg ikke helt?
--

#2 #3 Hvis I havde gennemlæst alle mine tråde, så ville I også kunne se, at jeg ikke er studerende. Jeg er udelukkende nysgerrig og vil gerne forstå de forskellige processer mv.
--

#7 Tak for dit lange indlæg "vil den give styresystemet besked om, at den har modtaget data, så styresystemet kan slette dataen fra dens oprindelse (USB, memory, andet drev etc)." Hvorfor sletter den det? Er det, hvis der er tale om den sletter en block for derefter skrive blokken igen + det nye data? "write throughput - altså en sekvensiel operation som har til hensigt at sige noget om, hvornår opgaven er færdig" Det er nok de termer jeg skulle have brugt, og de svar jeg søger. Der er jo så mange faktorer der spiller ind. Igen, kan du komme med et kvalificeret bud på mit oprindelige spørgsmål?
--

#11 Hele formålet med at skrive til SSD'en er jo at gemme data, som før lå et andet sted. Dvs. når SSD'en har gemt dataen, har du jo ikke brug for at have redundant data et andet sted. Så når du kopierer fra en USB pen, en mekanisk disk eller fra RAM til en SSD, så sletter styresystemet først den oprindelige data, når den har grønt lys for modtagelsen af SSD'en. Som sagt kan du ikke måle sådan lige måle write svartiden på NAND niveau pga. du ser det fra styresystemets vinkel, og den kan kun se til controller-niveau, ikke NAND-niveau. Tænker producenterne må have noget data, men det er ikke noget jeg har set tal på - igen det er ikke så relevant data. Tænker dog ikke de afviger meget fra read latency. Måske en faktor 2 langsommere eller noget (150-300us).
--
Mvh. Thomas Christensen.

some crucial kid er inde paa er der et par faktorer der spiller ind saasom caching mekanisme der skal ogsaa tages hoejde for SDD'ens tilstand. hvis den ikek har pages der er helt tomme for data saa skal de nye data ligge i en page med eksistrende data. da man ikke kan overskrive data en nand chip skal pagen sletts foerst. men da der er data paa den skal disse sikres foer vi kan slette resutalt er at en page laeses op i ram. modifieres med de nye data fra din fil. derefter skrives hele pagen tilbage. Saa selvom du kan gemmer en fil paa 15kb. saa kan du altsaa risiker at skulle laese data foerst og skriver til ssd'en mere data end hvad du rent faktisk gemmer Sideinfo: Det er af samme aarsager nogle raid5 opsaetninger er saa langsomme
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#12 Igen, mange tak for et langt og forklarende indlæg. Er processen ligeledes i hovedtræk?: OS ? > memory > SSD controller > NAND > giver besked til SSD controller om at data er skrevet > OS sletter data i memory "(150-300us)." - denne er dit bud på hele processen, fra tryk "gem" til færdigskrevet?
--

#13 Dette var også dette jeg prøvede at forklare i det oprindelige indlæg: Filen bliver skrevet til en ”fuld” / ”brugt” SSD. Med det menes: ” the SSD reads the “free”block into memory, then adds the new pages and then writes the whole block again, with the additional pages.” Jeg var klar over, at der er adskillige faktorer der spiller ind, jeg var dog ikke helt sikker på hvilke. Jeg er interesseret i kvalificerede bud på tid, for hele processen, hvor man tager højde for det du skiver, at der ikke skrives til empty data blocks. Hvad med dig Sven Bent, vil du komme med et kvalificeret bud?
--

Bent har ikke behandlet write-back cachen endnu.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#14 EmilFrederiksen Det er styresystemet og dets scheduler, som styrer showet ned til din SSD, så på den måde kan du jo godt sige, at den altid starter der. Men det er jo software, så den passer ikke ind i din først a, så b og så c. Det hele afhænger jo desuden af, hvor dataen kommer fra. Det vil jo oftest være fra RAM set fra et sandsynligheds perspektiv, men hvis du kopierer en fil fra drev x, så er det jo her, at processen starter, og ikke DRAM, som slet ikke vil være involveret. Tror du tænker på en read forespørgsel, hvor der set fra CPU'ens synpunkt f.eks. er en klar først den, så den tilgang (dvs. først L1 til L2 til L3 til DRAM til SSD til HDD til DVD osv.). Men lad os sige, at vi flytte data fra DRAM til SSD, så spørger styresystemet sin memory controller om data x, venter på den er klar, og efter modtagelse sender den det ned til SSD'en. Her modtager SSD-controlleren dataen, og når den har gemt den i sin cache, giver den styresystemet besked på, at data er modtaget, hvorefter styresystemet beder memory controlleren om at slette data i DRAM igen. Hvor lang tid SSD reelt er om at gemme data fra sin cache til et permanent lokation, det er en svær størrelse at måle, og den variere af forskellige årsager såsom load, antal frie blokke osv. Mit skud fra hoften var bare en faktor to i forhold til en read operation under optimale forhold, men det kunne sagtens være mere. #16 palle Write back cache er ligegyldig i forhold til spørgsmålet, da vi snakker direkte til SSD latency. Det er jo ikke hurtigere at skrive fra medie x til DRAM og så til SSD. Det tilføjer jo bare et ekstra hop. Og snakker vi SSD som write cache, så er det jo identisk hastighed uanset om SSD'en er endelig destination for dataen eller om det blot er som midlertidig cache - det er samme operation, blot lagret forskellige steder på SSD'en.
--
Mvh. Thomas Christensen.

#17 Men hvor længe ligger data i Windows' write-back cache, inden det bliver skrevet til SSD'en? Det er bl.a. på grund af denne cache, at det er en rigtig god ide at skubbe en ekstern disk ud, inden den bliver fysisk fjernet.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#17 Rigtig god gennemgang. blot en enkelt kommentar, det er ikke en sikkerhed at OS'et vil 'slette filen' fra RAM, den vil sandsynligvis blive markeret til cache istedet, med en timer på.
--
Large deployment System Engineer, High Performance Computing specialty.

0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012 ca.
--
I5 9600k - Evo 212 - 1070 Gaming X - HyperX 16 GB 2400 mhz - UV400 240GB - CX550M - Thermaltake Core V21

#17 Ja, det er selvfølgelig rigtig nok. Idet det er en billedfil der er åbnet i MS Paint og som arbejdes med. Så er det jo selvfølgelig CPU > memory osv. Og ja, selvfølgelig, hvis der er tale om kopi af data fra drev A til drev B, så starter det selvfølgelig med drev A. Og mange tak for den fine lange forklaring.
--

#18 Jeg højreklikker også altid og beder systemet om "skub" ud. Men god forklaring hvorfor det er vigtigt.
--

TRIM funktionen har ugentligt wiped pages og blocks med unsused data. Idet jeg havde 10 GB ledig, må det vel antages, at SSD'en har kunnet skrive direkte til en blok, uden først at slette blokkens indhold? Og derved er processen hurtigere. Men hvor meget hurtigere?
--

#18 palle Fortid. Sådan fungerer det ikke efter Win10 1809. Den cacher ikke længere writes på eksterne enheder. Du kan slå det til, men default er fra. Så cache write er en forkert størrelse at kaste ind i emnet. https://docs.microsoft.com[...] #23 EmilFrederiksen Det er algoritmer og andre smarte kodetricks der kommer i spil, og de skal også tage hensyn til slid - altså at de enkelte pages bliver brugt lige meget/lidt. Det er prioritet #1 over performance. TRIM kører ikke ugentligt. Det kører hele tiden. Styresystemet siger hele tiden til en SSD, at den der page ikke længere er i brug. SSD'en behøver ikke nødvendigvis at slette den, men vil typisk bare markere den som ligegyldig og klar til at blive brugt/overskrevet. Så TRIM øger sandsynligheden for, at der er hele blokke klar til at blive skrevet på, og dermed undgår du en write til hele blokken i forbindelse med en sletning. Carbage collection sørger for, at få flyttet data rundt og sprede slid på de enkelte blokke og pages. Hvor meget hurtigere er der ikke et tal for. Det minder lidt om at skulle svare på, hvor hurtig du er til at finde dimsedut x på dit værelse i tilfælde af 40% rod. Der er alt for mange variabler, og SSD'er varierer i deres prioriteringer. Den prioriterer typisk slid fordeling over alle andre faktorer, så man kan ikke bare sige, x antal ledig GB = x antal frie blokke.
--
Mvh. Thomas Christensen.

#24 Giver god mening den fordeler skrivning til de forskellige blokke, så ikke der kun er et område der bliver slidt. Nu har jeg efter bedste evne prøvet at læse op på "garbage collection" og TRIM, hovedsageligt med udgangspunkt i denne artikel, eftersom jeg fandt den mest forståelig og ligetil: https://getprostorage.com[...] Jeg har prøvet at lave en opsummering til mig selv, og du må gerne bekræfte hvorledes det er korrekt: Garbage collection Formålet er at have blokke der enten er helt fulde eller helt tomme Det er gode / aktuelle pages der bliver samlet og de uaktuelle der forbliver tilbage Sørger for, at have en stor beholdning af uberørte / pristine tomme blokke klar til at blive skrevet til Controlleren søger inventory / fortegnelse igennem for pages der er skrevet data til, for at lede efter pages med ”stale” / forslidt data /uaktuelle sider Det er pages med data på som skal ændres af OS Ændring af tilstand for pages er umulig uden først at slette dem De nye ændringer / det nye data skrives til tomme pages / tomme blokke Det tilbageblivende data markeres som stale / uaktuelt Garbage collection søger efter blokke, der inderholder både aktuelle / gode pages og stale / uaktuelle pages Alle de gode / aktuelle pages kopieres til tomme pages /tomme blokke Alle stale / uaktuelle pages forbliver tilbage i blokken Den gamle blok wipes og bliver markeret som tom og klar tilskrivning TRIM OS fortæller SSD hvilke pages der er stale / uaktuelle SSD behøver ikke længere at skrive pages med slettet data på Gør garbage collection mere effektiv
--

#24 Det er ikke den cache, jeg taler om her. Den pågældende cache er intern til Windows - Windows' cache manager. Den benytter "lazy writing". Du kan se effekten med process monitor. Lad processerne "system" og "mspaint.exe" overvåge din fil. Når du trykker gem i mspaint, vil du se to skriveoperationer til filen. Den operation, som rent faktisk skriver data til drevet, bliver udført af system-processen. Der kan godt gå nogle sekunder, fra du trykker gem i mspaint, til den bliver trigget.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Når vi så taler om fjernelsespolitik, "hurtig fjernelse" vs. "bedre ydelse", er forskellen den, at cachemanden ikke bruges ved hurtig fjernelse. Det ses i process monitor ved, at system ikke optræder i loggen.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#26 Din påstand er, at processen fra trykker "gem" til filen er færdigskrevet til SSD, derfor tager op til flere sekunder? Når jeg gemmer en fil på skrivebord, så optræder den på skivebordet i løbet af et halvt til helt sekund? Jeg vil meget gerne høre fra andre, hvorledes hans påstand er korrekt, for så er der mange der tager fejl i, at det ikke sker med det samme man trykker gem og processen ikke er fuldført på 0,1 sekund ca.
--

https://ibb.co[...] Loggen viser, at jeg har trykket på gem to gange. Anden gang bliver filen først gemt på drevet efter 9 sekunder.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#29 Så selvom, at filen fremgår i Explorer / skrivebord, så er det ikke garanti for, at den faktisk er færdigskrevet? Er spændt på, hvad folk siger til dine fund!
--

Nej, det kan du ikke vide. Hvis man f.eks. gemmer en stor fil, kan det virke, som om den bliver færdiggemt meget hurtigt - men hvor cache manageren rent faktisk i det skjulte er i færd med at skrive filen ud på drevet.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Kan du forklare, hvordan du gjorde i #26, således du nemt kunne isolere processen?
--

Du kan lave et filter på path, f.eks. "path" "contains" "navn på fil" "include" så viser den kun handlinger vedrørende din fil.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#26 Windows' cache manager. Den benytter "lazy writing". Har denne også indflydelse på hvad der foregår i CPU og RAM, eller er det kun på Disk niveau?
--