# Szybkosc systemu na roznych kernelach

## tboloo

Witam

Przeszedlem wlasnie na kernel 2.6.15-gentoo-r1 z 2.6.14-gentoo-r5 (cp .config && make oldconfig) i system dziala mi wolniej - przynajmniej takie sa moje odczucia. W zwiazku z tym pytanie - w jaki sposob mozna obiektywnie zmierzyc szybkosc dzialania systemy na poszczegolnych kernelach ?? ew. ktory benchmark da mi najpelniejsze wyniki ??

----------

## Belliash

mowia ze CK jest szybkie.

Ja swego czasu uzywalem tez archck i nie narzekalem.

Po przejsciu z 2.6.14-archck na 2.6.15-ock tez zauwazylem spowolnienie.

Moze to galaz 2.6.15 jest wybrakowana?

----------

## Gabrys

Nie ma takich testów. Powszechnie wiadomo, że niektóre łatki na kernel zwiększają wydajność w pewnych specyficznych sytuacjach, a w niektórych ją zmniejszają. Ogólnie najważniejsze (w mojej opinii) jest, żeby czuć, że system działa dla nas i odpowiada na naszą aktywność -- mówię o typowo desktopowym zastosowaniu komputera.

Jednak często podświadomie po zaktualizowaniu kernela oczekujemy, że będzie dużo szybszy i kiedy nie jest dużo szybszy wydaje się, że jest wolniejszy. Ja mam syndrom odwrotny: jakiej bym operacji nie wykonał zawsze wydaje mi się, że system przyśpieszył.

Warto zrobić swoje własne testy, p. szybkość uruchamiania aplikacji, z których najczęściej korzystasz. Dla mnie to jest najważniejsze, bo z szybkości ich działania jestem zadowolony.

Jeśli chcesz zwiększyć właśnie szybkość uruchamiania aplikacji (co zwiększa poczucie lekkości systemu) spróbuj zmigrować system plików na reiserfs albo użyj prelinka (najlepiej obu). Nie oczekuj też, że będzie to jakieś superprzyśpieszenie, ale zawsze coś.

Wracając do tematu samego kernela, to dużo bardziej istotne od wersji jądra jest jego konfiguracja. Warto choć raz przejrzeć wszystkie dostępne opcje. Uruchamiając w /usr/src/linux "make gconfig" dostajemy ładne drzewko opcji i jednocześnie pomoc na ich temat, co jest bardzo sprytne.

Kończąc moją niespójną i szczątkową odpowiedź życzę powodzenia w konfigurowaniu swojego systemu.

A ck-sources daje nam nową opcję w konfiguracji jądra: I/O Scheduler. Wybór CFQ daje lepsze rezultaty dla systemu typowo biurkowego (większa szybkość reakcji na działania użytkownika kosztem zmniejszonej wydajności systemu, czyli tego co system robi bez ingerencji użytkownika).

----------

## martin.k

Co do testowania wydajności, to za czasów jąder 2.6.9 - 2.6.12 bawiłem się trochę w różne mutacje (FX-sources, ISOTOPE-sources).

Jądro 2.6.9 + łatki CK Cona Kolivasa, a czasem PlugSched od dr P. Williamsa + dodatkowo genetyczne algorytmy od J. Moilanena na anticipatory I/O schedulera  :Smile:  To były czasy  :Smile:  Potem nastały kiepskie czasy i ogólnie z wydajnością jajek nastąpił spadek. No koniec tego biadolenia.

Co do testowania:

1) Jądra z gałęzi -mm ostatnio "przymuliły" nieco  :Smile:  Więc o ile nie potrzeba Ci jakiegoś nowego sterownika to ...  :Smile: 

2) Co do CPU schedulerów: doskonale przetestujesz, co Ci odpowiada za pomocą PlugSched'a [url]cpuse.sf.net[/url]

3) Co do I/O schedulerów: wystarczy, że w grubie/lilo w odpowiednim miejscu dodasz elevator=x gdzie za x wstawisz sobie jeden z tych:

```
noop

anticipatory

deadline

cfq
```

Interesujące stronki:

dr Peter Williams - PlugSched: [url]cpuse.sf.net[/url]

Jake Moilanen - algorytmy genetyczne w linuksie: [url]kernel.jakem.net[/url]

Con Kolivas - Staircase CPU scheduler i pozostałe łatki -ck: http://members.optusnet.com.au/ckolivas/kernel/

Ingo Molnar - łatki -RT: http://people.redhat.com/mingo/

Andrew Morton - drzewko -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

Przepis na zupę z Pingwina: http://lkml.org/

Miłego patchowania (gotowania) jajek  :Smile: 

