Seite 4 von 52 ErsteErste 1 2 3 4 5 6 7 8 14 ... LetzteLetzte
Ergebnis 76 bis 100 von 1297
  1. #76
    Hauptgefreiter
    Registriert seit
    22.06.2008
    Beiträge
    228


    Standard

    Zitat Zitat von HisN Beitrag anzeigen
    [*]Auslagerungsdatei verlagern
    [...]
    Das liegt einfach daran das ein 32-Bit-Programm von seinen 4GB virtuellem Speicher sowieso nur 1,8GB physikalisch nutzen kann, braucht es mehr geht dieser Teil in die Swapdatei.
    Warum sollte das so sein?

    Ein 32-Bit Programm im 32-Bit Windows OS hat maximal 2GB virtuellen Speicher. Mit dem Linker flag /LARGEADDRESSAWARE übersetzt, kann es 3GB virtuellen Speicher nutzen, wenn auch noch der /3GB Bootswitch (bzw. incr******erva in BCDEDIT) mitspielt.

    Wer aber die Auslagerungsdatei deaktivieren möchte, hat im Moment vermutlich eh >4GB. Sprich, wenn es ein Windows OS ist, hat er eine 64-Bit Version wie z.B. Vista 64-Bit. Dort hat jede Anwendung mit obigem Compileswitch dann 4 GB:
    http://msdn.microsoft.com/en-us/library/aa366778.aspx

    Wieviel Virtueller Adresspeicher von einer Anwendung adressiert werden kann (s.o. 2-4GB) hat natürlich nichts damit zu tun welche 4k Pages davon im Physikalischen Speicher liegen und welche im Swapfile. Vielmehr ist das Sache des Betriebssystem hier nach Zugriffsmustern zu entscheiden welche Pages ins Swapfile kommen und welche nicht. Dies im Gleichgewicht mit konkurrierenden Diensten wie z.B. Windows Datenträgercache und Superfetch, die prinzipiell so viel physikalischen Speicher haben wollen wie sie kriegen können.

    Woher die 1,8GB Einschränkung kommen soll ist mir schleierhaft. Im Microsoft Jargon heißt die Menge an pages, die im physikalischen Speicher liegen, und einem Prozess gehören das Working Set. Ich kenne solche Einschränkungen nicht für das Working Set. Darüberhinaus gibt es auch eine API gibt um noch schneller und einfacher Speicher jenseits der 2GB anzusprechen (AWE) und explizit physikalischen Speicher (non-paged) zu fordern:
    http://msdn.microsoft.com/en-us/libr...27(VS.85).aspx
    Somit ist es ein leichtes für Anwendungen >1,8GB physikalisch anzusprechen.
    --

    Die Auslagerungsdatei zu deaktivieren ist möglicherweise auch bei 8GB Hauptspeicher nicht die beste Idee. Manche Anwendungen gehen verschwenderisch mit Hauptspeicher um (*), da ist es günstiger die Seiten wegzupagen u. den physikalischen Speicher für sinnvollere Dinge zu verwenden (und wenn es Superfetch ist). Angeblich soll sich Photoshop auch beschweren, wenn die Auslagerungsdatei deaktiviert ist.

    Ich stimme also zu, dass das Auslagerungsdatei deaktivieren nicht unbedingt gut ist. Die Begründung mit den 1,8GB höre ich hingegen zum ersten Mal u. hätte gerne einen Link zum Nachlesen zu dem Thema. Auch wenn's Offtopic ist.

    (*) entweder weil sie zu viel Speicher vorausschauend allokieren, ihn aber nicht nutzen. Oder aufgrund von Speicherleaks, die in C(++) schnell auftreten können wenn nicht sorgfältig analysiert und bei größeren Projekten Toolgestützt überprüft.
    Geändert von 7oby (10.12.08 um 15:08 Uhr)

  2. Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

  3. #77
    Admiral Avatar von Snoopy69
    Registriert seit
    06.01.2005
    Beiträge
    18.474


    Standard

    Kann mir jmd erklären, warum Windows (Vista x64) trotz ausreichend Ram (4GB) auf pagefile.sys schreibt und davon liest?
    Ich hab nun wie HisN auf I-Ram ausgelagert. Frage mich aber trotzdem, ob es nicht besser wäre auf 8GB aufzurüsten (kosten unter 60€) und dann pagefile.sys auf die Software-Ramdisk auszulagern. Immerhin wäre das x-fach schneller als I-Ram.

    Geändert von Snoopy69 (14.12.08 um 12:55 Uhr)
    Solid State Drive (SSD) - Sammelthread

    Kraft macht keinen Lärm. Sie ist da und wirkt. (Albert Schweitzer) l Kühlst Du schon oder lüftest Du noch? l http://www.cyberslang.de/

  4. #78
    Hauptgefreiter
    Registriert seit
    22.06.2008
    Beiträge
    228


    Standard

    Zitat Zitat von Snoopy69 Beitrag anzeigen
    Kann mir jmd erklären, warum Windows (Vista x64) trotz ausreichend Ram (4GB) auf pagefile.sys schreibt und davon liest
    4GB nennst Du ausreichend für Vista x64? Das ist ja weniger als 3,5GB unter Vista 32-Bit...

    Selbst mit 8GB würde Vista pagen. Er tut es aus folgendem Grund:
    . Geht Dir der Speicher aus, so müsste er erst speicher auf HDD auslagern (= langsam) und dann kann der freigewordene genutzt werden.

    Windows ist schlauer und geht wie folgt vor:
    . Von dem gesamten pageable memory lagert er schon einen Teil während dem Betrieb mit geringer Prozesspriorität auf HDD aus.
    . Fordert ein Prozess mehr Ram als z.Z. verfügbar, so braucht zum großen Teil nicht ausgelagert zu werden, sondern lediglich einige Hauptspeicher Pages dem Prozess zugeordnet werden. Das funktioniert, da einige Seiten ja schon als 1:1 Kopie auf dem Hintergrundspeicher (pagefile) liegen.

    Es ist also tatsächlich eine Performanceoptimierung von 2000/XP/Vista. Siehe in diesem Buch S. 819 "The Page Replacement Algorithm":
    http://www.amazon.de/Modern-Operatin...dp/0130926418/

  5. #79
    Admiral Avatar von Snoopy69
    Registriert seit
    06.01.2005
    Beiträge
    18.474


    Standard

    Ok, dann erkläre mir warum Vista nicht die freien 30% Ram nutzt. Das sind ca. 1230MB freie Kapazität. Die Belegung in der pagefile.sys ist aber wesentlich weniger als 1230MB. In meinen Fall momentan ca. 310MB.
    Solid State Drive (SSD) - Sammelthread

    Kraft macht keinen Lärm. Sie ist da und wirkt. (Albert Schweitzer) l Kühlst Du schon oder lüftest Du noch? l http://www.cyberslang.de/

  6. #80
    Hauptgefreiter
    Registriert seit
    22.06.2008
    Beiträge
    228


    Standard

    Weil obiges Prinzip nicht die alleinige Regel ist. Windows sorgt dafür, dass nicht ein Prozess einfach das gesamte Ram auffrisst und 99 andere Prozesse darunter leiden, indem sie sehr oft swappen müssen. Windows gibt einem Prozess nicht einfach Hauptspeicher, sondern nur innerhalb der Working Set Minimum/Maximum Pages. Fordert ein Prozess mehr, so werden zunächst die Pages des Prozesses beschnitten: Für jede Page, die der Prozess neu anlegt, wird erstmal eine andere des selben Prozesses ausgelagert. Also auch, wenn eigentlich noch genügend Ram verfügbar ist.

    Minimum/Maximum Pages kann man als Administrator anpassen (weiß nicht auswendig wie, wird ein Registry Key sein). Die Grenzen sind aber ohnehin nicht statisch. In Windows sind genügend Heuristisken, die abhänig von der "Natur der Anwendung" das Paging Verhalten anpassen. Das mit den Minimum/Maximum Pages wusste ich auch gerade nicht auswendig. Hab's nachgeschlagen in besagtem Buch. Das erklärt dann warum Vista/XP auslagert auch wenn freier Speicher noch verfügbar ist. Allerdings aus einem anderen Blickwinkel als die geposteten 1,8GB.

    Das funktioniert eigentlich auch sehr gut. Zumal Anwendungen auch explizit nicht pagebaren Speicher anfordern können. Der Programmierer einer Anwendung weiß womöglich noch besser welche Daten oder Code Teile er sehr häufig benötigt u. kann dafür sorgen, dass diese nicht ausgelagert werden.

    Das Paging besteht aus einer Reihe von Prinzipien und von noch viel mehr Sonderfällen und Ausnahmen. Die wenigsten davon sind für XP/Vista irgendwo dokumentiert. Ist halt closed source.

    Das beste was Du tun kannst (wenn Du kein Hibernation Feature benutzt): 6GB oder 8GB Ram. Das ist einfach und nützlich. Rumtweaken kann man sicher auch hier und da.

    Der Prozess Scheduler ist ähnlich: Ein paar Prinzipien und sehr viele Ausnahmen. Selbst eine vermeindlich "simple" Kopierroutine in Windows ist unheimlich kompliziert. Für letzteres gibt's wenigstens auch einen Online Verweis:
    http://blogs.technet.com/markrussino...4/2826167.aspx
    Geändert von 7oby (14.12.08 um 15:09 Uhr)

  7. #81
    Keksjunkie Avatar von FischOderAal
    Registriert seit
    29.12.2004
    Beiträge
    31.655


    • Systeminfo
      • Motherboard:
      • MSI P55-GD65
      • CPU:
      • Core i5 750
      • Kühlung:
      • Luft (EKL Brocken ; Yate Loon)
      • Gehäuse:
      • Avance B030
      • RAM:
      • 4 GB G.Skill Ripjaws 1600 CL7
      • Grafik:
      • Sapphire HD 5850 1GB
      • Netzteil:
      • Enermax Liberty 500W
      • Betriebssystem:
      • Win 7 Business x64
      • Notebook:
      • MacBook Late 2006
      • Photoequipment:
      • Canon EOS 450D ; Sigma 105 mm Makro ; Canon EF 50 1.8II ; Canon EF-S 18-55 IS
      • Handy:
      • Palm Veer

    Standard

    Wow. Dank dir für die Erklärung! Das gleiche hat mich auch immer gewundert (Festplatte am rattern wie wild und 800 MB RAM frei).
    FUS RO DAH!
    Zitat Zitat von Terry Pratchett's "Snuff"
    Indeed, if a poor man will spend a year in prison for stealing out of hunger, how high would the gallows need to be to hang the rich man who breaks the law out of greed?

  8. #82
    Matrose
    Registriert seit
    02.09.2008
    Beiträge
    23


    Standard

    Ohne zu wissen wie die interen Schreibroutine von SSDs auf feste Dateien aussieht:
    Macht es vielleicht Sinn, die Auslagerungsdatei variable zu halten, zwischen 0 und bspw. 4 GB, um dafür zu sorgen, dass Änderungen innerhalb der Datei nicht immer auf die gleichen Blöcke der SSD geschrieben werden, wie es ja bei HDDs der Fall ist?

  9. #83
    Oberbootsmann Avatar von Warbeast
    Registriert seit
    13.02.2005
    Ort
    Berlin
    Beiträge
    944


    Standard

    Oder vielleicht in der grösse der Erase Blöcke festlegen?

  10. #84
    Admiral Avatar von Snoopy69
    Registriert seit
    06.01.2005
    Beiträge
    18.474


    Standard

    @ 7oby

    Danke
    Solid State Drive (SSD) - Sammelthread

    Kraft macht keinen Lärm. Sie ist da und wirkt. (Albert Schweitzer) l Kühlst Du schon oder lüftest Du noch? l http://www.cyberslang.de/

  11. #85
    Admiral Avatar von HisN
    Registriert seit
    09.06.2006
    Beiträge
    29.220
    Themenstarter


    Standard

    Zitat Zitat von Kannix Beitrag anzeigen
    Ohne zu wissen wie die interen Schreibroutine von SSDs auf feste Dateien aussieht:
    Macht es vielleicht Sinn, die Auslagerungsdatei variable zu halten, zwischen 0 und bspw. 4 GB, um dafür zu sorgen, dass Änderungen innerhalb der Datei nicht immer auf die gleichen Blöcke der SSD geschrieben werden, wie es ja bei HDDs der Fall ist?
    Der Controller in der SSD regelt wo was hingeschrieben wird. Einen festen "Platz" auf dem Speicherträger gibt es nicht mehr.
    Wenn ein Block ins Pagefile geschrieben wird, dann wandert der ganze Löschblock doch sowieso an eine andere Stelle der SSD :-)
    Ob das jetzt mit dem Ändern der Pagefile-Größe was gerissen wird weiß ich nicht.
    Geändert von HisN (15.12.08 um 18:19 Uhr)

  12. #86
    Matrose
    Registriert seit
    02.09.2008
    Beiträge
    23


    Standard

    Zitat Zitat von HisN Beitrag anzeigen
    Wenn ein Block ins Pagefile geschrieben wird, dann wandert der ganze Löschblock doch sowieso an eine andere Stelle der SSD :-)
    .
    Das war ja worauf ich hinaus wollte. Afair wird das ganze ja nicht gelöscht sondern nur aktualisiert/überschrieben.
    Aber wenn das SSD-intern als löschen gehandelt wird, dann ist es ja ok ;-)

  13. #87
    Admiral Avatar von Snoopy69
    Registriert seit
    06.01.2005
    Beiträge
    18.474


    Standard

    Zitat Zitat von HisN Beitrag anzeigen
    Ob das jetzt mit dem Ändern der Pagefile-Größe was gerissen wird weiß ich nicht.
    Kann man sicher überprüfen
    Solid State Drive (SSD) - Sammelthread

    Kraft macht keinen Lärm. Sie ist da und wirkt. (Albert Schweitzer) l Kühlst Du schon oder lüftest Du noch? l http://www.cyberslang.de/

  14. #88
    Bootsmann Avatar von IndianaX2
    Registriert seit
    17.09.2008
    Beiträge
    523


    Standard

    OK, bin auf meinem Notebook eben alle schritte durchgegangen.
    Problem: Windows XP 32 will sich nicht als NTFS auf eine "aligned Partitionen" installieren, nur als FAT32.

    Nun die frage, welches FS is für SSD besser?
    Ein convert C: /FS:NTFS wäre ja schnell durchgeführt.

    Mit dem WBEM bin ich mir noch nicht sicher, da ist noch jede menge Zeug drinnen was ziemlich mysteriös ist.

    Edit: Ohne oder mit geändertem Workdir mag das ATI CC nicht!
    Wobei WBEM auch nur schreibt wenn es benutzt wird => ambesten keine Monitoring sachen laufen lassen (z.b. SpeedFan & Co, mit Filemon beobachtet)
    Geändert von IndianaX2 (18.12.08 um 20:38 Uhr)
    Have a N.I.C.E. day!
    Real programmers don't comment their code - it was hard to write, it should be hard to understand.
    Mein Heimkino / Hardware

  15. #89
    Oberbootsmann
    Registriert seit
    05.08.2007
    Beiträge
    777


    Standard

    Vielen Dank an antiram für den Tipp mit dem Partiton alignment! Ich habe dazu noch ein paar Hinweise:

    Benutzer von Windows Server 2003 SP1 und Windows Vista haben bereits die aktuelle Version von diskpart.exe und können dieser einfachen Anleitung folgen: http://technet.microsoft.com/en-us/l...EXCHG.65).aspx

    Wer jedoch eine ältere Version von diskpart.exe hat (die in Windows XP und 2000) der bekommt eine Fehlermeldung beim Versuch den Parameter "align" zu benutzen. Es gibt aber eine Lösung. Entweder man holt sich die neue diskpart.exe von einem anderen Windows-System (habe ich nicht getestet). Ansonsten gibt es noch von Microsoft ein Windows 2000 Resource Kit, welches das Tool "diskpar.exe" (ohne t) enthält. Mit diesem Tool können auch unter XP und 2000 Partitionen ausgerichtet werden. Leider bietet MS dieses Kit nicht mehr zum Download an. Mit Google sollte man das Programm diskpar.exe aber finden können (ich will hier keinen Direktlink posten, bin mir nicht sicher ob das erlaubt ist).

    Benutzung von diskpar.exe:

    Programm in der Konsole öffnen: "diskpar -s x" wobei x die Nummer der SSD bzw. Festplatte ist. Diese Nummer kann man in der Datenträgerverwaltung nachschauen (wenn dort die SSD "Datenträger 2" heisst muss bei diskpar entsprechend eine 2 eingegeben werden). Dann bestätigen, und man bekommt die Option einen Startsektor für die erste Partition anzugeben. Jetzt muss man nur noch in die Datenträgerverwaltung gehen und die Platte mit dem gewünschten Dateisystem formatieren.

    Ganz hartgesottene können den Startsektor auch direkt in den Master Boot Record schreiben, es müssen die CHS-Einträge des ersten und letzten Sektors für die gewünschte Partition eingetragen werden (siehe http://de.wikipedia.org/wiki/Partitionstabelle ).


    Mal was zur Zuordnungseinheit des Dateisystems. Ich habe mir folgendes überlegt. Ich lasse ATTO laufen und sehe, dass ich bei den Random Writes einen sehr großen Sprung von 8k auf 16k habe (mehr als die doppelte Geschwindigkeit). Würde es dann Performancetechnisch sinn machen, die Clustergröße auf 16kb zu setzen? Oder habe ich da (mal wieder) falsch gedacht? Ich glaube fast ja, ich bringe dauernd durcheinander wie das alles zusammenhängt... und bringt es etwas, die Clustergröße auf die Größe eines erasable Blocks zu setzen?
    Geändert von barzefutz (18.12.08 um 22:53 Uhr)

  16. #90
    Banned
    Registriert seit
    19.07.2006
    Beiträge
    8.427


    Standard

    btw - hier gibts ne "freeware" ramdisk die bis zu 4gb grosse ramdisks machen kann
    laeuft auch unter vista 64bit
    http://www.cenatek.com/product_page_...nload_list.php
    die neue beta version ...

    load, save, autosave aus/in eine imagefile is moeglich!

  17. #91
    Obergefreiter
    Registriert seit
    15.06.2007
    Beiträge
    123


    Standard

    Ich habe ein paar Gedanken zum Booten, die ich gerne mit euch teilen möchte. Kurz zum Hintergrund: Habe (noch) keine SSD, benutze XP und habe mir gerade den Startvorgang angesehen, der ja mit einer (guten) SSD deutlich schneller läuft. Ich nutze selbst überwiegend Standby (S3), aber trotzdem einige Erkentnisse:

    • Beim Start meines XP (2 Jahre alt, typische Vielnutzer-Installation) werden 216 MB an Daten gelesen
    • Ich habe mir die Dateien per Zugriffsprotokoll angesehen:
      • Gesamt 879 Dateien (inkl. Autostart, z.B. Skype)
      • 150 Dateien sind < 1 KB
      • 204 Dateien sind 1 KB bis 10 KB
      • 262 Dateien sind 10 KB bis 100 KB
      • 226 Dateien sind 100 KB bis 1 MB
      • 37 Dateien sind > 1 MB, Spitzenreiter Skype.exe mit 22 MB

    • Der Bootvorgang dauert etwa eine Minute (5.400er-Platte). Wenn davon auch nur ein Drittel auf die Lesevorgänge der Platte entfällt, ist das schon eine riesige Verschwendung! Grund: Man könnte doch die oben genannten 216 MB in eine große Datei packen, diese bei jedem Booten in den RAM laden und von dort aus weiterstarten:
      • Die Datei könnte einmalig angelegt werden und 1x pro Monat aktualisiert werden
      • Laden der Datei in den RAM beim Booten dürfte 3 Sekunden dauern
      • Fehlen Dateien im RAM, wird dieser Rest eben "normal" von der Platte geladen


    Problem ist wohl, dass Windows keine solche Mechanik unterstützt? Ist doch eigentlich kein rocket science! Könnte man sowas basteln? Ich meine, auch eine SSD ist beim Zugriff auf kleine Dateien langsamer. Dafür läd sie die 200 MB aber in 2 Sekunden, und im RAM sind Wartezeiten nahe null anzunehmen.

  18. #92
    Kapitän zur See Avatar von crysel
    Registriert seit
    11.12.2005
    Beiträge
    4.093


    Standard

    Wieso sollte das Laden der Daten in den Ram schneller gehen als das ganz normale Laden beim Hochfahren (du musst die Daten doch irgendwie in den Ram schreiben bzw. von deiner HDD erstmal lesen )? Der Knackpunkt ist und bleibt die lesende Festplatte, wobei selbst eine alte 5400er deine 216MB in wenigen Sekunden gelesen haben wird.
    Und den ganzen Kram schon im Ram zu speichern ist nicht möglich.. sobald der PC aus ist, ist der Ram wieder leer.
    Beim Booten geht die meiste Zeit für die Initialisierung von Hardwareteilen oder Diensten drauf. Ich hab in meinem Notebook eine lahme 5400er gegen eine 16GB Mobi ersetzt. Booten geht zwar schneller, aber dauert trotzdem noch ca. 50Sek. und der XP-Balken muss 6mal durchlaufen. Aber nur bei 1-2 Balken zwischendurch leuchtet mal eben die SSD/HDD-Lampe auf, ansonsten langweilt die sich zu Tode.

  19. #93
    Oberbootsmann
    Registriert seit
    05.08.2007
    Beiträge
    777


    Standard

    Ich habe mal einige Tests durchgeführt mit verschiedenen Dateisystemen, Clustergrößen und Alignments.

    Tests durchgeführt mit PCMark05 (File Write Bench) und einem Transcend 2GB Flash Modul.

    STANDARD-AUSRICHTUNG ("krumme" 32 KB):

    26.297 - fat32 16k
    26.113 - fat16 64k
    26.002 - fat16 32k
    25.994 - fat32 512b
    25.936 - ntfs 16k
    25.664 - ntfs 4k
    25.251 - ntfs 64k
    25.196 - ntfs 512b

    OPTIMIERTE AUSRICHTUNG (16 MB):

    26.767 - fat16 64k
    26.667 - fat32 16k
    26.632 - fat16 32k
    26.306 - ntfs 4k
    26.161 - fat32 512b
    26.069 - ntfs 64k
    25.608 - ntfs 16k
    25.294 - ntfs 512b


    FAZIT:

    Mit der optimierten Ausrichtung war alles insgesamt 1,5% schneller. FAT ist schneller als NTFS. Je höher die Clustergröße, desto höher die Geschwindigkeit.
    Vielleicht stellt ja jemand ähnliche Tests an?

    Bei mir war der Abstand merkbar, aber längst keine 18% wie bei antiram. Liegt das an nilfs?

    Gute Nacht
    Geändert von barzefutz (19.12.08 um 01:23 Uhr)

  20. #94
    Bootsmann Avatar von DerRob
    Registriert seit
    01.10.2006
    Beiträge
    612


    Standard

    Zitat Zitat von crysel Beitrag anzeigen
    Wieso sollte das Laden der Daten in den Ram schneller gehen als das ganz normale Laden beim Hochfahren (du musst die Daten doch irgendwie in den Ram schreiben bzw. von deiner HDD erstmal lesen )? Der Knackpunkt ist und bleibt die lesende Festplatte, wobei selbst eine alte 5400er deine 216MB in wenigen Sekunden gelesen haben wird.
    stichwort zugriffszeit. für die eine 216mb-datei brauchst du 1x etwa 15ms, um auf die datei zuzugreifen. für die 879 einzelnen dateien brauchst du allerdings schon etwa 13 sekunden, um überhaupt auf die dateien zuzugreifen.
    Intel Core i5 4670K | 2x 8GB DDR3 | Asus Z87-A | GeForce GTX980 | Enermax Modu82+ 525W | Crucial M500 480GB + Seagate 2TB SSHD | Asus PB287Q + 2x Belinea 20"@1600x1200 | Windows 10 x64
    • • •
    Server: Intel Pentium G620 | 8GB DDR3 | ~20TB | Windows Home Server
    • • •
    Mobil: Dell Vostro A90 (Intel Atom N270 | 1x 2GB DDR2 | 32GB SSD) | Win7 Starter

  21. #95
    Admiral Avatar von HisN
    Registriert seit
    09.06.2006
    Beiträge
    29.220
    Themenstarter


    Standard

    Was bei einer SSD wiederrum auf 80-240ms reduziert werden würde :-)

  22. #96
    Kapitän zur See Avatar von crysel
    Registriert seit
    11.12.2005
    Beiträge
    4.093


    Standard

    Zitat Zitat von DerRob Beitrag anzeigen
    stichwort zugriffszeit. für die eine 216mb-datei brauchst du 1x etwa 15ms, um auf die datei zuzugreifen. für die 879 einzelnen dateien brauchst du allerdings schon etwa 13 sekunden, um überhaupt auf die dateien zuzugreifen.
    Naja, ok das hast du Recht. Aber dann müsste man erstmal eine große Datei hinbekommen.. könnte natürlich gezippt werden, dann beim Start in den Ram, dort entpacken lassen (sollte ja wesentlich schneller gehen ) und dann laden... da es sowas für den Bootvorgang aber nicht gibt --> SSD

  23. #97
    Banned
    Registriert seit
    19.07.2006
    Beiträge
    8.427


    Standard

    nennt sich hibernate und gibts schon lang

  24. #98
    Hauptgefreiter
    Registriert seit
    22.06.2008
    Beiträge
    228


    Standard

    Zitat Zitat von crysel Beitrag anzeigen
    da es sowas für den Bootvorgang aber nicht gibt
    So'n bißchen gibt's das schon u. wird von Microsoft ständig weiterentwickelt. Der Defragmentierer legt sich die Dateien, die er für's booten benötigt schon zusammen. Vista analysiert angeblich auch selbsständig die bootlogs u. baut das entsprechend um.

    Das Problem entsteht ein klein bißchen weiter hinten im Bootprozess: Wenn die Services geladen werden bzw. spätestens beim Autostart: Die starten alle parallel und nicht staggered. Die Dateien sind auch nicht gerade klein: Viruskiller, verschiedene Updater, Skype, ... Da rennt der Schreib-/Lesekopf nur hin und her.

    SSDs werden schon über kurz oder mittellang die Systemplatte ersetzen. Denn irgendwie tut sich Microsoft schwer den Bootprozess zu verkürzen - auch wenn sie ständig Verbesserungen einbauen (die aber von anderen Dingen wieder aufgefressen werden).

    bg,
    7oby

  25. #99
    Kapitän zur See Avatar von Dr.Cupido
    Registriert seit
    21.11.2008
    Beiträge
    3.131


    • Systeminfo
      • Motherboard:
      • MSI Z370 Tomahawk
      • CPU:
      • I5-8600k @ 5000Mhz
      • Kühlung:
      • passiv Wasserkühlung
      • Gehäuse:
      • Silverstone Raven 2
      • RAM:
      • 32GB G.Skill DDR4-3600, CL19
      • Grafik:
      • GTX 1080 TI
      • Storage:
      • 2x M.2 Samsung SSD 970 EVO 500GB
      • Netzteil:
      • EVGA SuperNOVA T2 1000W
      • Betriebssystem:
      • Win 10 64-Bit

    Standard

    wie finde ich heraus, wie groß meine Eraseblocks sind um mein Alignment richtig anzupassen ?

    Im ersten Beitrag unter Vorbereitung kommt man auf einen Post,der auf das OCZ Forum widerum verweist, dieser Link ist jedoch für User gesperrt. Hab mich sogar extra dort angemeldet, aber auch so kann man nicht drauf zugreifen!

  26. #100
    Oberstabsgefreiter
    Registriert seit
    17.09.2008
    Beiträge
    493


    Standard

    iometer nehmen und dann testen
    128k; 100% random; 100% write; align I/O on 128k
    256k; 100% random; 100% write; align I/O on 256k
    512k; 100% random; 100% write; align I/O on 512k
    1M; 100% random; 100% write; align I/O on 1M
    2M; 100% random; 100% write; align I/O on 2M
    4M; 100% random; 100% write; align I/O on 4M
    8M; 100% random; 100% write; align I/O on 8M
    16M; 100% random; 100% write; align I/O on 16M
    32M; 100% random; 100% write; align I/O on 32M

    die average I/O response time steigt zuerst langsam an. Ab einer bestimmsten Blockgröße (test x) verdoppelt sie sich dann immer im Vergleich zum vorherigen Blockgröße. Die Blockgröße bei test x ist die Größe der Eraseblocks.
    zb.
    1M Test: average I/O response time ca. 300ms
    2M Test: average I/O response time ca. 600ms
    4M Test: average I/O response time ca. 900ms
    8M Test: average I/O response time ca. 1200ms <----- Größe der Eraseblocks = 8MB
    16M Test: average I/O response time ca. 2400ms
    32M Test: average I/O response time ca. 4800ms

    im Anhang als iometer pattern. Bin mir aber nicht sicher obs woanders läuft weil ich es händisch editiert habe.
    Angehängte Dateien Angehängte Dateien
    Geändert von antiram (10.01.09 um 23:05 Uhr)

