sprzęt

Podczas porannej prasówki natrafiłem na link w 7thguard do informacji o udostępnieniu
przez AMD specyfikacji do chipsetów graficznych. Developerzy Xorg dostali pierwszą część dokumentacji
dwunastego września, lada chwila ma wyjść (a może wyszedł?) nowy,
open-source’owy sterownik do R500/R600… a w sieci praktycznie cisza.

Dziwne trochę. Były petycje, nie petycje, wieczne narzekania na brak
dobrych sterowników i specyfikacji, szum przy każdej wzmiance o ewentualnym
ujawnieniu specyfikacji itd. itp. A jak coś konkretnego się stało, to cisza.
Dziwne. Albo ja czegoś nie widzę…

Mam nadzieję, że tym razem nie zapeszę…

Po ostatnim wpisie tutaj na temat karty TV dałem sobie spokój z próbami
w moim komputerze. Za to zabrałem kartę do pracy. Tam zadziałała bez problemu.
Nie dość, że nie powodowała padu systemu, to jeszcze jakość nagrania była dużo
lepsza (brak zakłóceń w postaci białych pasków). Pomyślałem, że w ten sposób
będę mógł przynajmniej w pracy zgrać z kamery to co wcześniej sobie na taśmę
nagram… jednak na myśleniu się skończyło. Najpierw urwałem tacie jedną taśmę
(z tych które mi dał do przegrania), a potem odkryłem, że kamera w swoim
łakomstwie pożarła by każdą taśmę jaką do niej wsadzić. Więc eksperymenty
z przegrywaniem kaset zakończyłem na tej jednej urwanej i dwóch wymiętych
taśmach…

Poleżała więc kamera u mnie w pracy przez tydzień, aż postanowiłem znowu
spróbować w domu. Tym razem plan był taki: skoro problemem jest najwyraźniej
równoczesna transmisja DMA z karty TV i na dysk (lub z dysku), to może zmiana
kontrolera SCSI coś pomoże. Wygooglane materiały sugerowały, że to raczej
będzie problem płyty… jednak na temat problemów z DMA akurat tego modelu
płyty głównej w sieci nic nie było. Tak się składa, że miałem drugi kontroler
SCSI (wolniejszy, bo tylko Ultra-II zamiast Ultra-160, ale do jednego dysku
starczy) w tropku.

Dzisiaj znalazłem chwilkę, żeby przeprowadzić tę operację. Wyłączyłem
tropka (odcinając się od sieci – z tego powodu musiałem to zrobić, gdy
żonki nie ma w domu) i przełożyłem jego kontroler (Symbios 53c895) do
dużego. Włożyłem kartę TV, podłączyłem kamerę, uruchomiłem komputer,
zacząłem nagrywać. Po chwili sprawdziłem nagranie – brak
charakterystycznych zakłóceń jakie się pojawiały przy drugim kontrolerze
(Adaptec ASC 19160). Zostawiłem nagrywanie na dłużej i ciągle nic się nie
psuło. Tym razem to chyba rzeczywiście sukces! :-)

Po pierwszych testach karty pozostało tylko ponownie uruchomić tropka.
Oczywiście nie było to takie proste. Najpierw w ogóle się nie uruchamiał. Po
poprawieniu kabelków uruchomił się, ale nie zabootował. Po podpięciu do
monitora okazało się, że pamięć CMOS mu się skasowała (i głupi BIOS
stwierdził, że procesor się zmienił). A do tego wszystkiego, z nowym
kontrolerem mu się znowu klapka nie domyka… Na szczęście w końcu udało się
go odpalić i nie jestem odcięty od świata.

No to już wiem, że karta TV na chipsecie Bt878 i kontroler SCSI Ataptec
19160 wpięte razem do płyty Asus A8N-E to kiepski zestaw i po prostu nie
działa. Ten problem rozwiązany. Pozostaje wymyślić co zrobić, żeby kamera nie
pożerała taśmy… a właściwie, to czy ja w ogóle potrzebuję nagrywać na VHS?

Niby sytuacja beznadziejna, ale jeszcze się nie poddałem. Najpierw
spróbowałem odpalić system w 32-bitach. 32-bitowy chroot już miałem, więc
dorzuciłem tam kernela i parę innych pakiecików, skonfigurowałem gruba
i zabootowałem. Próba zgrania czegoś… i znowu, nie minęła minuta i kernel
płacze, że mu się filesystem popsuł… wrrr…

Kolejne podejście. Skompilowałem sobie własnego kernela (64-bity, skoro
nie widać różnicy), ale z wyłączonymi niektórymi podejrzanymi
ficzerami, jak np. CONFIG_PREEMPT. Reboot, próba zgrania czegoś… i znowu
oops.