----------

## Gabrys

Fajny się zrobił temat. Dzięki Martin za linki  :Smile: .

----------

## martin.k

 *Gabrys wrote:*   

> Nie ma takich testów. 

 

VETO!  :Smile: 

Są testy:

Con Kolivas: interbench http://members.optusnet.com.au/ckolivas/interbench/ <- pomiar interaktywności jaja.

A do testów I/O to na myśl mi przychodzi np.: boniee++ http://www.acnc.com/benchmarks.html

----------

## tboloo

Dzieki za wyczerpujace wyjasnienia   :Very Happy: 

Co do I/O schedulerów to probowalem cfq, ale strasznie przy nim dysk hasaluje, a roznicy zadnej w szybkosci nie zauwazylem. 

Dzieki Martin za linki do testow. Sprawdze i podziele sie wiedza.

----------

## martin.k

 *tboloo wrote:*   

> Dzieki za wyczerpujace wyjasnienia  
> 
> Co do I/O schedulerów to probowalem cfq, ale strasznie przy nim dysk hasaluje, a roznicy zadnej w szybkosci nie zauwazylem. 
> 
> Dzieki Martin za linki do testow. Sprawdze i podziele sie wiedza.

 

Na cfq bym uważał, zwłaszcza ze starszych jajek, działy się dziwne bajki z dyskami  :Smile:  Poza tym, to radzę przeglądać

posty na lkml.org od ostatniego wydania "stabilnego", albo -mm. Czasem nie warto wysadzać otwartych drzwi.

Osobiście jadę na anticipatory - dyski IDE Seagate 160GB + 40 GB na reiserfs i reiser4.

A testowanie zabierze Ci nieco czasu. Gdzieś przeglądałem wykresy testów wydajności róznych jajek od 2.6.9 do ostatnich 2.6.15 ale za Chiny Ludowe nie pamiętam gdzie  :Smile: 

----------

## mbar

Generalnie bardzo sobie chwalę serię archck, gdyż nie jest to jajko typu "wydajność kosztem stabilności". Ma ktoś jakieś teoretyczne porównanie schedulerów IO?

----------

## v7n

To i ja wtrace swoje 3 centy:

