Re: Uni-Processor vs. SMP workstations ...

Hi,

... hmm. interessant, mal auf seine eigene Mail zu antworten.
Aber hier kommt nochmal ein Nachtrag ...

Meine Athlon-Kiste hat nun 256 MB (noch ein DIMM aus der Firma
mitgenommen ;) ) und statt der ATA-Platte eine weitere IBM DNES
(die jedoch in der 9 GByte-Fassung).

    SCSI mittels 'sym0',
    IDE mit dem neuen ATA-Treiber, mangels AMD-Chipsatzunterstuetzung
        jedoch nur im PIO-Mode
    softupdates auf allen beteiligten Dateisystemen
    -current-Sourcen vom 17./19. Dezember
    in make.conf nur '-pipe' fuer den Compiler gesetzt

Damit stehen sich nun fuer ein
    make -j32 buildworld
gegenueber:

a) Athlon 700 128 MByte RAM
    /usr/src auf SCSI (U2W) DNES 18GB
    /usr/obj auf DTTA (IDE PIO4)

> > > 'time' meinte dazu:
> > > 1872.59s user 589.88s system 77% cpu 53:03.63 total
             ca. 31,2 min ca. 9,8 min

b) Athlon 700 128 MByte RAM
    /usr/src auf SCSI (U2W)) DNES 18GB
    /usr/obj auf derselben Platten (aber 'zylindermaessig' sogar
             relativ 'weit weg' von /usr/src)

> /usr/bin/time -lp make -j32 buildworld |& tee /build.log
> real 3086.98
    ca. 51,4 Min
> user 1878.86
    ca. 31,3 Min
> sys 573.67
    ca. 9,6 Min
    => ca. 80% CPU

> 11628 maximum resident set size
> 986 average shared memory size
> 949 average unshared data size
> 129 average unshared stack size
> 9979912 page reclaims
> 15246 page faults
> 819 swaps
> 52441 block input operations
> 9369 block output operations
> 0 messages sent
> 0 messages received
> 8 signals received
> 687098 voluntary context switches
> 461766 involuntary context switches

> > Ich würde eine RAM-Aufrüstung empfehlen. Und wirf das IDE-Ge-
> > rappel 'raus. :-)
> ... das mit der RAM-Aufruestung werd' ich heute abend mal versuchen; ich
> muss eh' gleich mal ins Buero rueber und zwei BSD-Installation fuer
> morgen frueh vorbereiten ...
(Exkurs: ... beide BSD-Server versehen nun wunschgemaess ihren Dienst
...)

c) Athlon 700 256 MByte RAM
    /usr/src auf SCSI (U2W) DNES 18GB
    /usr/obj auf SCSI (U2W) DNES 9GB

real 2879.24
    ca. 48 Min
user 1888.06
    ca. 31,5 Min
sys 585.90
    ca. 9,8 Min
    => ca. 86% CPU

     11656 maximum resident set size
       972 average shared memory size
       932 average unshared data size
       129 average unshared stack size
   9821756 page reclaims
      1788 page faults
:: aha, mehr RAM fast keine page faults mehr (eine 10er-Potenz besser ...)
         0 swaps
     40497 block input operations
:: weniger block inputs
      9107 block output operations
:: vernachlaessigbar weniger block outputs (logisch irgendwie ...)
         0 messages sent
         0 messages received
         7 signals received
    571362 voluntary context switches
    420998 involuntary context switches

Rueckschluss auf die taegliches Praxis .... (insbesondere, da ein
Dual Celeron 466, mit 128 MB und auf zwei IBM DNES 9GB verteilten
src- und obj-Dateisystem ebenfalls aehnliche 'real-Zeiten' abliefert):
    
    * der Engpass scheint wohl doch der I/O fuer das pure Lesen
      der Sourcen und Schreiben der object-files zu sein.
      Da der Unterschied zwischen 128 MB und 256 MB RAM nicht sooo gross ist,
      muss man offensichtlich soviel RAM in die Maschine stecken, dass
      man ca. 128 MB RAM _plus_ genuegend RAM fuer /usr/src auf einem
      MFS (jetzt ja wohl MD) Dateisystem haben. Mein /usr/src ist knapp
      270 MByte gross.
      Fuer ein 'buildworld'-Monster waeren das dann auch die - im Verlauf
      der Diskussion auch schon in Verbindung mit ca. 30 Minuten-Zeiten
      genannten 512 MByte ...

    * ein I/O-Subsystem mit Busmaster-DMA-Unterstuetzung lohnt sich
      (aber das wussten wir ja wohl alle schon vorher .. ;) )
      Ich glaube naemlich, dass sich die Zeitdifferenz und auch die
      interaktive Benutzbarkeit des Systems waehrend des 'buildworlds'
      der Konfigurationen mit SCSI-DNES oder IDE-DTTA als zweiter Platte
      nicht so sehr unterschieden haetten, wenn ein UDMA- statt des PIO-4-
      Modus genutzt worden waere.

    * _eine_ schnelle Platte fuer 'src' und 'obj' reicht offensichtlich
      fuer 'normal' ausgestattete Systeme; schliesslich laesst sich (s.o)
      die build-performance (und das laesst sich ja auch auf andere grosse
      Software-Systeme uebertragen) offensichtlich nur durch sehr viel mehr
      RAM signifikant erhoehen. ...
      (oder haltet Ihr dreieinhalb Minuten zwischen 48 und 51,4 Minuten fuer
      wirklich signifikant?)

    * dann hab' ich gerade nochmal das Verhaeltnis zwischen 'real'-Zeiten,
      den prozentualen Auslastungen der CPUs (zum Rausrechnen der
      I/O-Einfluesse) und 'kumulierten' (im SMP-Fall) Taktfrequenzen der
      beteiligten CPUs grob ueberschlagen.
      Hmmm, ... dabei kam (ja ich weiss, ... das ist mit einer derart geringen
      Anzahl von zu dem ungenauen Stichproben nicht wirklich aussagekraeftig)
      interessanterweise heraus, dass der Performance-Unterschied zwischen
      meinem alten dual PPro/200 und dem Athlon-700 nahezu linear zum
      Taktfrequenzunterschied ist.
      Das enttaeuscht mich nun doch etwas, ... fuer 'allround'-Anwendungen
      scheinen die inzwischen erreichten 'Verbesserungen')(?) der
      i386-Architektur kaum praktische Auswirkungen zu haben.
      (Nunja, ... ohne den architektonischen Fortschritt haette sich
      diese Linearitaet wahrscheinlich erst garnicht erreichen lassen. ...)

so, ... genug geblubbert ...

-Andreas

-- 
: Anti-Spam Petition:     http://www.politik-digital.de/spam/        :
: PGP-Key:                http://www.tse-online.de/~ab/public-key    :
: Key fingerprint:  12 13 EF BC 22 DD F4 B6  3C 25 C9 06 DC D3 45 9B :
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message