Asteroids@home

Ja, siehste, mein Odroid-C1+ macht seine alle fehlerfrei, es sei denn, er ist gerade nicht an und kann die Wuzen nicht schaffen. :D
 
Mein Ryzen läuft unter Linux wie auch der von MagicEye04 und bekommt immer mal wieder ein paar AVX - und die werden häufig Sondermüll (zumindest bei mir und bei Magic). Die SSE laufen auch bei mir problemlos durch.

Win kann ich nicht gegentesten, da ich keins drauf hab.

Vielleicht sollten Ryzen-User mit Linux bei Asteroids besser nen Bogen um AVX machen?!

Gruß,
Ritschie
 
Zuletzt bearbeitet:
Heute war wieder ein Schwung defekte WUs dabei. Gestern die liefen mal überwiegend anständig.
Ich hatte vor dem Penta ja eine Weile mit Windows10 gerechnet, da kann ich mich jetzt nicht an Fehler entsinnen. Aber vielleicht gabs da eh kein AVX.

Aktuell hab ich gerade keine Muße, die Optimierungen zusammenzusuchen und AVX irgendwie auszusperren, wird eben was anderes gerechnet.
 
Ich habe ja (leider) keinen Ryzen, aber dafür habe ich meinen Lappy (i7) mal zur den Steinchen geschickt und der hat nur avx gekriegt.
Bisher keine defekten Wuzen.
Die Laufzeiten sind allerdings witzig. Von 5:30 Minuten bis 5:20 h ist alles dabei und immer 480 Credits. :D

Nachher schicke ich noch den i7-2600 hin. Mal sehen, wie der sich schlägt.
(Ich brauche eh noch ca. 3.000h für Wuprop)
 
Ich habe ja (leider) keinen Ryzen, aber dafür habe ich meinen Lappy (i7) mal zur den Steinchen geschickt und der hat nur avx gekriegt.
Bisher keine defekten Wuzen
Ohne Angabe des OS bringt uns deine Aussage bei der aktuellen Diskussion leider nicht weiter. Verwendest Du Linux?

Gruß,
Ritschie
 
Njet. Win10_64 (Lappy) und Win10_64 (i7-2600).

Beide Male auch mit Optimierung und erzwungenen AVX-Wuzen. Auf beiden bisher keine Fehler.
Aber wenn es um Linux geht, kann ich nicht helfen. :-/
 
Vielleicht kann ich helfen? Ich hab nen Ryzen 7 1700 hier unter Windows 10 x64. Wenn mir jemand sagt, wie ich die avx-WUs erzwingen kann, könnte ich gegentesten. Dann wüsste man zumindest, ob es am Ryzen liegt wenn's unter Win auch auftritt oder an einer möglicherweise Intel-lastigen Optimierung des Linux-Kompilats *noahnung*

Derweil schmeiß ich schon mal die Linux-VM an, um zu sehen was sich dort tut in Sachen AVX...
 
Zuletzt bearbeitet:
app_info.xml:
Code:
<app_info>
 <app>
 <name>period_search</name>
 <user_friendly_name>Period Search Application</user_friendly_name>
 </app>
 <file_info>
 <name>period_search_10210_windows_x86_64__avx.exe</name>
 <executable/>
 </file_info>
 <app_version>
 <app_name>period_search</app_name>
 <version_num>1021</version_num>
 <avg_ncpus>1.00</avg_ncpus>
 <max_ncpus>1.00</max_ncpus> 
 <plan_class>avx</plan_class> 
 <file_ref>
 <file_name>period_search_10210_windows_x86_64__avx.exe</file_name>
 <main_program/>
 </file_ref>
 </app_version>
 </app_info>

http://asteroidsathome.net/boinc/download/period_search_10210_windows_x86_64__avx.exe
 