Od kiedy posiadlem wiedze i umiejetnosci samodzielnej kompilacji kernela (co stalo sie rownoczesnie z przesiadka na gentoo), zawsze uzywalem gentoos-sources. Jednak pewnego dnia trafilem na skrypt w pythonie (juz go dawalem, ale podam jeszcze raz) i prosbe o jego testowanie. Jako posiadacz swiezo zaemergowanego gentoo-sources-2.6.15-r1 postanowilem dolozyc swoj wynik (jakies 2:33 jak dobrze pamietam). Szczeka mi opadla, gdy zobaczylem, ze posiadacz 2100+ i 1024 ramu na gentoos-sources-2.6.12-r6 mial 2:04. Po podniesieniu sie z podlogi stwierdzilem, ze czas wycisnac z gentoo ile sie da, nie tracac specjalnie na stabilnosci. Teraz jade na  2.6.15-nitro3 i wynik spadl do 1:33, co uwazam, za swietny rezultat (pragne zauwazyc, ze to tylko zmiana kernela i zabawy z nice'em tak podzialaly - zadne zmiany w hardwarze ). Mysle, ze moral kazdy wyciagnie sam  :Smile: 

Zalacznik 1.

```
#!/usr/bin/python

import time

a=time.gmtime()

12345678**1234567

b=time.gmtime()

print "time is",abs(a[3]-b[3]),'hours',abs(a[4]-b[4]),'min',abs(a[5]-b[5]),'sec'
```

Zeby nie bylo zbednych pytan - odpalamy przez zwykle

```
$ ./skrypt
```

----------

## Axio

fajny skrypcik  :Smile: 

ja mam 2 min 5 sek na jądrze 2.6.14-gentoo-r2 , AMD Sempron 2400+ i 768 MB RAM

to dobrze czy źle?

----------

## ilny

Ja mam 2.6.14-gentoo-r5, AthlonXp 1700+, 256 Ram wynik:

```
time is 0 hours 2 min 10 sec
```

  :Wink: 

----------

## Aktyn

Może nie miło komuś zwracać uwage a ja jestem niegrzeczny i psuje zabawe, ale dopracuj troche ten skrypt:

pierwsze uruchomienie:

```
$ time ./test

timeis 0 hours 1 min 0 sec

real    1m0.933s

user    0m56.500s

sys     0m0.324s
```

Drugie urchomienie:

```
$ time ./test

timeis 0 hours 2 min 58 sec

real    1m2.015s

user    0m56.372s

sys     0m0.368s
```

amd64, 2,17Ghz

----------

## tboloo

 *Quote:*   

> 
> 
> Con Kolivas: interbench http://members.optusnet.com.au/ckolivas/interbench/ <- pomiar interaktywności jaja.
> 
> 

 

i wyszlo :

```

jajko 2.6.14-gentoo-r5

Using 1482161 loops per ms, running every load for 30 seconds

Benchmarking kernel 2.6.14-gentoo-r5 at datestamp 200601282124

--- Benchmarking simulated cpu of Audio in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.003 +/- 0.0032     0.005       100           100

Video     0.032 +/- 0.669       16.4       100           100

X       1.3 +/- 3.03          10       100           100

Burn     0.003 +/- 0.00378    0.005       100           100

Write      0.01 +/- 0.0941         2       100           100

Read     0.008 +/- 0.0102     0.146       100           100

Compile     0.007 +/- 0.0108     0.176       100           100

Memload     0.009 +/- 0.0448     0.792       100           100

--- Benchmarking simulated cpu of Video in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.003 +/- 0.00361    0.009       100           100

X      3.17 +/- 8.05        41.3      99.8          87.4

Burn     0.003 +/- 0.00337    0.009       100           100

Write      0.06 +/- 1.08        25.7       100          99.8

Read     0.005 +/- 0.00815    0.196       100           100

Compile     0.036 +/- 0.632       19.1       100          99.9

Memload      0.02 +/- 0.555       23.5       100          99.9

--- Benchmarking simulated cpu of X in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.006 +/- 0.0817         1       100          99.3

Video      11.4 +/- 24.2          84      37.1          29.4

Burn     0.006 +/- 0.0817         1       100          99.3

Write     0.076 +/- 0.907         15        98          97.4

Read     0.023 +/- 0.224          3       100          98.7

Compile     0.033 +/- 0.257          2      98.1          97.4

Memload     0.033 +/- 0.346          5       100          98.7

--- Benchmarking simulated cpu of Gaming in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU

None     0.065 +/- 0.68        10.5      99.9

Video      66.2 +/- 66.5        73.2      60.2

X      92.9 +/- 193         1133      51.8

Burn       312 +/- 354          400      24.3

Write      7.33 +/- 44.2         485      93.2

Read      4.25 +/- 12.7         212      95.9

Compile       341 +/- 381          715      22.7

Memload      1.79 +/- 3           16.9      98.2

```

natomiast na 2.6.15-nitro3

```

Using 1482161 loops per ms, running every load for 30 seconds

Benchmarking kernel 2.6.15-nitro3 at datestamp 200601282150

--- Benchmarking simulated cpu of Audio in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.008 +/- 0.013      0.135       100           100

Video     0.007 +/- 0.0106     0.136       100           100

X     0.014 +/- 0.1            2       100           100

Burn      0.01 +/- 0.0681      1.65       100           100

Write     0.012 +/- 0.0349     0.489       100           100

Read     0.011 +/- 0.018       0.34       100           100

Compile     0.024 +/- 0.344       8.42       100           100

Memload     0.014 +/- 0.0163     0.129       100           100

--- Benchmarking simulated cpu of Video in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.007 +/- 0.0125     0.158       100           100

X     0.047 +/- 0.588       16.7       100          99.9

Burn     0.007 +/- 0.00876    0.143       100           100

Write      0.01 +/- 0.0255       0.7       100           100

Read     0.009 +/- 0.0212     0.363       100           100

Compile      0.01 +/- 0.02       0.419       100           100

Memload     0.012 +/- 0.0303     0.525       100           100

--- Benchmarking simulated cpu of X in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None      0.02 +/- 0.183          2       100          98.7

Video      14.6 +/- 27.1          68      35.6          26.1

Burn     0.635 +/- 4             38      82.9          81.4

Write      0.27 +/- 2.91          40      84.7          83.7

Read     0.156 +/- 0.798          5      95.6          93.2

Compile      2.81 +/- 20.1         256      35.1          33.1

Memload     0.113 +/- 0.663          5      95.3          93.9

--- Benchmarking simulated cpu of Gaming in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU

None     0.007 +/- 0.0339     0.304       100

Video      65.8 +/- 66.1        72.9      60.3

X      99.3 +/- 177          863      50.2

Burn       393 +/- 405          480      20.3

Write      5.84 +/- 21           170      94.5

Read      2.62 +/- 2.91        5.13      97.4

Compile       428 +/- 446          725      18.9

Memload      5.12 +/- 10.7        87.1      95.1

```

teraz tylko zrozumiec te liczby i optymalizowac   :Very Happy: 

----------

## pmz

A ja mam (@ Athlon64 3200+)

```
time is 0 hours 1 min 10 sec
```

na "zwykłych" gentoo-sources 2.6.14-r5  :Razz: 

----------

## domel

Tak dla porównania:

xorg + KDE + uruchomionych kilka aplikacji:

```
time is 0 hours 3 min 14 sec
```

natomiast na konsoli:

```
time is 0 hours 2 min 7 sec
```

AMD Athlon XP 1700+; 512 MB RAM DDR 266 MHz; 2.6.15-nitro3

Pozdrawiam

----------

## tboloo

Wyniki 2:18 dla kernela 2.6.14-gentoo-r5 i 2:19 dla 2.6.15-nitro3

Wniosek z tego ze skrypt nie daje zadnych informacji o pracy na roznych kernelach przynajmniej u mnie.

----------

## szolek

A u mnie 1:31 1:27 2:31 w kolejnych poiwtórkach na jądrze 2.6.15-gentoo-r1. Miałem już jądro ck morph raptor orz nitro. Specjalnie nie widać poprwy na którymś jądrze.

----------

## Kajan

```

time is 0 hours 2 min 3 sec

real    1m56.743s

user    1m52.887s

sys     0m1.513s

```

Pozdro

----------

## yoshi314

1:05 na 2.6.15-archck2-r1 [a64 3200+]

----------

## arach

```

`--> time ./test.py 

time is 0 hours 8 min 13 sec

./test.py  424.98s user 4.88s system 87% cpu 8:13.99 total

```

Na P2 400, 256MB ramu na 2.6.14-arach-r2 (arach: ck + vesafb-tng + patch z grsec-a na ukrywanie procesow innych userow)

W trakcie "chodzenia" skryptu korzystałem normalnie z systemu więc wyniki mogą być troche przekłamane.

----------

## martin.k

Ja tylko dodam od siebie. Jeśli chcecie testować jądra na okoliczność interaktywności - to INTERBENCH jest póki co jedynym sensownym testem

Co do wyników interbech polecam lekturę dokumentacji i listy dyskusyjnej Cona Kolivasa.

TIP: porównaj sobie % Desired CPU  % Deadlines Met pomiędzy jajem gentoo a nitro. Odpowiedź nasuwa się sama  :Smile: 

A temu skryptowi nie ufałybm ani trochę  :Smile:  Choćby dlatego, że daje różne efekty po kilkukrotnym odpaleniu.

A jeśli mieć gdzieś interbench i opierać się na kadłubkach to moje trzy grosze:

```

time dd if=/dev/urandom bs=1024 count=100000 | md5sum > /dev/null

```

Moje wyniki

```

Linux gentoo 2.6.15-isotope7 #1 PREEMPT Mon Jan 23 20:17:28 CET 2006 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux

real    0m23.552s

user    0m0.567s

sys     0m22.155s

```

Wszystkie te skrypciki są za przeproszeniem g* warte jeśli chodzi o poprawne badanie interaktywności jądra.

Ja zaufałbym tylko interbench'owi  :Smile: 

----------

## martin.k

A oto wyniki interbench mojej blaszanki:

Jądro:Linux gentoo 2.6.15-isotope7 #1 PREEMPT Mon Jan 23 20:17:28 CET 2006 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux

System plików: ReiserFS

Scheduler I/O: anticipatory

Scheduler CPU: staircase

```

Using 240437 loops per ms, running every load for 10 seconds

Benchmarking kernel 2.6.15-isotope7 at datestamp 200601291455

--- Benchmarking simulated cpu of Audio in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.002 +/- 0.00279    0.006       100           100

Video     0.003 +/- 0.00436    0.043       100           100

X     0.137 +/- 0.797          6       100           100

Burn     0.003 +/- 0.00543    0.047       100           100

Write     0.016 +/- 0.0218     0.157       100           100

Read      0.02 +/- 0.021      0.044       100           100

Compile  0.043 +/- 0.358          5       100           100

Memload  0.047 +/- 0.235        2.8       100           100

--- Benchmarking simulated cpu of Video in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None     0.002 +/- 0.00348    0.041       100           100

X     0.168 +/- 0.853          6       100           100

Burn     0.002 +/- 0.00353    0.044       100           100

Write     0.023 +/- 0.206          5       100           100

Read      0.02 +/- 0.021      0.157       100           100

Compile  0.012 +/- 0.0524     0.884       100           100

Memload  0.037 +/- 0.219       3.44       100           100

--- Benchmarking simulated cpu of X in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met

None         0 +/- 0.000821   0.008       100           100

Video         0 +/- 0.000707   0.007       100           100

Burn         0 +/- 0.000802   0.008       100           100

Write         0 +/- 0.00289    0.029       100           100

Read         0 +/- 0.00269    0.027       100           100

Compile     0 +/- 0.00299     0.03       100           100

Memload    0 +/- 0.00269    0.027       100           100

--- Benchmarking simulated cpu of Gaming in the presence of simulated ---

Load   Latency +/- SD (ms)  Max Latency   % Desired CPU

None         0 +/- 0              0       100

Video         0 +/- 0              0       100

X         0 +/- 0              0       100

Burn      74.5 +/- 173          404      57.3

Write      4.78 +/- 14.9          95      95.4

Read         0 +/- 0              0       100

Compile    102 +/- 231          571      49.6

Memload   2.92 +/- 11.8        57.5      97.2

```

Jądro to własna produkcja: 2.6.15 + najnowsze łatki CK + reiser4 + vesafb-tng

----------

## wodzik

no ja nie wiem czy ten skrypt dziala. moj wynik na mandrivie 2006 z jadrem 2.6.12-12mdk (siedze na kompie dziwewczyny). 

```
[lucek@BoLs ~]$ ./test

time is 0 hours 3 min 30 sec

```

dodam ze odpalony bmp firefox kadu 2 konsole i wszystko sie dzieje w kde, a procek nie jest juz taki mlody 

```
[root@BoLs ~]# cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 15

model           : 2

model name      : Intel(R) Celeron(R) CPU 2.00GHz

stepping        : 9

cpu MHz         : 2000.571

cache size      : 128 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr

bogomips        : 3956.73

```

----------

## martin.k

 *wodzik wrote:*   

> no ja nie wiem czy ten skrypt dziala. 

 

No właśnie. Niezbyt działa. 

Use Interbench  :Smile: 

----------

## Belliash

```
[root]::[PECET]/# time dd if=/dev/urandom bs=1024 count=100000 | md5sum > /dev/null

100000+0 records in

100000+0 records out

102400000 bytes (102 MB) copied, 70,4313 seconds, 1,5 MB/s

dd if=/dev/urandom bs=1024 count=100000  0,03s user 16,31s system 23% cpu 1:10,59 total

md5sum > /dev/null  0,38s user 0,08s system 0% cpu 1:10,59 total

processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 47

model name      : AMD Athlon(tm) 64 Processor 3000+

stepping        : 0

cpu MHz         : 2528.493

cache size      : 512 KB

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm

bogomips        : 5060.18

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management: ts fid vid ttp tm stc
```

Athlon64 3000+ Venice @ FSB 280MHz => 2528MHz

Dodam ze w tle jeszcze leci kompilacja  :Wink: 

kernel: 2.5.16-ock1

Pozniej zrobie jeszcze raz te nsam test bez kompilacji w tle  :Wink: 

```
[root]::[PECET]/# time dd if=/dev/urandom bs=1024 count=100000 | md5sum > /dev/null

100000+0 records in

100000+0 records out

102400000 bytes (102 MB) copied, 17,2031 seconds, 6,0 MB/s

dd if=/dev/urandom bs=1024 count=100000  0,04s user 15,95s system 92% cpu 17,205 total

md5sum > /dev/null  0,36s user 0,08s system 2% cpu 17,205 total
```

W tle tylko firefox, z chatem w havie, na 2 zakladce to forum i BMP odtwarzajacy MP3  :Razz: 

----------

## tomborek

Athlon XP 2000+, 768MB RAM

Gentoo Sources 2.6.10r6, KDE, 2x Firefox

1wsza proba

```
time is 0 hours 1 min 53 sec
```

2ga proba

```
time is 0 hours 2 min 4 sec
```

----------

## Aktyn

Myśle że nie tylko od kernela zależy ale od jego ustawien, ja sobie zmieniłem (za sugestią któregoś z forumowiczów)

```
Preemption Model (Voluntary Kernel Preemption (Desktop))  --->

( ) No Forced Preemption (Server)

(X) Voluntary Kernel Preemption (Desktop)

( ) Preemptible Kernel (Low-Latency Desktop)
```

miałem (Server) oraz

```
IO Schedulers  --->

<*> Anticipatory I/O scheduler

<*> Deadline I/O scheduler

<*> CFQ I/O scheduler
```

miałem zdajesie Deadline teraz Anticipatory, i mam  wyraźną poprawę, nie jakaś potworna ale zawsze, a wynik skryptu:

```
time ./test

timeis 0 hours 1 min 5 sec

real    0m55.294s

user    0m54.219s

sys     0m0.264s
```

Czyli szybciej o ok. 2 sek, Sugeruje sie oczywiście czasem systemowym, gdyż jest bardziej odpowiada rzeczywistości.

----------

## martin.k

 *Aktyn wrote:*   

> Myśle że nie tylko od kernela zależy ale od jego ustawien, ja sobie zmieniłem (za sugestią któregoś z forumowiczów)
> 
> ```
> Preemption Model (Voluntary Kernel Preemption (Desktop))  --->
> 
> ...

 

Poprawa czasu działania skryptu, to na pewno nie zasługa zmiany Deadline na Anticipatory - jeśli cokolwiek mogło poprawić wydajność działania to zmiana nastawów na Voluntary Kernel Preemption. Deadline i Anticipatory - to planiści (scheduler) I/O. Ten skrypt może jedynie w niewielkim zakresie przetestować planistę (scheduler) CPU - staircase (Con Kolivas), nicksched (Nick Piggin) itp... Co by nie robić z tego postu wykładu  :Smile: 

Ten skrypt nie mówi wiele o wydajności samego jądra jak i całego systemu.

Zapuszczenie Interbench trwa może trochę dłużej ale to jedyny miarodajny benchmark dla kernela.

Wynikami tego skryptu, jak również skryptu, który zapodałem wcześniej, nie należy się sugerować oceniając wydajność jądra!!!

Zainteresowanym polecam lekturę:

a) Robert Lowe - "Linux Kernel - przewodnik programisty" - wydany nakładem Helion (2004 - 2005)

