Abo
  1. Foren
  2. Kommentare (alt, bis 13.1.2005)
  3. Software
  4. Betriebssysteme

Neuer Linux-Kernel verbessert IDE-Performance

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Neuer Linux-Kernel verbessert IDE-Performance

    Autor: Golem.de 16.06.03 - 09:30

    Nach mehr als sechs Monaten Entwicklungszeit hat Marcelo Tosatti am Freitag, den 13. Juni, den Linux-Kernel in der Version 2.4.21 veröffentlicht. Dieser verfügt neben zahlreichen weiteren Neuerungen über ein überarbeitetes IDE-Subsystem, das vor allem unter großer Last eine spürbar bessere Performance verspricht.

    https://www.golem.de/0306/25940.html

  2. Re: Neuer Linux-Kernel verbessert IDE-Performance

    Autor: Alex 16.06.03 - 10:05

    Werden damit auch mehr IDE-Chipsätze unterstützt? Suche immernoch nach einer Unterstützung für mein Notebook Samsung P10 (Intel 845MP Chipsatz).

    Gruß

  3. Re: Neuer Linux-Kernel verbessert IDE-Performance

    Autor: Treibholz 16.06.03 - 10:14

    Alle Intel-IDE-Chipsätze werden unterstützt und wurden schon immer unterstützt mit dem Intel PIIXn Treiber.

    Treibholz

  4. wann kommt der 2.6er kernel

    Autor: Pinocchino 16.06.03 - 10:26

    weis jemand wann die kernel version 2.6 freigegeben wird?

  5. Re: wann kommt der 2.6er kernel

    Autor: Suomynona 16.06.03 - 10:56

    wennn du nicht warten kannst, dannn experimentiere mit dem 2.5.70, vielleicht bietet dieser ja schon was du suchtst...

    Wenn er es dir nicht bietet, dann musst du warten oder trotzdem den 2.5er nehmen und daran mitarbeiten, damit der 2.6er schneller fertig wird.

    Einer der Gruende warum die Entwicklung so gemaechlich ablaeuft ist die Tatsache, dass der 2.2 und 2.4 bereits so gut sind, dass die Mehrzahl der Benutzer gar kein Beduerfnis haben den Neuen zu testen. Das war bereits beim Abschluss der 2.3er-Linie so und wird sich beim 2.5er genauso hinziehen, hoechstens ein bischen abgeschwaecht durch den Trend Linux auf dem Desktop. Denn nur dort machen Dinge wie ACPI, Bluetooth, die allerneusten Treiber fuer die aktuelleste Hardware usw. wirklich Sinn.
    Die kleinen Serverhersteller wuerden am liebsten auch noch die naechsten 5Jahre ihre Systeme auf P3-Basis bauen und trauern jetzt schon, dass diese Zeiten bald vorbei sind. Kurz die koennten theoretisch auch noch gut mit dem Kernel-2.2 leben.

  6. Re: wann kommt der 2.6er kernel

    Autor: SEth 16.06.03 - 12:25

    da hast du wohl recht...

    ich habe leider keine zeit nen 2.5 er zu testen und daher ists eher doof bei mir.
    aber leute die viel zeit haben und dauernd meckern sollten mal testen ...

  7. Re: wann kommt der 2.6er kernel

    Autor: Jonny 16.06.03 - 12:26

    Hi!

    Kann mir jemand auf die Schnelle sagen, ob es einen Kernel gibt, der den KT400 _wirklich_ unterstützt??

    Danke im Vorraus!

  8. Endlich!

    Autor: Struwwelpeter 16.06.03 - 13:52

    Endlich!

    Es wurde ja auch langsam Zeit.

    Die IDE-Performance unter Linux war in der Vergangenheit dermaßen lahm, dass man es gar nicht einsetzen konnte.

    Hoffentlich hält der Patch was versprochen wird.


    Viele Grüße Euer Struwwelpeter

  9. Und es geht doch....

    Autor: Nico 16.06.03 - 16:28

    Hi,
    ... das kann ich nicht ganz nachvollziehen.
    Wenn man bedenkt, das es unter Linux mit einem PIII 500 möglich ist, Videodaten mit einer Auflösung von bis zu 720x568 (nicht Encoded) ohne "dropped Frames" aufzunehmen, verstehe ich diese Aussage nicht ganz.
    Ein großes Problem ist auch die falsche Wahl des Dateisystems. Viele User arbeiten immer noch mit Ext2. Am besten ist es auf Ext2 - RaiserFs aufzusetzen, das über die verbesserte Performance hinaus auch eine höhere Datensicherheit bietet.
    Da "fragmentierte Daten" auf diesem Dateisystem so gut wie keine Rolle mehr spielen, steigert sich auch dementsprechend die Performance.
    Wichtig ist es auch, das die Swap Partition richtig angelegt und ordnungsgemäß eingebunden wurde.
    Defaultwert einer Swap Partition ist immer die vorhandene Ram - Speicherkapazität.
    Bsp. Bei einer Ramgröße von 256 MB sollte man einem Swap Bereich, die selbe Größe zuordnen.
    Hat man viele kleine Dateien, sollte der Swap Bereich am Anfang der Platte angebracht werden, bei Dateimonstern ist der hintere Bereich etwas besser geeignet. Da Festplatten nach einer gewissen Inaktivitätszeit die Head´s parken, ist die Zugriffszeit somit auch etwas besser.

    Mit diversen überlegten Optimierungen, lassen sich unter Linux Geschwindigkeitszuwächse von weit mehr als über 100 % herausholen. Oftmals ist aus Sicherheitsgründen der "Write Back" Modus ausgeschaltet und zwecks Kompatibilitätsprobleme bleibt u.a. der DMA Modus deaktiviert.
    (hatte ich ehrlich gesagt aber noch nie Probleme... egal mit welchen neueren Platten oder Chipsätzen)
    Dabei spielt es keine Rolle, welche Werte im Bios eingestellt sind. Die Funktionen werden vom Linux Kernel "Overrided" so das es wenig Sinn macht, hier die Einstellungen zu modifizieren.
    (Am besten ist es so oder so die Werte auf Auto zu belassen)
    Viele Anwender betreiben ihre Platten unbewusst im PIO4 Mode und würden sich wundern, "was" ihre Kiste nach einer Optimierung noch so alles draufhat.
    In der SuSE Distr. befinden sich diverse Tools, mit denen die Einstellungen vorgenommen werden können.(Unter Yast, z.B. Kernel Tweaker)
    Vorsicht: Wer hier keine Ahnung hat, (sowie auch unter Windows mit Tweakerprogr., das spielt in diesem Moment wirklich keine Rolle) sollte dringend seine Finger davon lassen. Eine falsche Einstellung bewirkt Systemstillstände, die nicht mehr ohne weiteres rückgängig gemacht werden können.
    Sollte sich jemand jedoch seiner Sache sicher sein, wäre es von Vorteil seinem System noch einiges an verstecktem Potential zu entlocken.


    ~Regards~

  10. Re: Und es geht doch....

    Autor: John Doe 16.06.03 - 18:17

    Mann was laberst du da? Auf ext2 Raiserfs aufsetzen? Was soll das sein? R_e_iserfs ist unabhäng von ext2 und ersetzt selbiges. Write back modus? DMA default deaktiviert? Du redest wirr und hast URalte Infos. Aber: Wenn man das wireless RAM im UdSSR-Modus demoduliert, kompiliert die Library im Vollduplex-Glasfasermodus.

  11. Re: Endlich!

    Autor: Philipp 16.06.03 - 18:25

    Ist das Problem mit dem Rückfall in Pio bei Blockgrößen ungleich 2048 damit nicht mehr existent?

    Gruß
    Philipp

  12. Re: wann kommt der 2.6er kernel

    Autor: Mo 16.06.03 - 18:26

    http://www.linux-community.de/Neues/story?storyid=4263

  13. Re: Endlich!

    Autor: Linux-phased 17.06.03 - 00:31

    Also ich weis nicht wie du darauf kommst, aber Testwerte meiner 60GB WD Platte unter Windows und Linux zeigten bei mir immer schon identische Werte.

    Darüber hinaus, macht wie schon von jemanden gesagt die Wahl des Dateisystems einiges aus.
    Bei Inktomi wurden Tests unter Linux (kernel 2.4.20) mit einem 3TB System durchgeführt, was zeigte, das XFS die beste Performance und Sicherheit bietet.

  14. Re: Und es geht doch....

    Autor: radookee 17.06.03 - 10:21

    mwahaha der war gut :D

  15. Re: wann kommt der 2.6er kernel

    Autor: Henk 17.06.03 - 12:33

    Bei uns stehen auch noch eine Reihe Server mit P3 500ern rum, die mit einem 2.2er ihre Arbeit zuverlässig erledigen. Bis auf einen laufen die jetzt schon seit mehr als zwei Jahren ohne Unterbrechung oder gar Absturz, und werden das wohl auch noch ein paar weitere Jahre so tun.
    Wenn ich das mit unserem einzigen Windows-Server den wir wegen unserer Druckmaschine brauchen vergleichen, ist das Wahnsinn. Das ist ein Dual-P3-800 mit 2GB RAM (die anderen haben nur 256MB), und der braucht für das reine Weiterleiten der Druckdaten mehr als doppelt solange wie der eigentliche Druckserver, der die Daten umwandeln muss. Und ein- bis zweimal täglich Bluescreen und damit Druckpause ist auch Standard.
    > Die kleinen Serverhersteller wuerden am liebsten
    > auch noch die naechsten 5Jahre ihre Systeme auf
    > P3-Basis bauen und trauern jetzt schon, dass
    > diese Zeiten bald vorbei sind. Kurz die koennten
    > theoretisch auch noch gut mit dem Kernel-2.2
    > leben.

  16. Re: Und es geht doch....

    Autor: Nico 17.06.03 - 13:21

    Ein Beispiel, wie jemand seine Dummheit auch noch veröffentlicht.....
    Man oh man, lern mal etwas über Linux du Troll und dann lasse deine Sose nicht in derartigen Foren los.... Mister DAU. (passt fast schon zu deinem Pseudonym)

    Die Partitions-Identifikationsnummern von Linux ist auch unter Raiser immer noch 83.
    Raiser setzt auf ext2 (genau so wie Ext3) auf und ist so gesehen ein Filesystem "PlugIn"
    http://www.namesys.com/
    Warscheinlich kannst du bei deinem Wissensstand auch kein Englisch, so das sich dieser Link wohl auch erübrigt.
    Da du von DMA Einstellungen genauso wenig weist wie über Swap Partitionen, erübrigt sich wohl der Rest.

    Mein Tipp:
    Bleib bei deinem Windows und lass Linux User in Ruhe.... oder versuche mal etwas Konstruktives von dir zu geben. Das ist hier kein Chatraum.

  17. Re: Und es geht doch....

    Autor: . 17.06.03 - 19:07

    Lieber Nico,

    >
    > [Beschimpfungen gelöscht]
    >
    > Die Partitions-Identifikationsnummern von Linux
    > ist auch unter Raiser immer noch 83.

    "Raiser" schreibt man Reiser mit "ei" nicht mit "ai". Die Partitionsnummer hat nichts mit dem Dateisystem zu tun. Das Dein fdisk unter Linux bei 83 evtl. ein Linux ext2 ausgiebt, heißt noch lange nicht, das dies auch "auf ext2 aufsetzt". Im MBR steht halt 83 und ist in der fdisk Tabelle Linux zugeordnet, das früher zumeist mit ext2 formatiert wurde.

    > Raiser setzt auf ext2 (genau so wie Ext3) auf
    > und ist so gesehen ein Filesystem "PlugIn"
    > http://www.namesys.com/

    *räusper*. Du hast Dir die Seite mal durchgelesen? Du beziehst Dich nicht zufällig auf "ReiserFS is a filesystem using a plug-in based object oriented variant on classical balanced tree algorithms. The results when compared to the ext2fs conventional block allocation based filesystem [...]" oder?
    Wenn ja denn würde ich Deine Aussage nochmals überdenken...
    Der Author beschreibt den prinzipiellen Aufbau im Vergleich zu ext2. Mit Plug-In ist gemeint, das das Dateisystem auf einer Variante der Block-Belegungs Dateisysteme beruht, wie es die meinsten Dateisysteme auch tun (ext2, fat) und auf die Programmierschnittstellen des Kernels zurückgreifen, die eine Verteilung auf solche Blocks vornehmen. Dies hat aber nichts mit ext2 zu tun.

    > [Englisch Flame gelöscht]

    > Da du von DMA Einstellungen genauso wenig weist
    > wie über Swap Partitionen, erübrigt sich wohl
    > der Rest.

    Erläutere uns das doch mal bitte genauer. Was für DMA Einstellungen meinst Du? hdparm -d1 /dev/hda etwa? Und was für geniale Swap Tricks kannst Du uns verraten?

    > [Anderer Flame gelöscht]

  18. Re: Und es geht doch....

    Autor: . 17.06.03 - 20:26

    > ... das kann ich nicht ganz nachvollziehen.
    > Wenn man bedenkt, das es unter Linux mit einem
    > PIII 500 möglich ist, Videodaten mit einer
    > Auflösung von bis zu 720x568 (nicht Encoded)
    > ohne "dropped Frames" aufzunehmen, verstehe ich
    > diese Aussage nicht ganz.

    Du willst mit dem Beispiel wohl ausdrücken, das Du konstant ~19,5 MB/s auf die Festplatte schreiben kannst? Die CPU hat bei einem DMA- im Gegensatz zu dem PIO-Transfer einen sehr untergeordneten Einfluss. Insofern ist die Angabe "PIII 500" etwas befremdlich. Ich vermute mal Du willst ausdrücken, das selbst auf älteren Systemen mit eingeschaltetem DMA-Modus auch unter Linux eine sehr gute IDE-Performance zu bewerkstellingen ist?
    Die Auflösung von D1- repektive DV-Material des PAL Formates hat 720x576 Bildpunkte, nicht 720x568. Für die Berechnung Deiner Angaben fehlen zudem die pro Sekunde aufgenommenen (Halb)-Bilder von i.d.R. 50 Feldern/s bei PAL und die verwendete Anzahl der Bits pro Pixel (bei YUV 4:2:2 16 Bits). Auch die Verwendung von unkomprimierten Material ist wohl nicht die Regel, denn DV mit ~3,5 MB/s hat schon eine sehr gute Qualtität.

    > Ein großes Problem ist auch die falsche Wahl des
    > Dateisystems. Viele User arbeiten immer noch mit
    > Ext2. Am besten ist es auf Ext2 - RaiserFs
    > aufzusetzen, das über die verbesserte
    > Performance hinaus auch eine höhere
    > Datensicherheit bietet.

    Diese Aussage ist nicht korrekt. Ein Journaling-Filesystem hat eine bis zu 15% schlechtere Performance als eines ohne selbiges. Die begründet sich aus dem zusätzlichen Verwaltungsaufwand des mitzuschreibenden Journales. Zudem hat bei obigem Beispiel einer einzelnen Datei, das Dateisystem einen verschwindent geringen Einfluss auf die zu erwartende Performance. Ebenso hat ein JFS keine höhere "Datensicherheit", also keine Redundanz der Daten, sondern nur eine höhere Datenkonsistenz der Verwanltungsinformationen.

    > Da "fragmentierte Daten" auf diesem Dateisystem
    > so gut wie keine Rolle mehr spielen, steigert
    > sich auch dementsprechend die Performance.

    Ob ext2, ext3, ReiserFS spielt keine Rolle. Diese haben alle mehr oder weniger unter Fragmentierung zu leiden. Nur im Vergleich mit dem FAT Dateisystem von Microsoft kann man behaupten, das es eine geringere Rolle spielt, wenn Dateien fragmentiert sind. Das Problem bleibt aber prinzipbedingt auch bei den moderneren (JFS-) Dateisystem bestehen.

    > Wichtig ist es auch, das die Swap Partition
    > richtig angelegt und ordnungsgemäß eingebunden
    > wurde.

    Wie legt man diese falsch an? Am langsameren Ende (dem Innenbereich der) Platte? Zu groß zu klein?

    > Hat man viele kleine Dateien, sollte der Swap
    > Bereich am Anfang der Platte angebracht werden,

    Nanu? Du weißt was ein Swap-Bereich ist? Und Du weist das darin nicht benötigte Speicherseiten des RAMs ausgelagert werden? Und Dir ist bewusst, das dies nichts mit "vielen kleinen Dateien" zu tun hat?

    > bei Dateimonstern ist der hintere Bereich etwas
    > besser geeignet. Da Festplatten nach einer
    > gewissen Inaktivitätszeit die Head´s parken, ist
    > die Zugriffszeit somit auch etwas besser.

    Oh jeh. Dir ist bewusst, das die Festplatte im "hinteren Bereich" langsamer ist, als vorne? Und Du weißst was für einen geringen Einfluß eine einzelne Kopfbewegung der HD im Bezug auf die Swap-Partition hat? Und Du weißt das die Platten einen eigenen Cache haben, der solche Dinge oft wegpuffern kann?

    > Mit diversen überlegten Optimierungen, lassen
    > sich unter Linux Geschwindigkeitszuwächse von
    > weit mehr als über 100 % herausholen. Oftmals

    100%? Was ist das denn für ein aus der Luft gegriffener Wert? Denn wenn...

    > ist aus Sicherheitsgründen der "Write Back"
    > Modus ausgeschaltet und zwecks
    > Kompatibilitätsprobleme bleibt u.a. der DMA
    > Modus deaktiviert.

    ...der DMA Modus aktiviert ist, kann die Platte gut und gerne von z.B. 1500 KB/s auf über 30.000 KB/s hochschnellen. Das sind schlappe 2000%. Hingegen kann ein "Write Back" Puffer (damit meint er wohl einen Festplattencache im RAM, der für schreibende Aktionen reserviert ist) bei zumeist lesenden Operationen nichts (0% mehr) bringen. Wobei erziehle ich also in der Praxis 100% mehr?

    > (hatte ich ehrlich gesagt aber noch nie
    > Probleme... egal mit welchen neueren Platten
    > oder Chipsätzen)

    Wenig Erfahrung. Das erklärt so manches. Wenn Du schon mit Mainboards von Supermicro gearbeitet hättest, dann wüsstest Du warum.

    > Viele Anwender betreiben ihre Platten unbewusst
    > im PIO4 Mode und würden sich wundern, "was" ihre
    > Kiste nach einer Optimierung noch so alles
    > draufhat.

    Da stimme ich Dir voll und ganz zu :-)! Neue Distributionen (wie die genannte SuSE) schalten aber häufig den DMA Modus der IDE Platten von sich aus ein.

    > Sollte sich jemand jedoch seiner Sache sicher
    > sein, wäre es von Vorteil seinem System noch
    > einiges an verstecktem Potential zu entlocken.

    Klingt wie der Fazit eines Artikels "Mein Linux leichtgemacht".

  19. Re: Und es geht doch....

    Autor: Nico 17.06.03 - 23:39


    "Du willst mit dem Beispiel wohl ausdrücken, das Du konstant ~19,5 MB/s auf die
    Festplatte schreiben kannst? Die CPU hat bei einem DMA- im Gegensatz zu dem
    PIO-Transfer einen sehr untergeordneten Einfluss. Insofern ist die Angabe "PIII 500"
    etwas befremdlich. Ich vermute mal Du willst ausdrücken, das selbst auf älteren
    Systemen mit eingeschaltetem DMA-Modus auch unter Linux eine sehr gute
    IDE-Performance zu bewerkstellingen ist?"

    ***
    Genau das wollte ich bewerkstelligen. Danke für die so gute DirektMemoryAccess
    Erklärung.
    Vieleicht hätte ich noch die Framebufferadressierung, PCI Latency Clocks und die
    CAS/RAS Parameter noch mit eintragen sollen.Wenn du das alles so gut weist, wüsstest
    du auch, das ein DMA Transfehr ohne einen vorangehenden Interrupt nicht erfolgt.Da
    dieser immer noch von der CPU verarbeitet werden muss, kannst du nicht hier
    behaupten das z.B. ein P200 die gleiche Interrupt Verarbeitungszeit aufweist als z.B. ein
    1000er.Wie du sicher auch weist, wird der Stack sehr stark beansprucht und dieser
    befindet sich nunmal in der CPU. IDE Festplatten werden nicht von einem "intelligenten
    Controller" angesteuert wie jener der sich z.B. in der SCSI Technik befindet. Somit sind
    keine mehrfach "Multi Command" Bus Master Zyklen ohne CPU Hilfe möglich.
    Die CPU muss sozusagen vor jedem BusMaster Zugriff eine "Single"
    Bereichsadressierung an den "Controller" übergeben. Dies erklärt auch die
    Transfehreinbrüche bei stark belasteten CPUs mit IDE "Controllern".
    Über Bios und INT13 werden wir uns jetzt hier bestimmt nicht unterhalten.
    Lese das bitte 2 mal, bevor du wieder dein ironisches Getue an die Spitze treibst.
    ***

    >>>"Diese Aussage ist nicht korrekt. Ein Journaling-Filesystem hat eine bis zu 15%
    schlechtere Performance als eines ohne selbiges. Die begründet sich aus dem
    zusätzlichen Verwaltungsaufwand des mitzuschreibenden Journales. Zudem hat bei
    obigem Beispiel einer einzelnen Datei, das Dateisystem einen verschwindent geringen
    Einfluss auf die zu erwartende Performance. Ebenso hat ein JFS keine höhere
    "Datensicherheit", also keine Redundanz der Daten, sondern nur eine höhere
    Datenkonsistenz der Verwanltungsinformationen."<<<

    ***
    Reiser (Sorry das ich das falschgeschrieben hatte.... an alle Rechtschreibwächter..Danke..)
    verwendet den gesamten Bereich eines Blocks für Daten und kann somit die
    Datendichte emens erhöhen. Das sich dadurch eine höhere Transfehrrate ergibt, brauche ich dir wohl nicht zu erklären. Eine Original Angabe des Entwicklers:
    "We have fewer worst case performance scenarios than other filesystems and generally
    better overall performance."
    Mehr habe ich auch wohl nicht wiedergegeben.
    ***
    >>>"Ob ext2, ext3, ReiserFS spielt keine Rolle. Diese haben alle mehr oder weniger
    unter Fragmentierung zu leiden. Nur im Vergleich mit dem FAT Dateisystem von
    Microsoft kann man behaupten, das es eine geringere Rolle spielt, wenn Dateien
    fragmentiert sind. Das Problem bleibt aber prinzipbedingt auch bei den moderneren
    (JFS-) Dateisystem bestehen."<<<

    ***
    Sicher, nur ist Reiser eben in der Lage "leere" Blöcke durch das Journaling
    "intelligenter" zu verwalten und zu beschreiben. Wenn du noch einmal meine
    Aussage überprüfst, wirst du feststellen, das ich die Fragmentierung nicht ausschließe.
    ****
    >>> "Wie legt man diese falsch an? Am langsameren Ende (dem Innenbereich der)
    Platte? Zu groß zu klein? <<<
    ****
    Oh, Sorry. Du Verstehst meine Aussage, kannst dich aber der Ironie nicht entziehen...?
    Also gut: Überhaupt keine Swap Datei, in der Fstab nicht eingetragen oder was du dir
    noch so alles darunter vorstellst. Das bleibt dir überlassen.
    ****
    >>>"Nanu? Du weißt was ein Swap-Bereich ist? Und Du weist das darin nicht benötigte
    Speicherseiten des RAMs ausgelagert werden? Und Dir ist bewusst, das dies nichts mit
    "vielen kleinen Dateien" zu tun hat?"<<<
    ****
    Entschuldige bitte, das ich mich so "unverständlich" ausdrücke. Dennoch werde ich den
    Gedanken nicht los und frage mich, ob du wirklich so beschränkt bist, oder dich hier nur
    aufpusten willst.
    In der FS Partition. Viele kleine Dateien in der FS Partition..Erstes Szenario: Durch die
    Rekalibrierung von IDE Festplatten muss der Kopf den Swap Bereich immer wieder
    Überspringen um an die höheren Spuren zu gelangen.Da in IDE Festplatten kein
    termischer Rekalibrationsprozessor (wie z.B. unter SCSI) existiert, müssen IDE
    Festplatten sich immer wieder rekalibrieren.Befinden sich viele kleinere Dateien auf
    einer Festplatte, werden die Köpfe stärker beansprucht. Dadurch erhöht sich auch die
    Festplattentemperatur und somit sinkt auch die Transfehrrate.Auch stark fragmentierte Daten
    rufen diesen Effekt hervor. Gut unter Reiser ist das eher unnötig und.... vielleicht war ich mit dieser Aussage wirklich etwas kleinlich.
    Das Problem tritt vielmehr im RAID Bereich auf, wobei sich diese Eigenschaft, unter
    anderem !!!! sehr störend auswirkt.

    ****
    >>>"...der DMA Modus aktiviert ist, kann die Platte gut und gerne von z.B. 1500 KB/s auf
    über 30.000 KB/s hochschnellen. Das sind schlappe 2000%. Hingegen kann ein "Write
    Back" Puffer (damit meint er wohl einen Festplattencache im RAM, der für schreibende
    Aktionen reserviert ist) bei zumeist lesenden Operationen nichts (0% mehr) bringen.
    Wobei erziehle ich also in der Praxis 100% mehr?"<<<<<<
    ******


    Hast du ein Verständnissproblem ?? Du sagst es: Fürs schreiben. Habe ich mich aufs
    LESEN beschränkt ??? Kurz: Schalte deinen Write Back Modus aus, so das sich Anwendungen anstatt um ihre eigentliche Aufgabe zu kümmern lieber auf ein Write ACK der Festplatte warten.
    Du brauchst Erklärungen zwecks Write Back. ?? Das ausführende Programm übergibt die zu speichernden Daten an einen weiteren Prozess, der diese dann verzögert >selbstständig< abspeichert. Die Anwendung erhällt kein ACK von der "Hardware" sondern vom Treiber.Dieser schreibt daraufhin die Daten dann selbstständig auf die Hardware. Nachteil: Bei einem Stromausfall gehen die gepufferten Daten verloren.
    Ich bin mir sehr sicher, das du das wustest, oder gar noch besser erklären kannst.
    Es sei dir gegönnt.
    ***************

    Traurig finde ich die Tatsache, das in diesem Forum sehr weniges, vor allem Wissenswertes, zu finden ist. Die meisten Postigs bestehen oftmals aus absolut unnötigen Aussagen, versucht auch nur jemand mal "Ansatzweise" etwas zu erklären, wird er bis auf das äußerste beleidigt. Erst wird man mit "Flames" bombardiert, wehrt man sich dagegen, wird man anschließend selbst als "Flamer" hingestellt.
    Anstatt die Unklarheiten im einem sachlichen Ton zu klären, wird oftmals ein ironisches- vor allem angeberisches- Getue an den Tag gelegt, das man schon gar nicht glauben mag. Fast gewinnt man den Eindruck, das einige User regelrecht auf "Provozieren" aus sind als selbst mal etwas lesenswertes zu posten.
    Klar , das man sich selbst da schon nicht mehr beherschen kann und den gleichen Ton anlegt.

    Wenn jemand mit dem Satz "Was schreibst du da für eine Sose" ein Kritikgespräch anfängt und sich danach wundert, das man nicht gerade freundlich darauf reagiert, geht der jenige auch noch einen Schritt weiter und erklärt das "er" das Opfer ist und emens "Geflamed" wurde.
    Hochachtung Mister Doe.


    Nun zu allen Online Forumswächter:
    Findet ihr Druck, Rechtschreib, oder Grammatikfehler bitte....
    behaltet sie...

    ~regards~

  20. Re: Und es geht doch....

    Autor: . 18.06.03 - 20:24

    > vorangehenden Interrupt nicht erfolgt.Da
    > dieser immer noch von der CPU verarbeitet werden
    > muss, kannst du nicht hier
    > behaupten das z.B. ein P200 die gleiche
    > Interrupt Verarbeitungszeit aufweist als z.B. ein
    > 1000er.

    Da aber die Verarbeitungszeit für diesen winzigen Handler ein so verschwindent geringen Teil der Gesammtbelastung ausmacht, ist das trotzdem nicht sonderlich relevant. Und ja tatsächlich ist eine 1 GHz CPU in der Verarbeitung schneller als ein 200 MHz. Sogar bei der Datenübertragung bei schnellen Platten. Nichtsdestotrotz hat die CPU bei einem eingeschalteten DMA Modus einen viel geringeren Anteil als Performance-Bremse, als in einem PIO Modus. Und darauf wollen wir doch hinaus nicht?

    > Wie du sicher auch weist, wird der Stack
    > sehr stark beansprucht und dieser
    > befindet sich nunmal in der CPU.

    Der Stack "befindet sich" genauso wie der Heap im RAM des Rechners, nicht in der CPU. In der CPU sind nur Register & 1st Level-Cache. Der Stack wird zur Laufzeit eines Programms im RAM alloziert.

    > IDE Festplatten
    > werden nicht von einem "intelligenten
    > Controller" angesteuert wie jener der sich z.B.
    > in der SCSI Technik befindet. Somit sind
    > keine mehrfach "Multi Command" Bus Master Zyklen
    > ohne CPU Hilfe möglich.

    Eine vergleichbare Technik gibt es bei den modernen UDMA Modi ebenfalls.

    > Die CPU muss sozusagen vor jedem BusMaster
    > Zugriff eine "Single"
    > Bereichsadressierung an den "Controller"
    > übergeben. Dies erklärt auch die
    > Transfehreinbrüche bei stark belasteten CPUs mit
    > IDE "Controllern".

    Und in dieser BEREICHSadressierung kann man eben einen ganzen Bereich auf einmal übertragen und damit die Anzahl der auszulösenden Adressierungen soweit minimieren, das die CPU kaum belastet wird. Insofern spielt die CPU Geschwindigkeit, insbesondere in den hohen Gefilten in denen wir uns bewegen (200 MHz und mehr) kaum eine Rolle.

    > Über Bios und INT13 werden wir uns jetzt hier
    > bestimmt nicht unterhalten.

    Warum denn nicht? Der Interrupt 13h ist ein sehr interessantes Thema und lohnt immer für ein Gespräch. Ärgerlich ist z.B. das die BIOS Hersteller es nicht für nötig erachten, die Funktionen des Int13h zum Einschalten des DMA Modus zu implementieren. Sonst könnte man sich eine Direktprogrammierung unter Umgehung der Int13h Schnittstelle (insbesondere unter DOS) sparen. Nur wenige, wie z.B. Norton Ghost, versteigen sich in den Bemühungen, mit mehr oder minder Erfolg, das direkt zu versuchen.

    > Reiser (Sorry das ich das falschgeschrieben
    > hatte.... an alle Rechtschreibwächter..Danke..)
    > verwendet den gesamten Bereich eines Blocks für
    > Daten und kann somit die
    > Datendichte emens erhöhen.

    Wenn ein Dateisystem einen "Block" nicht komplett beschreibt, dann liegt das i.d.R. daran, das dieses der letzte Block einer Datei ist. Insofern kann eine Steigerung der Datenübertragungsrate bei einem haufen sehr kleiner Dateien zu verzeichnen sein.

    > Entschuldige bitte, das ich mich so
    > "unverständlich" ausdrücke.

    Entschuldingung ist akzepiert. Kann jedem mal passieren. Die Aussage der vielen kleinen Dateien war in der Tat höchst missverständlich.

    > einer Festplatte, werden die Köpfe stärker
    > beansprucht. Dadurch erhöht sich auch die
    > Festplattentemperatur und somit sinkt auch die
    > Transfehrrate.Auch stark fragmentierte Daten
    > rufen diesen Effekt hervor. Gut unter Reiser ist

    Wirklich? Durch entsprechende Benchmarks kann bewiesen werden, das die Temperatur auf die Performance keinen signifikanten Einfluss hat, wenn dieser unter dem von Hersteller angegebenen Wert liegt. Bei Hitachi (früher IBM) IDE Festplatten i.d.R. <= 65° C.

    > Hast du ein Verständnissproblem ?? Du sagst es:
    > Fürs schreiben. Habe ich mich aufs
    > LESEN beschränkt ???

    Indirekt ja. Du gibts Peformance-Tipps für Linux Anfänger, die, da wirst Du mir sicher recht geben, im überwiegenden Teil ihrer Zeit lesende Operationen des Betriebssystems durchführen lassen. Insofern bringen solche Optimierungen keine "100%" Leistungssteigerungen.

    > Du brauchst Erklärungen zwecks Write Back. ??

    Danke nein.

    > Ich bin mir sehr sicher, das du das wustest,
    > oder gar noch besser erklären kannst.
    > Es sei dir gegönnt.

    Ja - danke trotzdem. Es lesen noch andere dieses Forum die sich gerne weiter bilden.

    > Traurig finde ich die Tatsache, das in diesem
    > Forum sehr weniges, vor allem Wissenswertes, zu
    > finden ist. Die meisten Postigs bestehen oftmals
    > aus absolut unnötigen Aussagen, versucht auch
    > nur jemand mal "Ansatzweise" etwas zu erklären,

    Absolut richtig. Korrekturen an falschen oder missverständlichen Aussagen sind jedoch in einem Forum durchaus erwünscht.

    > wird er bis auf das äußerste beleidigt. Erst
    > wird man mit "Flames" bombardiert, wehrt man
    > sich dagegen, wird man anschließend selbst als
    > "Flamer" hingestellt.

    Wenn andere Flamen, dann must Du doch nicht ebenfalls Flamen oder? Sprich: Mit gleicher Münze zurückzahlen? Meiner Meinung nach wird das Forum durch zurückbellen nicht besser.

    Wir bewundern alle Deine mühevolle Arbeit in diesem Forum und lesen gerne Deine fundierten Artikel. Ab und an ist es jedoch nötig, darauf sachlich zu antworten, um Missverständnisse auszuräumen. Ich hoffe Du verstehst unsere schwierige Lage: Einerseits der große Dank an Dich, andererseits die Pflicht, auf evtl. Fehlinformationen zu reagieren.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Landkreis Märkisch-Oderland, Seelow
  2. Franz Binder GmbH + Co. Elektrische Bauelemente KG, Neckarsulm
  3. THD - Technische Hochschule Deggendorf, Deggendorf
  4. BG BAU - Berufsgenossenschaft der Bauwirtschaft, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Logitech G502 Proteus Spectrum für 39€ und Nokia 3.2 DS 16 GB für 84,99€ - Bestpreise!)
  2. 179€ (Bestpreis - nach 40€ Direktabzug)
  3. 35€ (Bestpreis!)
  4. 199€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mädchen und IT: Fehler im System