08.06.2017 18:07:38 | Asteroids@home | Found app_info.xml; using anonymous platform
08.06.2017 18:07:38 | Asteroids@home | Datei auf die aus app_info.xml verwiesen wurde, existiert nicht: period_search_10210_windows_x86_64__avx.exe
08.06.2017 18:07:38 | Asteroids@home | [error] State file error: missing application file period_search_10210_windows_x86_64__avx.exe
08.06.2017 18:07:51 | Asteroids@home | update requested by user
08.06.2017 18:07:53 | Asteroids@home | Sending scheduler request: Requested by user.
08.06.2017 18:07:53 | Asteroids@home | Not requesting tasks: don't need (CPU: ; AMD/ATI GPU: )
08.06.2017 18:07:54 | Asteroids@home | Scheduler request completed

:(
 
Ich teste gerade mit meinem R7 1700 System auf ASUS Prime X370-Pro mit Bios 0612.
Auf Win 10 bekomme ich nur SS3 app habe ich nicht erzwungen, dfas mache ich später.
In der Linux VM wurden 99% der AVX WU mit Berechnungsfehler gekennzeichnet.

Jetzt wird auf die neue Bios Version 0803 mit dem AGESA 1.0.0.6 geflasht.
Dann mal schauen ob es sich dann was bessert.
 
Habe die Datei oben verklinkt.
 
Also durchgelaufen sind nun alle AVX-WUs unter Windows x64; soweit erstmal unauffällig.
http://asteroidsathome.net/boinc/results.php?hostid=423548
In welcher Phase werden die denn bei Dir als fehlerhaft gekennzeichnet? Gleich nach dem Hochladen oder erst beim Gegentest mit der "Kontrollgruppe"?

Ich werf jetzt mal die Linux-VM an und schau, was dort mit den AVX-WUs unter Ryzen passiert. Das wäre dann hier:
http://asteroidsathome.net/boinc/results.php?hostid=439324&offset=40&show_names=1&state=0&appid=
 
Zuletzt bearbeitet:
In der VM werden auch mit dem aktuellen 1.0.0.6 Microcode die meisten WU fehlerhaft berechnet.
R7 1700 @Stock in VM
 
In der VM werden auch mit dem aktuellen 1.0.0.6 Microcode die meisten WU fehlerhaft berechnet.
R7 1700 @Stock in VM
Ok, dann haben wir ja jetzt eine Konstellation, um herauszufinden woran es liegt, denn bei mir sind alle AVX-WUs unter Windows fehlerfrei durchgelaufen...
windows-avx.PNG
...und auch die bisher in der Linux-VM abgelieferten AVX-WUs sind ok :o
linux-avx.PNG

Das heißt, es besteht kein grundsätzliches Problem bei Ryzen mit AVX-Code oder den AVX-Versionen von asteriods@home, sonst wär's bei mir ja auch.

Nun müssen wir "nur" noch herausfinden, einerseits wo sich Dein und Ritschies Ryzen-System von meinem unterscheidet und andererseits wo die Gemeinsamkeit Eurer beiden Systeme liegt, das die Fehler auslöst.

Ich hab einen Ryzen 7 1700 @Stock mit Boxed-Kühler, der unter Vollast 62°C warm wird. Mainboard ist ein ASUS Prime B350-PLUS mit BIOS 0803 (AGESA 1.0.0.6) weitestgehend @Default. Manuell umgestellt ist lediglich SVM (AMD-V) Enabled für die VM-Beschleunigung, USB-Legacy Disabled und D.O.H.C @2667. Alles andere nicht angefasst. RAMs sind Crucial Ballistix Elite BLE2C8G4D26AFEA 2x 8 GB DDR4-2667 Dual-Rank mit DRAM-Voltage Auto (=1,200 V). OS ist Windows 10 Pro x64 1703, VM-Host VirtualBox 5.1.22, VM-Guest Debian 8.3.0 stable ohne grafische Oberfläche.

Von der Ferne kann ich das natürlich schwer einschätzen, aber soweit ich das sehe unterscheiden sich Eure Systeme von meinem a.) beim RAM (ich Crucial, Ihr G.Skill, allerdings unterschiedliche Modelle) und b.) beim Linux-Kernel (ich 3.16, Ihr beide mit 4.4er Kernel). Das müsste man jetzt herausdestillieren und gegentesten, dann kommen wir schon drauf :)

Nachtrag: hab mal ein Ubuntu 16.04 LTS mit Kernel 4.4.0 in ne VM geschmissen. Mal sehn, was sich dort tut:
http://asteroidsathome.net/boinc/results.php?hostid=439538&offset=85&show_names=0&state=0&appid=