b) Josh Aas - "Understanding the Linux 2.6.8.1 CPU Scheduler" - Silicon Graphics, Inc. (2005)

c) Daniel P. Bovet, Marco Cesati - "Understanding the Linux Kernel, 3rd Edition" - nakład O'Reilly (2005)

d) http://lkml.org

----------

## Gabrys

hehś i do czego doszliśmy, że jedynym w miarę wiarygodnym testem jest interbench. Mamy jeden, zatem nie można powiedzieć, że są testy, które mierzyłyby szybkość systemu w sposób obiektywny  :Laughing: . A tak zupełnie serio, to na system biurkowy liczy się, aby system szybko odpowiadał na gesty użytkownika, a nie, żeby szybko liczył, która jest godzina (czy coś w tym stylu  :Wink: ). Dlatego używam tej trzeciej opcji w konfiguracji kernela, czyli Preemptible Kernel oraz Preempt Big Kernel Lock (to jest dopiero spowalniacz, czytałem, że już w 2.6.13 mieli wywalić przynajmniej 80% wystąpień tego cuda, ale im nie wyszło  :Wink: ). Do tego Timer ustawiony na 1000 MHz, system plików reiser, CFQ i w ten sposób nie mam najszybszego jądra, ale takie, które współgra ze mną. A kompa i tak mam szybkiego, to mogę sobie pozwolić na niewielki (wątpię, czy większy niż 10%) spadek wydajności.