Mädchen und IT
Fehler im System

Bis zu einem gewissen Alter sind Jungen und Mädchen gleichermaßen an Technik interessiert. Wenn es dann aber um die Berufswahl geht, entscheiden sich immer noch viel mehr junge Männer als Frauen für die IT. Ein wichtiger Grund dafür ist in der Schule zu suchen.
Von Valerie Lux

  1. IT an Schulen Intelligenter Stift zeichnet Handschrift von Schülern auf
  2. 5G Milliardenlücke beim Digitalpakt Schule droht
  3. Medienkompetenz Was, Ihr Kind kann nicht programmieren?

Linux-Kernel: Selbst Google ist unfähig, Android zu pflegen
Linux-Kernel
Selbst Google ist unfähig, Android zu pflegen

Bisher gilt Google als positive Ausnahme von der schlechten Update-Politik im Android-Ökosystem. Doch eine aktuelle Sicherheitslücke zeigt, dass auch Google die Updates nicht im Griff hat. Das ist selbst verschuldet und könnte vermieden werden.
Ein IMHO von Sebastian Grüner

  1. Kernel Linux bekommt Unterstützung für USB 4
  2. Kernel Vorschau auf Linux 5.4 bringt viele Security-Funktionen
  3. Linux Lockdown-Patches im Kernel aufgenommen

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

  1. Streaming: Apple und Netflix aus Auktion um South Park ausgestiegen
    Streaming
    Apple und Netflix aus Auktion um South Park ausgestiegen

    Insidern zufolge könnte der Bieterwettstreit um die Streaming-Rechte der Zeichentrickserie South Park bis zu 500 Millionen US-Dollar erreichen. Netflix soll sein Angebot bereits zurückgezogen haben. Auch Apple will wohl nicht mitbieten - was am jüngsten Verbot der Sendung in China liegen soll.

  2. Google: Vorabwiderspruch bei Street View wird überprüft
    Google
    Vorabwiderspruch bei Street View wird überprüft

    Googles Street View ist in Deutschland bisher kaum verfügbar, das Bildmaterial ist veraltet und Häuser sind oft verpixelt. Grund ist der Vorabwiderspruch gegen die Anzeige von Häusern, den viele Besitzer in Anspruch nahmen. Google lässt nun prüfen, ob neue Aufnahmen ohne Vorabwiderspruch möglich sind.

  3. Datenschutz: Zahl der Behördenzugriffe auf Konten steigt
    Datenschutz
    Zahl der Behördenzugriffe auf Konten steigt

    Behörden in Deutschland haben im bisherigen Jahresverlauf häufiger auf Konten von Bürgern zugegriffen als im Vorjahreszeitraum. Dem Bundesdatenschutzbeauftragten gefällt das nicht - er fordert eine Überprüfung der rechtlichen Grundlage.


  1. 15:12

  2. 14:18

  3. 13:21

  4. 12:56

  5. 11:20

  6. 14:43

  7. 13:45

  8. 12:49