Kolejne próby to wyłączanie wszelkich sterowników. Najgorzej było z USB,
ciągle coś mi ładowało moduły, nawet jak miały alias na „off” w modprobe.conf.
Przeniosłem gdzieś odpowiedni katalog z /lib/modules i się tego USB pozbyłem.
Dalej nic to nie dało.

Wszystko wskazywało na to, że programowe możliwości mi się wyczerpały,
więc zabrałem się za sprzęt. Wyciągnąłem nieużywaną kartę sieciową
i przestawiłem w slotach karty TV i SCSI. Start systemu, próba nagrywania…
i to samo.

Już właściwie postanowiłem, że wezmę tę kartę do pracy, sprawdzić ją na
płycie Intela, bo coś ten mój Asus A8N-E podejrzany jest… ale jeszcze
chciałem parę rzeczy sprawdzić…

I w końcu ruszyło. Nie wiem dokładnie co pomogło (dość mam rebootów, nie
będę sprawdzał), ale mogła to być jedna z dwóch rzeczy: albo options
bttv latency=248 gbuffers=32 w modprobe conf (wcześniej miałem
tylko latency=200, albo nic), albo przestawienie w BIOSie
synchronizacji zegara PCI (czy jakoś tak) z To CPU na 33.333.
W każdym razie teraz od ponad 1000 sekund idzie nagrywanie i nic się jeszcze
nie sypie. :-)