----------

## Aktyn

 *martin.k wrote:*   

> Poprawa czasu działania skryptu, to na pewno nie zasługa zmiany Deadline na Anticipatory - jeśli cokolwiek mogło poprawić wydajność działania to zmiana nastawów na Voluntary Kernel Preemption. 
> 
> Ten skrypt nie mówi wiele o wydajności samego jądra jak i całego systemu.
> 
> Zapuszczenie Interbench trwa może trochę dłużej ale to jedyny miarodajny benchmark dla kernela.

 

Oczywiście, sheduler dyskowy w tym skrypcie raczej nie pomógł, 

A jeśli chodzi o wydajność, to czym sie sugerować?, płynnością? czasem konwersji ogg czy mpeg? A moze płyną obsługą sieci (serwer)

A jak serwer, to liczy sie co?, czas odpowiedzi do klienta czy ilość klientów na sekunde?

Dla mnie system ma nie marnowac czasu jak ma coś liczyć, ale ma zapewniać interaktywność, czyli żadnego przycinania sie filmu jak leci kompilacja, czy oglądanie stronek jak leci np taki skrypt w pythonie, choćby ich miało 100 takich w tle pracować,

A wiec dobry scheduler zdajesie CPU. Priorytety zadań też pewnie mają coś tutaj do powiedzenia.

