Seneste forumindlæg
Køb / Salg
 * Uofficiel Black/White liste V2
Login / opret bruger

Hvor hurtig bliver en fil skrevet til min SSD?

Af Gigabruger EmilFrederiksen | 23-01-2020 03:42 | 1459 visninger | 34 svar, hop til seneste
Hej alle sammen Er er der nogen herinde, der kan komme med et kvalificeret bud på, hvor hurtigt en fil bliver skrevet til min SSD, når jeg trykker gem i MS Paint? Filens størrelse er ca. 15 kb. 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.” For yderligere forklaring se følgende link, nærmere betegnet afsnittet Read,Writes, and Erasure, med dertilhørende model: https://www.extremetech.com[...] Der er intet krævende software kørende i baggrunden. Jeg har ikke oplevet noget hardware fejle eller blevet langsommere med tiden. Mine specs: MB1151 Asus PRIME B250M-A Intel Core i5-7500 DDR4-2400 8GB Corsair Vengeance RAM SSD Samsung 850 EVO 250GB 2,5" (SSD) 9 Nvidia Asus GTX 1060 6GB Expedition PSU Corsair VS550 550W 80+ Windows 10 D-OEM Home Jeg håber, at nogen herinde, kan komme med et kvalificeret bud, end min simple udregning nedenunder. Jeg antager, at det tager længere tid end 0.000028 sek Skrivehastighed spec på SSD 520.000 kb / s divideret med 15 kb Ser meget frem til jeres svar! Hilsen Emil
--
#1
EXIA
Super Nørd
23-01-2020 04:13

Rapporter til Admin
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]
#2
Juletræet
Juniorbruger
23-01-2020 04:41

Rapporter til Admin
Skrevet kl 03:42.. er du okay ?
--
[I7 [email protected]|RTX 2080|ASUS Z270P|16GB 3200MHz]
#3
the688
Guru
23-01-2020 08:48

Rapporter til Admin
#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!"
#4
Charly
Junior Nørd
23-01-2020 09:05

Rapporter til Admin
Svaret er: Rigtigt hurtigt.
--
#5
zzup
Nørd
23-01-2020 09:36

Rapporter til Admin
--------- 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
#6
palle
Gæst
23-01-2020 11:06

Rapporter til Admin
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.
#7
crucial-kid
Redaktør
23-01-2020 14:28

Rapporter til Admin
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.
#8
EmilFrederiksen
Gigabruger
24-01-2020 01:50

Rapporter til Admin
#1 #4 #5 Kan I komme med et kvalificeret bud i milisekunder, eller hvor mange 0'er i nu kan sætte på.
--
#9
EmilFrederiksen
Gigabruger
24-01-2020 01:51

Rapporter til Admin
#6 Det forstod jeg ikke helt?
--
#10
EmilFrederiksen
Gigabruger
24-01-2020 01:52

Rapporter til Admin
#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.
--
#11
EmilFrederiksen
Gigabruger
24-01-2020 02:09

Rapporter til Admin
#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?
--
#12
crucial-kid
Redaktør
24-01-2020 15:43

Rapporter til Admin
#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.
#13
Sven Bent
Mega Nørd
24-01-2020 23:32

Rapporter til Admin
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
#14
EmilFrederiksen
Gigabruger
25-01-2020 03:49

Rapporter til Admin
#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?
--
#15
EmilFrederiksen
Gigabruger
25-01-2020 03:52

Rapporter til Admin
#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?
--
#16
palle
Gæst
25-01-2020 12:19

Rapporter til Admin
Bent har ikke behandlet write-back cachen endnu.
--
Gæstebruger, opret dit eget login og få din egen signatur.
#17
crucial-kid
Redaktør
26-01-2020 20:05

Rapporter til Admin
#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.
#18
palle
Gæst
26-01-2020 21:42

Rapporter til Admin
#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.
#19
MadsFerguson
Elite Supporter
26-01-2020 23:21

Rapporter til Admin
#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.
#20
Stilling
Maxi Supporter
27-01-2020 08:21

Rapporter til Admin
0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012 ca.
--
I5 9600k - Evo 212 - 1070 Gaming X - HyperX 16 GB 2400 mhz - UV400 240GB - CX550M - Thermaltake Core V21
#21
EmilFrederiksen
Gigabruger
29-01-2020 02:10

Rapporter til Admin
#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.
--
#22
EmilFrederiksen
Gigabruger
29-01-2020 02:11

Rapporter til Admin
#18 Jeg højreklikker også altid og beder systemet om "skub" ud. Men god forklaring hvorfor det er vigtigt.
--
#23
EmilFrederiksen
Gigabruger
29-01-2020 02:52

Rapporter til Admin
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?
--
#24
crucial-kid
Redaktør
29-01-2020 21:43

Rapporter til Admin
#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.
#25
EmilFrederiksen
Gigabruger
30-01-2020 02:19

Rapporter til Admin
#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
--
#26
palle
Gæst
30-01-2020 06:13

Rapporter til Admin
#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.
#27
palle
Gæst
30-01-2020 13:01

Rapporter til Admin
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.
#28
EmilFrederiksen
Ultrabruger
01-02-2020 01:21

Rapporter til Admin
#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.
--
#29
palle
Gæst
01-02-2020 01:33

Rapporter til Admin
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.
#30
EmilFrederiksen
Ultrabruger
01-02-2020 01:49

Rapporter til Admin
#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!
--
#31
palle
Gæst
01-02-2020 02:03

Rapporter til Admin
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.
#32
EmilFrederiksen
Ultrabruger
01-02-2020 02:09

Rapporter til Admin
Kan du forklare, hvordan du gjorde i #26, således du nemt kunne isolere processen?
--
#33
palle
Gæst
01-02-2020 02:23

Rapporter til Admin
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.
#34
EmilFrederiksen
Ultrabruger
04-02-2020 06:44

Rapporter til Admin
#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?
--

Opret svar til indlægget: Hvor hurtig bliver en fil skrevet til min SSD?

Grundet øget spam aktivitet fra udlandet, er det desværre ikke muligt for dig, at oprette svar som gæst.

Hvis du ønsker at deltage i debatten, skal du oprette en brugerprofil.

Opret bruger | Login
NYHEDSBREV
Afstemning