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

On Sun, Dec 19, 1999 at 01:14:09PM +0100, Andreas Braukmann wrote:
> Hi,
>
> On Sun, Dec 19, 1999 at 11:32:11AM +0100, Oliver Fromme wrote:
> > Bernd Walter wrote in list.de-bsd-chat:
> > > On Sat, Dec 18, 1999 at 01:55:26PM +0100, Andreas Braukmann wrote:
> > > [...]
> > > >
> > > > Wenn ich soetwas auf die aeltere Maschine losgelassen habe, dauerte
> > > > das buildworld zwar deutlich laneger (ca. 1:20 - 1:30), aber
> > > > meine interaktive Arbeit nur wenig merklich davon beeinflusst.
> ... ein -j12 buildworld erzeugt immer mal wieder Phasen mit Load
> zwischen 8 und 10, ... und das ist auf dem Dual/PPro200 eigentlich immer
> recht gut zu ertragen. Klar merkt man dann, dass gewisse Dinge langsamer
> gehen, aber man kann immer noch verzoegerungsfrei seine Fenster samt
> Inhalt durch die Gegend schieben und auch ohne sichtbaren
> Performance-Verlust Shell und Editor benutzen.
>
> > > Wenn die load uerber 1 liegt, dann ist fuer gewoehnlich das interaktive
> > > arbeiten nicht mehr sooo toll.
> ... noe, noe. "Load" sagt ja (etwas vereinfacht)(fast) nur etwas darueber
> aus, wieviel Prozesse als 'runnable' in der Scheduler-Queue stehen.
> Und das duerfen bei hinreichend schneller CPU durchaus 'ein paar mehr
> sein', bevor man interaktiv davon etwas merkt.

Nicht ganz.
Wenn grundsaetzlich ein Prozess in der Run-Queue steht (In wirlichkeit ist das
natuerlich nur statistisch) dann wartet ein anderer der neu in die Run-Queue
kommt statistisch bis die Zeitscheibe von bislang laufenden vorbei ist.
Die Zeitscheiben sind allerdings unabhaengig von der Maschinengeschwindigkeit.
Wenn man z.B. einen Prozess hat der CPU-Zeit nutzt soviel er bekommt wie ein Seti
dann wird die load ca. bei 1 liegen und eine Shell die ab und an was tut muss
statistisch auf einem UP-System warten bis statistisch die halbe Zeitscheibe um
ist - also 50ms.
Bei einer load von 10 sind das dann schon 500ms also eine halbe Sekunde - das
ist schon deutlich spuerbar.
Allerdings meinte der Oliver auch das es schon etwas ausmacht was die load
verusacht. Das liegt wohl daran weil sich bei vielen beteiligten Prozessen
 durchaus kuerzere Prozesswechsel als bei einer gleichen Load mit weniger
Prozessen ergeben und dann natuerlich wieder etwas Reaktionszeit gewonnen wird.

> >
> > > Ein verkleinern der Zeitscheiben wirkt hierbei oft Wunder:
> > > sysctl -w kern.quantum=10000
> > Ist 10000 nicht sogar der Default unter -current?
> hmmm.
> cage:[/sys/i386/conf] # sysctl kern.quantum
> kern.quantum: 100000
> cage:[/sys/i386/conf] # uname -a
> FreeBSD cage.tse-online.de 4.0-CURRENT FreeBSD 4.0-CURRENT #2: Fri Dec 17 01:56:19 CET 1999
> toor(at)cage.tse-online.de:/usr/src/sys/compile/ABWS-UP i386

womit das auch beantwortet waere - ich kann bei mir nicht so ohne weiteres
nachsehen weil die eh ueberschrieben wurden.

-- 
B.Walter                  COSMO-Project              http://www.cosmo-project.de
ticso(at)cicely.de             Usergroup                info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message