Poza tym nawet uruchamianie aplikacji zależy od tego gdzie sa na dysku, i jak bardzo pofragmentowane. Według mnie to bardzo złożony temat.

----------

## martin.k

 *Gabrys wrote:*   

> hehś i do czego doszliśmy, że jedynym w miarę wiarygodnym testem jest interbench. Mamy jeden, zatem nie można powiedzieć, że są testy, które mierzyłyby szybkość systemu w sposób obiektywny :lol

 

Interbench wystarczy, jeżeli chodzi o pomiar interaktywności  :Smile: 

Co jak co, ale doktor Kolivas zna się na schedulerach - pewnie tak samo dobrze jak na anastezjologii.

A jeśli chcecie zobaczyć co się działo z kernelem od 2.6.0 to proszę:

http://test.kernel.org/perf/perf_matrix.html

P.S.

Prawda, że testy przeprowadzane były na solidnych maszynkach.

Nam śmiertelnikom najbliżej do: elm3b132 - czyli 4x Pentium!!!

----------

## Gabrys

 *Aktyn wrote:*   

> 
> 
> A jeśli chodzi o wydajność, to czym sie sugerować?, płynnością? czasem konwersji ogg czy mpeg? A moze płyną obsługą sieci (serwer)
> 
> A jak serwer, to liczy sie co?, czas odpowiedzi do klienta czy ilość klientów na sekunde?
> ...

 