Seite 4 von 52 ErsteErste 1 2 3 4 5 6 7 8 14 ... LetzteLetzte

LinkBacks (?)

  1. 22.05.11, 10:42
  2. 21.03.11, 22:34
  3. 19.02.11, 16:30
  4. 08.02.11, 18:28
  5. 11.01.11, 23:01
  6. 09.01.11, 19:25
  7. 09.01.11, 13:35
  8. 06.01.11, 19:33
  9. 15.12.10, 19:31
  10. 11.12.10, 01:31
  11. 10.12.10, 22:47
  12. 10.12.10, 16:35
  13. 25.08.10, 01:34
  14. 30.07.10, 09:51
  15. 04.07.10, 08:49
  16. 29.06.10, 20:00
  17. 15.05.10, 11:30
  18. 11.05.10, 11:00
  19. 12.03.10, 15:45
  20. 11.03.10, 21:53
  21. 09.03.10, 16:04
  22. 08.03.10, 22:52
  23. 07.03.10, 11:32
  24. 02.03.10, 13:26
  25. 02.03.10, 11:51
  26. 28.02.10, 23:54
  27. 27.02.10, 15:21
  28. 26.02.10, 22:50
  29. 23.02.10, 10:32
  30. 23.02.10, 10:31
  31. 23.02.10, 10:22

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •