Zabaw nowym sprzętem ciąg dalszy…

Mój nowy komputerek sprawuje się znakomicie. Wszystko działa, nic się nie
sypie. Nawet 3D wreszcie działa znakomicie (potestowałem trochę w Enemy
Territory). Coś mi się zdaje, że moje poprzednie problemy z kartami ATI
związane były z walniętą płytą główną. Zresztą, nie tylko to. Na nowej płycie
wreszcie prawidłowo działa nagrywanie z mikrofonu. Na starej ciężko było
złapać cokolwiek poza szumem i to niezależnie od tego, czy używałem wejścia
audio z samej płyty, czy z dodatkowej karty muzycznej.

Dzisiaj postanowiłem zrobić porządek z czytnikiem kart i urządzeniami USB,
bo ciężko byłoby się w tym połapać – czy mój pendrive wyląduje pod
/dev/sdb1, czy /dev/sdf1… Ale od czego mamy takie
wynalazki jak udev i hal. Zrobiłe upgrade
tych ustrojstw no najnowszych wersji z PLD, ale domyślne zachowanie mnie nie
zadowoliło – wszystkie karty, pendrive’y i aparat lądowały pod
/media/usbdisk*. Więc spłodziłem sobie taki oto plik
konfiguracyjny (/etc/hal/fdi/policy/10-local-storage-policy.fdi,
na podstawie analogicznego w /usr/share):

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <!-- skip for drives with the no partitions hint (they are handled somwhere else) -->
        <match key="@block.storage_device:storage.no_partitions_hint" bool="false">
          <merge key="volume.policy.should_mount" type="bool">true</merge>
          <match key="@block.storage_device:storage.drive_type" string="compact_flash">
                <merge key="volume.policy.desired_mount_point" type="string">cf</merge>
          </match>
          <match key="@block.storage_device:storage.drive_type" string="sd_mmc">
                <merge key="volume.policy.desired_mount_point" type="string">sd</merge>
          </match>
          <match key="@block.storage_device:storage.drive_type" string="smart_media">
                <merge key="volume.policy.desired_mount_point" type="string">sm</merge>
          </match>
          <match key="@block.storage_device:storage.drive_type" string="memory_stick">
                <merge key="volume.policy.desired_mount_point" type="string">ms</merge>
          </match>
          <match key="@block.storage_device:storage.model" contains="CAMERA">
                <merge key="volume.policy.desired_mount_point" type="string">camera</merge>
          </match>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

Teraz kartę CF mam pod /media/cf, aparat pod
/media/camera, a pendrive pod /media/usbdisk. Montuję
i odmontowuję to ręcznie, ale tu żadnej automatyki nie potrzebuję.

Kolejną sprawą którą chciałem załatwić, było zwolnienie obrotów
wentylatorów, gdy nie jest potrzebna ich pełna moc. Z Linuksa kontrolować mi się tego nie udało,
ale wystarczyło włączyć odpowiednią opcję w BIOSie, żeby to się robiło
samo. Niestety nie spowodowało to żadnego wyciszenia komputera –
prawie cały hałas produkuje zasilacz, a chwilami dysk. To już będzie trzeba
jakoś sprzętowo załatwić.

Kolejna sprawa to benchmarki. Przed zmianą sprzętu zrobiłem na starym
komputerze, teraz trzeba było spróbować na nowym. Już wczoraj je zrobiłem, ale
w systemie 32-bitowym. Dzisiaj jednak ciekawość już zżerała mnie na tyle, że
postanowiłem zrobić sobie bajzel w systemie i spróbować odpalić coś w 64 bitach…

Chciałem odpalić tylko nbench-byte w 64 bitach, ale do tego
potrzeba, jak do każdej innej 64-bitowej aplikacji, 64-bitowego kernela.
Zrobiłem więc backup obecnego i nadinstalowałem wersję amd64, wraz ze
wszystkimi używanymi dodatkowymi modułami. Wcześniej jeszcze wcisnąłem w
system 64-bitowe glibc. Wszystko z --ignorearch. Prawdę mówiąc
nie liczyłem na to, że to wystartuje, a nawet na to, że initrd się poprawnie
wygeneruje… Initrd się wygenerował, system wystartował. Tylko skrypt od
firewalla nie zadziałał, bo najwyraźniej 32-bitowe iptables z 64-bitowym
kernelem nie działają. Doinstalowałem 64-bitowe iptables (z
--ignorearch) i firewall też ruszył.

Zanim odpaliłem benchmarka, postanowiłem sprawdzić, czy sobie systemu
zbytnio nie rozwaliłem. Najbardziej obawiałem się o Xy, o to, czy 64-bitowy
sterownik ATI w kernelu dogada się z 32-bitowymi Xami. Nie dogadywał się –
Xy się niby odpaliły, ale ani nie wyglądały dobrze (przesunięty, migoczący obraz),
ani nie były stabilne (wszystko się sypło przy próbie przełączenia się na
konsolę). Wyłączenie VesaFB niewiele zmieniało. Trzeba było więc i Xserver
zainstalować w wersji 32-bitowej…

Miałem już trochę dość --ignorearch --replacepkgs, więc
postanowiłem zainstalować 64-bitowego Poldka z RPMem… Niestety jak
zainstalowałem 64-bitowego RPMa, to Poldek przestał działać. Skopiowałem
więc ręcznie wszystkie potrzebne binarki (poldek i biblioteki) z pewnego
64-bitowego serwera i już tak naprawionym poldkiem zainstalowałem to samo
z RPMów. --ignorearch --replacepkgs już więcej nie było
potrzebne, ale okazało się, że Poldek wcale sobie dobrze z mieszanym systemem (32/64
bit) najlepiej nie radzi. Jednak doświadczony PLDowiec jakoś nad tym
zapanuje. W każdym razie Xserver ze wszystkimi potrzebnymi modułami i
sterownikami udało się zainstalować. Cała reszta systemu pozostała 32-bitowa
(poza, oczywiście, bibliotekami, z których wiele mam teraz w obu wersjach). Co
więcej, Xy ruszyły i działają niegorzej niż w 32-bitach. :-)

Wszystko działa, więc mogłem zrobić te swoje benchmarki… Oto wyniki:

  1. hdparm -t -T

    To najprostszy test, którym można coś sprawdzić. Niby do
    dysku, ale pokazuje też przepustowość pamięci, jak i drobny wpływ
    innych części systemu na komunikację z dyskiem.

    Test przeprowadziłem po kilka razy, poniżej wkleiłem
    środkowy wynik.

    • Na starym kompie:
      /dev/sda:
       Timing buffer-cache reads:   808 MB in  2.00 seconds = 403.17 MB/sec
       Timing buffered disk reads:  148 MB in  3.03 seconds =  48.81 MB/sec
      
    • Na nowym, w 32-bitach:
      /dev/sda:
       Timing buffer-cache reads:   3364 MB in  2.00 seconds = 1681.89 MB/sec
       Timing buffered disk reads:  160 MB in  3.02 seconds =  52.91 MB/sec
      
    • Na nowym, w 64-bitach:
      /dev/sda:
       Timing cached reads:   3084 MB in  2.00 seconds = 1541.90 MB/sec
       Timing buffered disk reads:  158 MB in  3.02 seconds =  52.25 MB/sec
      

    Widać, że zmiana kompa spowodowała prawie czterokrotne
    przyspieszenie cache dysku, a także niewielkie przyspieszenie transferu
    z dysku. Jest z czego się cieszyć. :-)

    Niespodzianką jest odrobinę gorszy wynik w systemie 64-bitowym na
    tej samej maszynie, ale różnica ta raczej nie ma znaczenia.

  2. nbench-byte

    To pakiecik do benchmarków, jaki znalazłem w PLD. Coś on tam mądrego
    liczy i w ten sposób mierzy wydajność maszyny. Cokolwiek to jest, to do
    moich celów się nada. ;-)

    • Na starym kompie:
      CPU                 : AuthenticAMD AMD Athlon(tm) processor 1004MHz
      L2 Cache            : 256 KB
      OS                  : Linux 2.6.14.7-2
      C compiler          : i686-pld-linux-gcc
      MEMORY INDEX        : 5.565
      INTEGER INDEX       : 4.729
      FLOATING-POINT INDEX: 9.567
      
    • Na nowym kompie, w 32-bitach:
      CPU                 : AuthenticAMD AMD Athlon(tm) 64 Processor 3200+ 2011MHz
      L2 Cache            : 512 KB
      OS                  : Linux 2.6.14.7-5
      C compiler          : i686-pld-linux-gcc
      MEMORY INDEX        : 11.805
      INTEGER INDEX       : 10.001
      FLOATING-POINT INDEX: 20.263
      
    • Na nowym kompie, 32-bitowo, pod 64-bitowym kernelem:
      CPU                 : AuthenticAMD AMD Athlon(tm) 64 Processor 3200+ 2010MHz
      L2 Cache            : 512 KB
      OS                  : Linux 2.6.14.7-5
      C compiler          : i686-pld-linux-gcc
      MEMORY INDEX        : 12.047
      INTEGER INDEX       : 10.116
      FLOATING-POINT INDEX: 19.884
      
    • Na nowym kompie, 64-bitowo, pod 64-bitowym kernelem:
      CPU                 : AuthenticAMD AMD Athlon(tm) 64 Processor 3200+ 2010MHz
      L2 Cache            : 512 KB
      OS                  : Linux 2.6.14.7-5
      C compiler          : amd64-pld-linux-gcc
      MEMORY INDEX        : 13.785
      INTEGER INDEX       : 13.313
      FLOATING-POINT INDEX: 19.262
      

    Widać, że sama zmiana komputera przyspieszyła te testy
    mniej-więcej dwa razy. Uruchomienie 64-bitowego kernela
    poprawiło odrobinę memory index i integer index
    jednocześnie odrobinę psując floating-point index.
    Skompilowanie testów na 64 bity wyraźniej poprawia wydajność
    pamięci i liczb całkowitych, ale operacjom zmiennoprzecinkowym nie
    pomaga. Wniosek z tego taki, że jak komuś zależy na wydajności
    operacji zmiennoprzecinkowych, to 64 bity mu są co najmniej zbędne.
    W innych przypadkach można conieco zyskać (pewnie sporo więcej niż w
    powyższym teście, jeśli kod jest odpowiednio przygotowany), ale i w 32
    bitach Athlon 64 ma moc. Z drugiej strony, wydaje się od mojego
    starego Athlona szybszy o tyle, o ile ma szybszy zegar… mogłoby być
    lepiej. Jednak w normalnej pracy pewnie będzie lepiej – w
    przeciwieństwie do tego testu, w praktyce więcej się wykorzysta
    przepustowości pamięci i I/O.

Advertisements

8 uwag do wpisu “Zabaw nowym sprzętem ciąg dalszy…

  1. Ciekawy ten nbench.

    Z domyślnymi CFLAGS, jakie są w tym nbench:
    MEMORY INDEX : 14.013
    INTEGER INDEX : 10.910
    FLOATING-POINT INDEX: 19.557

    Po dodaniu -march=athlon-xp -fstrength-reduce -floop-optimize2 -funroll-loops:
    MEMORY INDEX : 16.566
    INTEGER INDEX : 14.035
    FLOATING-POINT INDEX: 21.178

    System: Athlon-XP 2800+ mobile, 768M ramu DDR 333MHz.

    Lubię to

  2. No dziwne. Ja używam GCC 4, jeśli masz starszego to może to jest przyczyną? Chociaż wydaje mi się, że przy teście pamięci nie powinno być takiej różnicy…

    Lubię to

  3. Jeśli ten Athlon Mobile jest podobnie zbudowany co Pentium M to nie jest tak bardzo słabszy, czasem potrafią te procki nieźle wymiatać w porównaniu do analogicznych desktopowych kości…

    Lubię to

  4. Jajcuś: Miło było pomóc 😉

    Popatrzyłeś może na tego poldka, czy da się go zmusić aby równomiernie aktualizował pakiety dla obu architektur, czy dalej chce jedną wyrzucać?

    Lubię to

Co o tym sądzisz?

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s