Nachtrag 2: inzwischen sind etliche AVX-WUs auch mit Kernel 4.4.0 problemlos durchgelaufen:
linux44-avx.PNG

Daher würde ich die Kernel-Version eher nicht als Auslöser in Betracht ziehen. Womöglich doch eine Hardware (RAM?) Sache? *noahnung*
 
Zuletzt bearbeitet:
Also bei mir werden die direkt bei der Berechnung abgebrochen. Wenn ich mal länger zugucke, sprang der Fortschritt plötzlich von xx% auf 100% und sie wurde als fehlerhaft markiert.
Die, die vollständig durchlaufen, werden dann als gültig mit Punkten belohnt.
Für mich ist das einfach eine Imkompatibilität der AVX-App mit Ryzen und Linux, denn Windows lief ja bei mir auch fehlerfrei. Die alten Kernel wollten bei mir gar nicht erst von der install-DVD booten, nur 4.10 läuft.
 
Also bei mir werden die direkt bei der Berechnung abgebrochen. Wenn ich mal länger zugucke, sprang der Fortschritt plötzlich von xx% auf 100% und sie wurde als fehlerhaft markiert.
Die, die vollständig durchlaufen, werden dann als gültig mit Punkten belohnt.
So sieht es auch bei mir aus.

1700X watercooled
ASUS B350-Plus (0609)
2x 8GB RAM 3200MHz @ 2400MHz
Einstellungen auf default, außer RAM auf 2400MHz (gem. SPD 2133MHz) und Timings um eine Stufe verschärft.

Werd demnächst mal das neue Beta-BIOS drauf spielen und beim RAM wieder alles auf default setzen.

Edit:
1700X watercooled
ASUS B350-Plus (0803)
2x 8GB RAM 3200MHz @ 2133MHz (SPD)
Jetzt alles auf default!

Gleich nochmal testen, was Asteroids dazu sagt. Projekt resettet und der Rechner hat sich auch gleich 16 AVX geholt. To be continued ...

Gruß,
Ritschie
 