Update: chwilę po wysłaniu wpisu się jednak sypło :-(

Kupiłem sobie nową zabawkę – kartę TV. Prawde mówiąc nie jest mi to
specjalnie potrzebne, ale chciałem się czymś nowym pobawić, a za kilkadziesiąt
złotych mogę zaszaleć. Karta to AverTV Studio Model 103, na bt878a.

Karta po włożeniu do kompa została automatycznie wykryta (został załadowany
odpowiedni sterownik), bez najmniejszego problemu. Nie mając innego sprzętu, ani kabla
do podłączenia sygnału TV, pierwsze co podłączyłem to aparat cyfrowy,
wykorzystując jego wyjście Video. Odpaliłem tvtime, ale bez oczekiwanego efektu
(karta została rozpoznana, ale obrazu nie było). Okazało się, że 32-bitowa aplikacja nie
może się dogadać z 64-bitowym sterownikiem w kernelu. Zainstalowałem 64-bitowe tvtime
i pojawił się obraz.

Pierwszego wieczora wypróbowałem jeszcze radio. To działało nawet poprzez
32-bitową aplikację (gnomeradio), ale niestety odbierało (na dołączonej do
karty antanie) tylko Radio Maryja. Po przestawieniu anteny udało się jeszcze
złapać Antyradio, ale słabo.

Następnego dnia zaopatrzyłem się w kabelki, żeby potestować kolejne funkcje karty.
Telewizja ruszyła, tylko większość kanałów zaśnieżone. Ale to można było
przewidzieć, bo sygnał w naszej kablówce jest nienajlepszy, a w komputerze
sporo szumów. W każdym razie Wiadomości obejrzeliśmy sobie na monitorze LCD.

Próbowałem też coś nagrać na dysk, ale wszelkie próby, jeśli już się
program dogadał z kartę, kończyły się tajemniczymi Oopsami, więc dałem sobie
z tym spokój.

W sobotę wpadł do nas mój ojciec i okazało się, że może nam odstąpić swoją
kamerę VHS (prawdę mówiąc nie miałem pojęcia, że miał coś takiego), bo kupił sobie
cyfrową. Teraz mogło zacząć się prawdziwe szaleństwo z moją nową zabawką…

Obraz z kamery wyświetlić na komputerze udało się od razu – tvtime
w końcu już się sprawdziło. Ale wypadałoby zrobić z tym coś więcej, równie dobrze
przecież mógłbym sobie podpiąć kamerę do telewizora. Zacząłem więc szukać jakiegoś
fajnego oprogramowania do tego. Najpierw coś do zrobienia kamerki internetowej.
W końcu znalazłem webcam_server które zaspokoiło
moje potrzeby na tę chwilę i przez jakiś czas parę osób mogło oglądać
niezwykle fascynującą transmisję: Ikę
przed laptopem.

Dzisiaj wróciłem do walki z nagrywaniem. Niestety wciąż tylko oopsy
i oopsy. Kombinowałem z różnymi opcjami bttv i kernela, z różnymi aplikacjami
i wciąż to samo. Pogooglałem i okazało się, że to najprawdopodobniej wina
sprzętu, najpewniej płyty głównej, która nie radzi sobie z dwoma transmisjami
DMA na raz (z karty TV i do kontrolera SCSI). Zamazywane są losowe fragmenty
pamięci jądra i właściwie powinienem się cieszyć, że na dysku mam jeszcze
jakieś dane, a nie już tylko śmieci (dobrze, że to ext3).

Wkurzyłem się trochę. Myślałem, że wreszcie mam porządną płytę główną,
a tu znowu jakiś feler wyskakuje. I to chyba nie do obejścia. Chociaż…
jeszcze wszystkich kombinacji nie sprawdziłem… z drugiej strony, żeby
sprawdzić z 32-bitowym kernelem, to znowu pół systemu musiałbym wywalić do
góry nogami… ech… może po prostu nigdy więcej składaków-PC?

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.

Postanowiliśmy sobie odświeżyć nieco sprzęt. Przez cały weekend
i poniedziałek oglądałem w sieci ceny i opisy sprzętu. We wtorek poszedłem do
sklepu Proline po płytę główną (A8N-E) i kartę grafiki (Sapphire Radeon X550
na PCI-Express). Resztę sprzętu, tj. procesor (Athlon 64 3200+), pamięć
(2* Kingston DDR 512MB 400MHz CL2.5) oraz taki panelik do obudowy z czytnikiem
kart i portami USB, zamówiłem na Allegro. Oczywiście od tej chwili nie mogłem
się doczekać przesyłek, ale liczyłem się z tym, że mogą dochodzić przez
tydzień… Żonka zamówiła sobie pamięć do laptopa.

Dzisiaj zadzwonił kurier Stolicy, a więc w sprawie paczki z procesorem
i pamięcią. Ja byłem w pracy, w Zabrzu, to odesłałem go do żonki, która
pracuje kilkaset metrów od domu. Niewiele później żonka doniosła, że odebrała
paczkę. Chwilę później, że jeszcze jedną – z pamięcią do jej laptopa.
Czyli pozostała tylko paczka z panelikiem, ale mało mnie to obchodziło, bo
reszta by mi wystarczyła do złożenia komputera.

W domku najpierw zrobiłem zaległy upgrade tropka (wiąże się to
z odłączeniem sieci, więc mogłem to zrobić tylko wtedy, gdy żonki nie ma),
a zaraz potem zabrałem się za rozbebeszanie kompa. W międzyczasie przyszedł
paczkonosz z Poczty Polskiej z panelikiem. A więc wszystkie zamówione w tym
tygodniu manele przyszły jednego dnia. 🙂

Komputerek udało się złożyć bez większych problemów, Linux wystartował,
jednak parę rzeczy na początku nie działało. Pierwsze: USB. Winną okazała się
opcja acpi=off w parametrach kernela – bez ACPI kontroler
USB nie miał przydzielonego IRQ. Drugie: karta dźwiękowa. Uaktualniłem
modprobe.conf i Linux widzi kartę… tyle, że nic nie
słychać, mimo wyłączenia wyciszenia w mikserze. Tym pobawię się później…

No i, oczywiście (może nie tak całkiem), nie zadziałała grafika. Ani
framebuffer, ani Xy. Sterownik radeon z X.org stwierdził, że nie zna
takiej karty. Znał jednak inne na podobnych kościach. Wymusiłem więc
ChipId 0x5b60 i ruszyło. Oczywiście tylko 2D, ale starczy.
Szkoda, że modułu radeonfb nie można (nie umiem?)
podobnie oszukać…

2D mi w zasadzie wystarcza… ale 3D też dobrze byłoby mieć. Więc
wypróbowałem też te paskudne (bo zamknięte) sterowniki od ATI. Po
zainstalowaniu ruszyły od kopa – nic nie musiałem ruszać w konfiguracji
– ruszyło na konfigu z moich prób ze starszymi Radeonami. Więc
mam działającą akcelerację 3D, a jednocześnie, przy normalnej pracy (2D) nie
jestem ograniczony zamkniętymi sterownikami. Niestety, na razie lepiej być nie
może.

Reszta wydaje się działać ok. Sieciówka (Gigabit Ethernet) ruszyła od
razu. Czytnik kart jest widoczny jako kilka urządzeń usb-storage odkąd
naprawiłem USB. Zegar procesora udało mi się zwalniać i przyspieszać za
pomocą cpufreq, czy idzie za tym zmiana prędkości wentylatora dowiem
się dopiero po tym jak dziecko poszło spać (wcześniej było za głośno)…

Na razie system działa 32-bitowego. Kiedyś pewnie zrobię upgrade całości
do 64-bitów, ale na razie nie chcę sobie psuć systemu. Zaraz zabiorę się za
benchmarki – wczoraj zrobiłem kilka na starym kompie i jestem ciekawy
jak wypadnie porównanie. Na oko jest trochę szybciej…