Zweimal cat /dev/urandom > /dev/null zwingt den 8core in die Knie?

Diskutiere das Thema Zweimal cat /dev/urandom > /dev/null zwingt den 8core in die Knie? im Forum Mac Pro, Power Mac, Cube

  1. s_herzog

    s_herzog Thread Starter Mitglied

    Beiträge:
    3.312
    Zustimmungen:
    156
    Mitglied seit:
    11.04.2006
    Moin zusammen,

    ich bin jetzt doch ein wenig schockiert.

    Heute mal mit Acrobat 6 in Rosetta 4 Gig TIFF-Bilder zu nem PDF zusammenkleben lassen -> Mac Pro kommt ins Stocken, Finder zeigt den Beachball, iTunes setzt kurz aus.

    Das kanns ja wohl nicht sein, Rosetta kann doch eh nur einen Kern und was machen die sieben anderen??

    Wollt ich dann nicht dabei belassen und dachte mir, jo, jetzt lasten wir mal ein paar Kerne aus.

    Ins Terminal gegangen, cat /dev/urandom > /dev/null, OK, einer dreht durch auf 100%.

    Zweiten Tab aufgemacht, cat /dev/urandom > /dev/null, WHOHO, das System kommt ins Stocken, Musik stockt, CPU wird nur ein Kern gescheduled...

    Was ist denn das bitte für ein Mist? Wird /dev/urandom etwa single-threaded befüllt?

    Und wo gilt das dann noch überall?

    Wie sollen Anwendungen denn geschickt mehrere Kerne nutzen, wenn das bescheidene UNIX-Userland das offenbar schon nicht kann?

    Das soll jetzt keine Hexenjagd oder Geflame geben, aber ich finde diese Effekte sehr merkwürdig.
     
  2. _ebm_

    _ebm_ Mitglied

    Beiträge:
    2.076
    Zustimmungen:
    202
    Mitglied seit:
    19.01.2008
    Was hat das denn mit dem Userland zutun? Die Anwendung muss dafür gebacken sein! Eines wundert mich allerdings schon. Wieso lagert er die Tasks nicht auf die anderen Kerne aus. Deine kurzen Tests wanderten bei mir übrigens zwischen den Kernen hin und her (C2D MBP).
     
  3. s_herzog

    s_herzog Thread Starter Mitglied

    Beiträge:
    3.312
    Zustimmungen:
    156
    Mitglied seit:
    11.04.2006
    Eine single-threaded Anwendung wird vom OS auch auf einen bestimmten Kern gelegt.

    Die zwei cat /dev/urandom blieben bei mir aber zusammen auf einem Kern, das macht mich stutzig, eventuell wird /dev/urandom eben vom Kernel nur in einem Thread gefüllt....

    [​IMG]

    Die beiden cats bleiben dauernd unter 100% zusammen, werden also immer auf einem Kern gescheduled.

    Wenn nun auf den anderen Kernen kaum Last ist, stockt z.B. mein iTunes... wie gerade jetzt...
     
  4. _ebm_

    _ebm_ Mitglied

    Beiträge:
    2.076
    Zustimmungen:
    202
    Mitglied seit:
    19.01.2008
    Ich hab das eben nochmal überprüft. /dev/urandom wird offensichtlich nur von einem Thread befüllt. Ich hab die beiden calls in einem Terminal gestartet und er wechselt schön zwischen ihnen hin und her, in summe 100%. Dabei wechselt er auch zwischen den Kernen. Wenn du das mit zwei verschiedenen Terminals aufrufst, hat der Terminal priorität, der im Fokus steht. Offensichtlich arbeitet der Scheduler von MacOS nicht fair sondern priorisierend auf dem Programm im Fokus. Der bekommt den ersten Kern und alle anderen Anwendungen treten in den Hintergrund. Das erklärt auch das Stuckern von iTunes...
     
  5. s_herzog

    s_herzog Thread Starter Mitglied

    Beiträge:
    3.312
    Zustimmungen:
    156
    Mitglied seit:
    11.04.2006
    Hm, ok, also das Stockern von iTunes ist wohl doch nur das Netzwerk, es stockt einmal pro Stunde...raten wir mal, was das sein könnte :p

    OK, also nehme zurück, dass das System zum stocken gebracht wird, aber das Scheduling zweier cat, die aus /dev/urandom lesen, ist dennoch komisch... Allerdings könnte es auch zu erklären sein, dass /dev/urandom jeweils immer nur einmal zum Lesen zur Verfügung steht, ist ja immerhin "pseudo"-Filesystem....
     
  6. Zapfenzieher

    Zapfenzieher Mitglied

    Beiträge:
    356
    Zustimmungen:
    20
    Mitglied seit:
    31.01.2007
  7. _ebm_

    _ebm_ Mitglied

    Beiträge:
    2.076
    Zustimmungen:
    202
    Mitglied seit:
    19.01.2008
    Das ist definitiv so. /dev/random ist ein Character Device, welches sequentiell Zeichen ausspuckt. Das Programm mit der höheren Priorität bekommt dann eben das nächste Zeichen. Dein Benchmark war also denkbar ungeeignet, um die Multithreading-Fähigkeiten vom XNU-Kern zu testen.
     
  8. was dagegen ?

    was dagegen ? Mitglied

    Beiträge:
    323
    Zustimmungen:
    7
    Mitglied seit:
    17.11.2006
    'nen zweiten Seed und schon hast Du einen zweiten PRNG – und selbst wenn Du den selben in mehreren Threads hättest, würdest Du halt "abwechselnd" die Zufallszahlen kriegen
     
  9. Zapfenzieher

    Zapfenzieher Mitglied

    Beiträge:
    356
    Zustimmungen:
    20
    Mitglied seit:
    31.01.2007
    /dev/urandom verwendet die Zufallsdaten von /dev/random. Nur gibt dir /dev/urandom weiter Zufallsdaten auch wenn die Entropie gering ist.
     
  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Akzeptieren Weitere Informationen...