Zuletzt bearbeitet:
So richtig stabil läuft meine Kiste aber derzeit auch nicht.
Heute Nacht hat sich Seti mit dem Nvidia-Treiber gekloppt und zum Schluß war der Rechner eingefroren.
Code:
Jun 10 05:12:41 AZen kernel: [203922.085958] BUG: Bad page map in process setiathome_8.22  pte:8000000252be4867 pmd:29cd8b067
Jun 10 05:12:41 AZen kernel: [203922.085964] page:ffffe001c94af900 count:1 mapcount:-1 mapping:ffff9c50fe2dab78 index:0x10349
Jun 10 05:12:41 AZen kernel: [203922.085967] flags: 0x17ffffc000003c(referenced|uptodate|dirty|lru)
Jun 10 05:12:41 AZen kernel: [203922.085971] raw: 0017ffffc000003c ffff9c50fe2dab78 0000000000010349 00000001fffffffe
Jun 10 05:12:41 AZen kernel: [203922.085973] raw: ffffe001c9b84120 ffffe001d0003fe0 0000000000000000 ffff9c51ce00c800
Jun 10 05:12:41 AZen kernel: [203922.085974] page dumped because: bad pte
Jun 10 05:12:41 AZen kernel: [203922.085975] page->mem_cgroup:ffff9c51ce00c800
Jun 10 05:12:41 AZen kernel: [203922.085977] addr:0000000005abb000 vm_flags:08100073 anon_vma:ffff9c51c0d8c000 mapping:          (null) index:5abb
Jun 10 05:12:41 AZen kernel: [203922.085978] file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
Jun 10 05:12:41 AZen kernel: [203922.085982] CPU: 13 PID: 23475 Comm: setiathome_8.22 Tainted: P    B      OE   4.10.0-22-generic #24-Ubuntu
Jun 10 05:12:41 AZen kernel: [203922.085982] Hardware name: System manufacturer System Product Name/PRIME B350M-A, BIOS 0612 05/15/2017
Jun 10 05:12:41 AZen kernel: [203922.085983] Call Trace:
Jun 10 05:12:41 AZen kernel: [203922.085989]  dump_stack+0x63/0x81
Jun 10 05:12:41 AZen kernel: [203922.085992]  print_bad_pte+0x1df/0x2b0
Jun 10 05:12:41 AZen kernel: [203922.085994]  unmap_page_range+0x7ac/0x8b0
Jun 10 05:12:41 AZen kernel: [203922.085996]  unmap_single_vma+0x7d/0xe0
Jun 10 05:12:41 AZen kernel: [203922.085998]  unmap_vmas+0x51/0xa0
Jun 10 05:12:41 AZen kernel: [203922.085999]  exit_mmap+0xa7/0x170
Jun 10 05:12:41 AZen kernel: [203922.086001]  ? timerqueue_del+0x25/0x70
Jun 10 05:12:41 AZen kernel: [203922.086004]  mmput+0x57/0x130
Jun 10 05:12:41 AZen kernel: [203922.086005]  do_exit+0x273/0xb10
Jun 10 05:12:41 AZen kernel: [203922.086007]  ? poll_select_copy_remaining+0x150/0x150
Jun 10 05:12:41 AZen kernel: [203922.086009]  do_group_exit+0x43/0xb0
Jun 10 05:12:41 AZen kernel: [203922.086011]  get_signal+0x289/0x630
Jun 10 05:12:41 AZen kernel: [203922.086013]  do_signal+0x37/0x730
Jun 10 05:12:41 AZen kernel: [203922.086015]  ? pick_next_task_fair+0x47a/0x4b0
Jun 10 05:12:41 AZen kernel: [203922.086016]  ? __switch_to+0x23c/0x520
Jun 10 05:12:41 AZen kernel: [203922.086018]  ? __schedule+0x23b/0x6f0
Jun 10 05:12:41 AZen kernel: [203922.086019]  ? ktime_get_ts64+0x4f/0x100
Jun 10 05:12:41 AZen kernel: [203922.086021]  exit_to_usermode_loop+0x76/0xb0
Jun 10 05:12:41 AZen kernel: [203922.086023]  syscall_return_slowpath+0x59/0x60
Jun 10 05:12:41 AZen kernel: [203922.086024]  entry_SYSCALL_64_fastpath+0xab/0xad
Jun 10 05:12:41 AZen kernel: [203922.086026] RIP: 0033:0x7f0052bc018d
Jun 10 05:12:41 AZen kernel: [203922.086027] RSP: 002b:00007f0044be7de0 EFLAGS: 00000293 ORIG_RAX: 0000000000000007
Jun 10 05:12:41 AZen kernel: [203922.086028] RAX: fffffffffffffdfc RBX: 0000000000000000 RCX: 00007f0052bc018d
Jun 10 05:12:41 AZen kernel: [203922.086029] RDX: 0000000000000064 RSI: 0000000000000006 RDI: 00007f0040000950
Jun 10 05:12:41 AZen kernel: [203922.086029] RBP: 0000000000000006 R08: 0000000000000064 R09: 0000000000000000
Jun 10 05:12:41 AZen kernel: [203922.086030] R10: 00007f0040000950 R11: 0000000000000293 R12: 0000000000000006
Jun 10 05:12:41 AZen kernel: [203922.086031] R13: 0000000000000000 R14: 0000000002a02200 R15: 0000000002a023e0
Jun 10 05:12:41 AZen kernel: [203922.086676] BUG: Bad page state in process setiathome_8.22  pfn:252be4
Jun 10 05:12:41 AZen kernel: [203922.086679] page:ffffe001c94af900 count:0 mapcount:-1 mapping:ffff9c50fe2dab78 index:0x1
Jun 10 05:12:41 AZen kernel: [203922.086681] flags: 0x17ffffc0000000()
Jun 10 05:12:41 AZen kernel: [203922.086683] raw: 0017ffffc0000000 ffff9c50fe2dab78 0000000000000001 00000000fffffffe
Jun 10 05:12:41 AZen kernel: [203922.086685] raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
Jun 10 05:12:41 AZen kernel: [203922.086686] page dumped because: non-NULL mapping
Jun 10 05:12:41 AZen kernel: [203922.086687] Modules linked in: serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic twofish_generic twofish_avx_x86_64 ablk_helper twofish_x86_64_3way lrw twofish_x86_64 twofish_common dm_crypt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd snd_hda_core edac_core snd_hwdep kvm snd_pcm snd_seq_midi irqbypass snd_seq_midi_event eeepc_wmi asus_wmi sparse_keymap video input_leds snd_rawmidi snd_seq crct10dif_pclmul snd_seq_device crc32_pclmul snd_timer ghash_clmulni_intel pcbc snd soundcore aesni_intel aes_x86_64 crypto_simd ccp glue_helper nvidia_uvm(POE) cryptd shpchp i2c_piix4 8250_dw i2c_designware_platform i2c_designware_core wmi mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid nvidia_drm(POE)
Jun 10 05:12:41 AZen kernel: [203922.086719]  nvidia_modeset(POE) nvidia(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 ahci mii libahci gpio_amdpt fjes gpio_generic
Jun 10 05:12:41 AZen kernel: [203922.086728] CPU: 13 PID: 23475 Comm: setiathome_8.22 Tainted: P    B      OE   4.10.0-22-generic #24-Ubuntu
Jun 10 05:12:41 AZen kernel: [203922.086729] Hardware name: System manufacturer System Product Name/PRIME B350M-A, BIOS 0612 05/15/2017
Jun 10 05:12:41 AZen kernel: [203922.086730] Call Trace:
Jun 10 05:12:41 AZen kernel: [203922.086733]  dump_stack+0x63/0x81
Jun 10 05:12:41 AZen kernel: [203922.086735]  bad_page+0xc1/0x120
Jun 10 05:12:41 AZen kernel: [203922.086737]  free_pages_check_bad+0x5f/0x70
Jun 10 05:12:41 AZen kernel: [203922.086738]  free_pcppages_bulk+0x3f6/0x4c0
Jun 10 05:12:41 AZen kernel: [203922.086739]  free_hot_cold_page+0x232/0x260
Jun 10 05:12:41 AZen kernel: [203922.086740]  free_hot_cold_page_list+0x3f/0xa0
Jun 10 05:12:41 AZen kernel: [203922.086742]  release_pages+0x2b9/0x360
Jun 10 05:12:41 AZen kernel: [203922.086744]  free_pages_and_swap_cache+0x9b/0xb0
Jun 10 05:12:41 AZen kernel: [203922.086746]  tlb_flush_mmu_free+0x36/0x60
Jun 10 05:12:41 AZen kernel: [203922.086747]  unmap_page_range+0x761/0x8b0
Jun 10 05:12:41 AZen kernel: [203922.086749]  unmap_single_vma+0x7d/0xe0
Jun 10 05:12:41 AZen kernel: [203922.086750]  unmap_vmas+0x51/0xa0
Jun 10 05:12:41 AZen kernel: [203922.086751]  exit_mmap+0xa7/0x170
Jun 10 05:12:41 AZen kernel: [203922.086753]  ? timerqueue_del+0x25/0x70
Jun 10 05:12:41 AZen kernel: [203922.086755]  mmput+0x57/0x130
Jun 10 05:12:41 AZen kernel: [203922.086756]  do_exit+0x273/0xb10
Jun 10 05:12:41 AZen kernel: [203922.086758]  ? poll_select_copy_remaining+0x150/0x150
Jun 10 05:12:41 AZen kernel: [203922.086760]  do_group_exit+0x43/0xb0
Jun 10 05:12:41 AZen kernel: [203922.086762]  get_signal+0x289/0x630
Jun 10 05:12:41 AZen kernel: [203922.086765]  do_signal+0x37/0x730
Jun 10 05:12:41 AZen kernel: [203922.086767]  ? pick_next_task_fair+0x47a/0x4b0
Jun 10 05:12:41 AZen kernel: [203922.086769]  ? __switch_to+0x23c/0x520
Jun 10 05:12:41 AZen kernel: [203922.086772]  ? __schedule+0x23b/0x6f0
Jun 10 05:12:41 AZen kernel: [203922.086774]  ? ktime_get_ts64+0x4f/0x100
Jun 10 05:12:41 AZen kernel: [203922.086776]  exit_to_usermode_loop+0x76/0xb0
Jun 10 05:12:41 AZen kernel: [203922.086777]  syscall_return_slowpath+0x59/0x60
Jun 10 05:12:41 AZen kernel: [203922.086779]  entry_SYSCALL_64_fastpath+0xab/0xad
Jun 10 05:12:41 AZen kernel: [203922.086780] RIP: 0033:0x7f0052bc018d
Jun 10 05:12:41 AZen kernel: [203922.086781] RSP: 002b:00007f0044be7de0 EFLAGS: 00000293 ORIG_RAX: 0000000000000007
Jun 10 05:12:41 AZen kernel: [203922.086782] RAX: fffffffffffffdfc RBX: 0000000000000000 RCX: 00007f0052bc018d
Jun 10 05:12:41 AZen kernel: [203922.086783] RDX: 0000000000000064 RSI: 0000000000000006 RDI: 00007f0040000950
Jun 10 05:12:41 AZen kernel: [203922.086784] RBP: 0000000000000006 R08: 0000000000000064 R09: 0000000000000000
Jun 10 05:12:41 AZen kernel: [203922.086784] R10: 00007f0040000950 R11: 0000000000000293 R12: 0000000000000006
Jun 10 05:12:41 AZen kernel: [203922.086785] R13: 0000000000000000 R14: 0000000002a02200 R15: 0000000002a023e0
Jun 10 05:12:41 AZen kernel: [203922.095112] BUG: Bad rss-counter state mm:ffff9c51c43864c0 idx:0 val:-1
Jun 10 05:12:41 AZen kernel: [203922.095116] BUG: Bad rss-counter state mm:ffff9c51c43864c0 idx:1 val:1
 
Ich habe Asteroids mal zum validieren in der VM beim Ryzen laufen lassen.
Wäre für mich jetzt auch interessant wie die Fehler zustande kommen in dieser Konstellation.
Selbe Konfig war beim Penta bei anderen Projekten unauffällig, sowohl mit als auch ohne VM.

R7 1700@default SMT aktiviert, 47-49°C bei Last @Wasser
ASUS PRIME X370-PRO D.O.H.C @2667 Bios:0803
G Skill F4-2666C15-8GVR Single Rank mit SK Hynix Chip 15-15-15-35

Microsoft Windows 10 Professional (x64) Build 15063.296 (RS2)

VMware® Workstation 12 Player 12.5.6 build-5528349
Ubuntu Linux Mint mit 8 CPU & 8GB Ram
 
Hmmm,

die ersten 16 AVX-WUs seit dem Update sind durch - scheint jetzt zu laufen.

Ich werde demnächst mal versuchen, den RAM wieder auf die für Ryzen versprochenen 2400MHz für dual rank zu heben. Sollte bei 3200er Modulen ja wohl möglich sein?! *noahnung*

Gruß,
Ritschie
 
Bei mir sind mittlerweile alle AVX-WUs in der Linux-VM fehlerfrei durchgelaufen. Wie es scheint, ist Asteroids@home unter Linux mit der AVX-App ein besserer RAM-Tester als Prime95 ;D Muss ich mir merken für meine Stabitests 8)

Ich werde demnächst mal versuchen, den RAM wieder auf die für Ryzen versprochenen 2400MHz für dual rank zu heben. Sollte bei 3200er Modulen ja wohl möglich sein?! *noahnung*
Vielleicht hat ihm Spannung gefehlt? Die G.Skill-RAMs sind doch mit 1,35 V spezifiziert, oder?
 
Zuletzt bearbeitet:
Bei mir sind mittlerweile alle AVX-WUs in der Linux-VM fehlerfrei durchgelaufen. Wie es scheint, ist Asteroids@home unter Linux mit der AVX-App ein besserer RAM-Tester als Prime95 ;D Muss ich mir merken für meine Stabitests 8)
Aber nur, wenn es wirklich am RAM liegt. Das bezweifel ich noch ein wenig.
 
Zurück
Oben Unten