Uszkodzony procesor?

[buninek]

Przestawiłem boinca na projekt miesiąca i mam nie lada problemy. Mianowice ok 40-50% próbek wywala się.

FPU status word ffff88e1, flags:  ERR_SUMM STACK_FAULT PRECISION INVALID

Procesor to AMD Athlon 64 X2 4200. Na co dzień pracuje stabilnie z częstotliwością 2700-2750MHz.
Z powodu błedów zmniejszałem taktowanie, aż doszedłem do nominalnego - 2200 i o dziwo, i w tym wypadku
częstość błędów jest identyczna jak przy znacznym OC.

Nigdy wcześniej nie robiłem żadnych stress testów ani memtestów ponieważ nie było takiej potrzeby, komp
pracował stabilnie.
Czyżby procek już swoje wysłużył i był uszkodzony? Jak go dobrze przetestować?

[TJM]

A nie będzie to ten sam przypadek co tutaj ? http://einstein.phys.uwm.edu/forum_thread.php?id=7346

[buninek]

Może to problem programowy. Już wczoraj chciałem sprawdzić to pod innym kernelem i inną dystrybucją.
Tylko na dzień dobry, boinc wysypał wszystkie próbki.
Dystrybuowane aplikacje einsteina (i686) są linkowane dynamicznie i pod architekturą x86_64 wymagają podstawowych bibliotek 32-bit, których nie miałem. Cały dzienny limit wu został wyczerpany.
Ewentualnie przekompiluję obecny kernel z CONFIG_PREEMPT=n.

Taki primegrid (LLR) liczył poprawnie przy taktowaniu 2650. Wydawało mi się, iż jest to dość dobry test stabilności.

[buninek]

Pobrałem mprime http://www.mersenne.org/freesoft/
i zapuściłem na 6h (krótko?) torture test. Przy taktowaniu 2650 nie wykazał żadnych błędów.
Z prockiem raczej wszystko ok.

Mam prośbę do osób liczących pod linuksem, którym aplikacja nie sprawia żadnych problemów, aby sprawdziły config kernela. Chciałbym się dowiedzieć czy problem aby nie dotyczył kerneli skopilowanych z

Preemptible Kernel (Low-Latency Desktop) - YES

Bardzo łatwo to sprawdzić

Kod [Zaznacz] Rozwiń

zgrep 'CONFIG_PREEMPT=y' /proc/config.gz

Trudno mi jednoznacznie to wykluczyć, ponieważ obecnie mój dzienny limit WU = 2.

[TJM]

U mnie aplikacja nie sprawia żadnych problemów, testowana na kernelach

2.6.18-6-686
2.6.18-5-686

niestety nie powiem ci o nich nic więcej oprócz tego, że są to standardowe kernele debiana 4 (aktualny i poprzedni), po ostatnich przejściach nie chce mi się chwilowo kompilować własnych %)

/proc/config.gz niestety u mnie nie istnieje.

Daily quota da się ominąć, wystarczy stworzyć nowy host id na stronie na innym kompie/innym klientem a potem ręcznie wyedytować host cpid w starym kliencie, powinien zacząć używać nowego wpisu na stronie.

[buninek]

/proc/config.gz niestety u mnie nie istnieje.

Ponieważ kernel skonfigurowany bez 'Kernel .config support' ;D
Wszystkie nowsze tak się konfiguruje. Po prostu jest to bardzo wygodne w każdej chwili można sprawdzić jak
jest skonfigurowane jajko, które kompilowało się 3 lata temu, a config się gdzieś już zapodział.

.config o ile masz źródła powinien być tu
/lib/modules/2.6.xx/~build/.config

W twoim przypadku raczej i tak jest '# CONFIG_PREEMPT is not set'

[TJM]

Źródła obu kerneli mam zainstalowane, ale jedyny plik .config jaki znalazłem w systemie jest od amd_digital_temp.

Niemniej znalazłem konfigurację kernela, wygląda tak

# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set

[buninek]

Jajko już przekompilowałem, pozostaj ominąć limit wu i testować.
Choć już mój entuzjazm dla projektu minął, a to za sprawą beznadziejnej wydajności pod AMD. :(

Wydajność procków amd do intela ma się tak samo jak w przypadku primegrid (LLR) słabiutko.
Tu już tylko nowsze AMD II pewnie mogą dotrzymać kroku intelowi.
Chyba, że to wina słabej optymalizacji aplikacji.

[TJM]

Też to zauważyłem, raczej nie jest to wina słabej optymalizacji. Nie ma się co oszukiwać, po prostu Athlony 64/X2 to nie są zbyt szybkie procesory, przy tym samym taktowaniu są chyba wolniejsze nawet od starych konstrukcji.
Już zwykły Phenom lepiej wypada, ale nadal to żaden rarytas.

[buninek]

Wszystko wskazuje, że konfiguracja linuksowego kernela z 'CONFIG_PREEMPT=y' ma destrukcyjny wplyw na aplikację Einsteina. W dodatku generowany był złowieszczo brzmiący komunikat "FPU ... PRECISION INVALID".

Po przekompilowaniu kernela wszystko jest już ok. Szkoda tylko próbek, które wysypywały się po 7h liczenia. >:(

[TJM]

W nowszych wersjach kernela (chyba RC) jest to już podobno naprawione, tak coś mi się o oczy odbiło przy czytaniu jakiegoś changeloga.
Swoją drogą, 7h które zadania liczyło ? Wydaje się to dość długo nawet jak na AMD.

[buninek]

W nowszych wersjach kernela (chyba RC) jest to już podobno naprawione, tak coś mi się o oczy odbiło przy czytaniu jakiegoś changeloga.
Swoją drogą, 7h które zadania liczyło ? Wydaje się to dość długo nawet jak na AMD.

Siedzę na stosunkowo nowym kernelu 2.6.29.3

Zadania z serii p2030... liczą się ok 38000s, a oznaczone h1_... różnie od 18000 do 26000s, czyli baaardzo dłuuugo.

[TJM]

To czasy podobne w sumie jak na niekręconym A64 2,4GHz. Te p-cośtam liczą mi się około 10h, chociaż żadne chyba jeszcze nie miało okazji przeliczyć się w całości na niedotykanym kompie, tak więc może mógłby coś zejść z czasu.

[RAD-Poland]

na AMDX2 3800+ 2,0@2,4

h1_0739.95_S5R4__760_S5R5a_0    33,957.10     59.77     200.23  -> punktuje 21,22 pkt/h

przeliczyłem kilka próbek h1_x punktacja oscyluje 20-22pkt/h czyli nieco lepiej niż w enigmie 19,5-21,5pkt/h  ;)
na w/w CPU czasy 24000-34000sek  (6,6-9,4h)

na niekręconym Q6600 2,4 widziałem podobne czasy 6-8h ale nie pamiętam dla jakich próbek (chwilowo brak dostępu - beznetowiec)

[TJM]

Jakieś kiepskie optymalizacje enigmy musiałeś mieć, z tymi ostatnimi wynalazkami czas obliczeń na niektórych procach spada o 30% %)
Jak mi zejdą punkty z pendinga ocenię sytuację dokładniej, na chwilę obecną wygląda na to, że proc Intela łupie niestety dużo więcej punktów od AMD za ten sam czas, nawet uwzględniając ponad 50% różnicę zegara %)