I tu trafiasz w sedno sprawy. Wg mnie należy wybrać jakieś normalne jądro i zastanowić się co jest wąskim gardłem w obecnym zastosowaniu. Jak już dojdziesz co, należy wyszukać coś w tym kierunku.

----------

## martin.k

 *Aktyn wrote:*   

> 
> 
> Oczywiście, sheduler dyskowy w tym skrypcie raczej nie pomógł, 
> 
> A jeśli chodzi o wydajność, to czym sie sugerować?, płynnością? czasem konwersji ogg czy mpeg? A moze płyną obsługą sieci (serwer)
> ...

 

Serwer nie równy serwerowi. Jeżeli używasz serwera typowo do obliczeń albo renderingu, to w twoim interesie jest mniej więcej aby:

1) zadania interaktywne (task interactive) nie otrzymywały dodatkowych bonusów (tak jak to ma miejsce w przypadku wielu łatek optymalizujących jądro dla desktopa np. -CK),

2) algorytm szeregowania round robin przydzielał procesom dłuższe interwały czasowe,

3) zadania były wywłaszczane po jak najdłuższym czasie.

Natomiast, jeżeli na serwerze jest duży ruch po sieci, to potrzebne ci są jak najmniejsze opóźnienia (latencies) przynajmniej jeżeli chodzi o sieć.

Co do desktopa, to potrzeba ci mniej więcej aby:

1) zadania interaktywne otrzymywały bonusy,

2) wywłaszczenie zadania następowało po jak najkrótszym możliwym czasie,

3) opóźnienia (latencies) były jak najmniejsze,

4) interwały czasowe przydzielone zadaniom były stosunkowo mniejsze, niż w przypadku konfiguracji serwerowej,

A dotego wszystkiego pozostaje jeszcze kombinacja z poziomami uprzejmości (nice)  :Smile: 

Pozostaje jeszcze kwestia systemu plików i schedulera I/O. To następny temat rzeka  :Smile: 

Reasumując: sam musisz przetestować, co tak naprawdę tobie odpowiada.

Ze swojego, miernego, doświadczenia mogę polecić ci na desktop:

1) zestaw łatek Cona Kolivasa -ck

2) łatki -nitro - oparte na ck

3) jeżeli komponujesz, obrabiasz profesjonalnie muzę na kompie - łatki -RT od Ingo Molnara

A co do serwera obliczeniowego - ponownie łatki od doktora Kolivasa tym razem -cks -wersja serwerowa.

Dalej nie czuję się upoważnionym do ciągnięcia tego wywodu, bo i moja wiedza jest mierna jeżeli chodzi o "bebechy" jądra linuksa.

----------

## Aktyn

 *martin.k wrote:*   

> Dalej nie czuję się upoważnionym do ciągnięcia tego wywodu, bo i moja wiedza jest mierna jeżeli chodzi o "bebechy" jądra linuksa.

 

Dzieki za wskazówki  :Smile: 

A co do wiedzy pewnie nie każdy ma w głowie całokształt, ale zawsze jakimiś doświadczeniami może sie podzielić.

Forum do tego służy, niekoniecznie trzeba być profesorem. Wtedy nikt by tutaj nie pisał  :Smile:  no bo o czym, że słońce świeci  :Wink: 

----------

## Belliash

Dobra dosyc gadania o wszystkim i o niczym  :Very Happy: 

Niech ktos poda nazwe jakiegos softu albo skryptu, czy czego kolwiek co sprawdzi nasze CPU, co tak na prawde potrafia i nasze Gentoo, jak bardzo sa zoptymalizowane  :Razz:  Tylko prosze o cos wiarygodnego, to ptestujemy wszyscy i zobaczymy czyj komp ma prawdziwego kopa  :Wink: 

----------

## martin.k

 *rafkup wrote:*   

> Dobra dosyc gadania o wszystkim i o niczym 
> 
> Niech ktos poda nazwe jakiegos softu albo skryptu, czy czego kolwiek co sprawdzi nasze CPU, co tak na prawde potrafia i nasze Gentoo, jak bardzo sa zoptymalizowane  Tylko prosze o cos wiarygodnego, to ptestujemy wszyscy i zobaczymy czyj komp ma prawdziwego kopa 

 

Gadnie jest bynajmniej o wszystkim i o niczym  :Shocked: 

Nie ma na linuksa (IMO) całościowego testu, który miałby sprawdzić kto ma jakiego kopa w kompie. 3D Mark 200x Linux nie prędko zobaczysz. Jeśli tak bardzo chcesz pokazać ile masz fps-ów, milionów operacji na sekundę itp. To pozostaje Ci na razie wyłącznie: PassMark BurnInTest Linux http://www.passmark.com/products/bitlinux.htm 30 dni evaluation, potem US$49.

Wymagania:

```

Linux kernel 2.6.9 or higher.X Window System X11R6.KDE 3.2 or higher.Open GL 1.2 or higher (for 3D graphics test plus working Open GL drivers for your video card).
```

A tak z zupełnie innej beczki, to chyba nie chodzi o tylko o te fps-y, co by ziomowi pokazać ile wydusiłeś ze swojej blaszanki!? 

A może ja już nie z tej epoki jestem!

Pozdro!

Niżej podpisany Ebonit.

----------

## Aktyn

 *rafkup wrote:*   

> Dobra dosyc gadania o wszystkim i o niczym 
> 
> Niech ktos poda nazwe jakiegos softu albo skryptu, czy czego kolwiek co sprawdzi nasze CPU, co tak na prawde potrafia i nasze Gentoo, jak bardzo sa zoptymalizowane  Tylko prosze o cos wiarygodnego, to ptestujemy wszyscy i zobaczymy czyj komp ma prawdziwego kopa 

 

Obawiam sie że nie ma jakiegoś ogólnego testu, każdy jak pisał martin.k optymalizuje kompa pod siebie.

Ja może coś napisze bardziej poważnego, przy okazji jak coś będe pisał czy uczył się, zawsze coś tam wyrzeźbie, jak to powiadają gdzie drwa rąbią tam i wióry lecą  :Smile:  ,

Tu jest małe co nieco, ale to do sprawdzania 32 i 64 bitowych systemów, ale jak już chcesz możesz sie wyżyć.  :Smile: 

@martin.k

Jak sie ma to co napisałeś, do tego co masz w stopce?  :Wink: 

----------

## martin.k

 *Aktyn wrote:*   

> 
> 
> @martin.k
> 
> Jak sie ma to co napisałeś, do tego co masz w stopce? 

 

Dobre  :Smile:  He! He! Nie będzie nam tu Ebonit, za przeproszeniem, bogomipsami w kaszę plwał!

----------

## rooter666

z benchmarków pod linuxa jest też bashmark (jest dostępny w portage)

```
marek@gentoo ~ $ bashmark &

[1] 1829

#######################################################

:  T   E   S   T        :    :S C O R E :  : R A T I O:

:-----------------------------------------------------:

:Cpu, Integer           :    :       937:  :      -13%:

:Cpu, Floating point    :    :       686:  :      -10%:

:                       :    :          :  :          :

:Memory r/w (cached)    :    :      3168:  :     +163%:

:Memory de-/alloc       :    :       500:  :      -24%:

:                       :    :          :  :          :

:Multithreading         :    :      1786:  :      -28%:

#######################################################

:           S  Y  S  T  E  M     I  N  F  O           :

-------------------------------------------------------

1x AMD Athlon(tm) XP 1700+ 1466.943MHz, L2 256KB

Linux 2.6.15-gentoo-r1 

GCC 3.4.4 

100KB binary size

#######################################################

:      R E F E R E N C E   S Y S T E M   I N F O      :

-------------------------------------------------------

Reference system was Geno's pc with:

Athlon XP 1800+ 1575.631MHz, 256KB

Linux 2.6.11-ck1

GCC 3.4.3-20050110 (compiled with standard cflags)

glibc 2.3.4 (with nptl)

128KB binary size

Scores gathered on March, 30th. 2005 with bashmark 0.6

[1]+  Done                    bashmark

```

ram na moim pececie to ddr 266 stąd nie najlepsze wyniki.

----------

