PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NumberFields@home



Sysadm@Nbg
19.08.2011, 18:09
über den WUProb-Ticker bin ich drauf gestoßen:
NumberFields@home (http://stat.la.asu.edu/NumberFields/)
außer Aend und mir ist bislang keiner im Team.
sieht aus wie ein Matheprojekt ...
Apps gibts für Win und Linux (hier nur 64-bit)

:x)

Hoshione
19.08.2011, 18:16
Na dann bin ich mal froh das ich ein 64bit System habe ;):x)

Dude
19.08.2011, 18:34
NumberFields@home (http://stat.la.asu.edu/NumberFields/)
außer Aend und mir ist bislang keiner im Team.
:x)

Teammember +1

anchedo
19.08.2011, 18:46
Ich bin dann auch mal mit dabei.

n8-h4wk
19.08.2011, 18:55
Ich lass mein pc auch mal bissel mit rechnen hier :x)

aendgraend
20.08.2011, 13:23
Na dann immer rein ins Team, neue sind immer gern gesehen. :x)

n8-h4wk
20.08.2011, 16:39
Sagt mal wie lang brauchen bei euch die WU's so ?
Hab da 2 am laufen, eine mit 4h eine mit 6h, aber ohne angabe ner Restzeit und sie laufen so vor sich hin.
Kommt mir Irgendwie nicht normal vor.

Jemand ne Idee ? :rolleyes:

Sysadm@Nbg
20.08.2011, 16:53
wuprop hat für meine CPU gemessen:

* Linux 64-bit: 1.9 (0.0-3.9)
* Windows 32-bit: 4.4 (0.0-14.7)

das sind jeweils CPU-Stunden - also die längste gemessene lag bei 14 Stunden

such dir mal deine CPU hier (http://wuprop.boinc-af.org/results/projet.py?projet=NumberFields%40home&application=Get+Decics+with+Bounded+Discriminant) raus

PoHeDa
20.08.2011, 16:55
Sagt mal wie lang brauchen bei euch die WU's so ?
Hab da 2 am laufen, eine mit 4h eine mit 6h, aber ohne angabe ner Restzeit und sie laufen so vor sich hin.
Kommt mir Irgendwie nicht normal vor.

Jemand ne Idee ? :rolleyes:



Hi n8-h4wk ,

meine erste WU wurde nach 4,5 Stunden als fehlerhaft nach einem Rechnerneustart zurückgemeldet.
Die zweite WU läuft jetzt seit 6 Stunden. BoincManager und BoincView zeigen 0% Fortschritt ganze Zeit an, nur bei BoincTasks habe ich eine Fortschritt Anzeige die jetzt bei 113% steht.

Mehr Info kann ich dir im Moment nicht geben.

n8-h4wk
20.08.2011, 17:08
Danke für die schnellen Antworten da scheints ja normal zu sein mit denn 0% in BOINC

Dude
20.08.2011, 17:28
Unter BoincTask gibtst auch anstelle von 0% eine Fortschrittsanzeige.
Aktuell läuft bei mir die erste immer noch nach knapp 7:30h.

HJL
20.08.2011, 18:22
Ich hab mal 18 Stück durchgerechnet,
die Zeiten lagen zwischen 23 min und 8,5 h
Fehler hatte ich keine !
;) Credits sehen "gewürfelt" aus ;)

Grüße

:x) hl

n8-h4wk
20.08.2011, 23:22
Jo bei mir is jetzt auch die erste fertig mit 8,5h. Gab auch gerade mal 100 punkte für ...
:shocked:

Dude
21.08.2011, 07:23
Aktuell läuft bei mir die erste immer noch nach knapp 7:30h.
Soeben wurde die 12h durchbrochen. Wie lange sie wohl noch laufen möchte :confused:

grobij
21.08.2011, 10:25
bei mir eine mit 25h - 600 Credits

Dude
21.08.2011, 16:17
bei mir eine mit 25h - 600 Credits

Dank fehlender Fortschrittsanzeige werde ich mich mal überraschen lassen wie lange sie laufen wird.

n8-h4wk
21.08.2011, 17:22
Also mein längste war bis jetzt bei rund 9h.
Hatte aber auch schon einige kürzere zwischen drinn.

Kann es sein das man hier unter Linux 64bit schneller ist als unter Win?
Da würde es sich vlt lohnen mal mein Ubuntu wieder zu Booten :D

tocx
05.09.2011, 12:35
kleiner Bugfix etc. beim Projekt

New and Improved executable now available.
I fixed a rare bug that was causing about 1 out of every 1000 WUs to crash. Not a big deal, unless you were one of the unlucky ones to get such a WU.
The app also checkpoints more often now and gives finer resolution with the progress meter.

tocx
06.09.2011, 23:10
kleine Info zur Creditvergabe:

Aktuell gibt es hier recht starke Unterschiede bei credits pro zeit => Problem wird demnaechst angegangen um eine konstantere creditvergabe zu gewaehrleisten. Weiterhin sieht es auch danach aus das die Credits angehoben werden.
Linuxhosts bekommen aktuell das 2-3 fache an Credits pro Stunde. Ob das ebenfalls ein Fehler ist oder die App (64Bit Linux, 32Bit Windows) einfach nur besser ist kann ich noch nicht sagen. Mal schaun was der Admin antwortet.

zur Diskussion bei NumberFields (http://stat.la.asu.edu/NumberFields/forum_thread.php?id=20)

EDIT:
glatt vergessen: fuer Linux gabs heut nochmal ne neue App, das es mit der Korrektur in 1.05 auf einigen Hosts Probleme gab


Hinzugefügter Post:

Eric (Projektadmin) hat nun bestätigt das Linux ungefähr doppelt so schnell läuft wie Win (zumindest die Winapp fertiggestellt ist).

tocx
28.10.2011, 13:07
mal ein kleines Update:

Mittlerweile gibts es die App in der Version 2.02 fuer Linux 64Bit und eine 32Bit fuer Windows. Die Deadline wurde von 3 auf 7 Tage angehoben, da nun auch die WUs um einiges laenger sind (wenige Sekunden bis hin zu mehreren Tagen, meist dauern die laengeren nicht mehr als 16h auf einem aktuellen PC ohne HT).

offene Punkte der Projektadmins:
- stabile Creditvergabe (cr/h schwanken leider immernoch recht stark, habe deshalb nochmal im oben erwaehnten Projektthread nachgefragt)
- Fehlerbehebung: einige WUs schlagen mit Maximum Elapsed Time Exceeded fehl
- die grossen Laufzeitunterschiede der WUs verkleinern
- neue Apps: Mac, 64Bit Windows & 32Bit Linux

shka
28.10.2011, 13:52
offene Punkte der Projektadmins:
- stabile Creditvergabe (cr/h schwanken leider immernoch recht stark, habe deshalb nochmal im oben erwaehnten Projektthread nachgefragt)

Yepp, gestern/heute liefen einige Maschinen mit ca 1.1k- 3k Cr/h :undecided:

Bis dann.. shka

HGW
28.10.2011, 15:19
Q6600 oc 3,0 GHz



Laufzeit..............CPU Zeit.............Punkte

2,885.88.............2,724.02..............49.94

3,852.41.............3,347.39..............65.73

10,939.33..........10,023.06............184.92

15,503.66..........14,223.27............260.84

60,036.77..........51,689.12.............922.01

80,331.83..........71,488.56...........5,545.22

tocx
30.10.2011, 21:56
Ich habe die Statistiken die letzten Tage mal etwas genauer verfolgt: aktuell sieht es so aus als ob Windowshost hier wesentlich mehr Credits bekommen (entsprechender Post ist im Projektforum erstellt), natuerlich mit den oben erwaehnten Schwankungen (aber das betrifft auch die Linuxuser). Mittlerweile scheint ein Q6600 unter Win mehr Credits einzufahren als meine 4 Hosts unter Linux (i7-860, i5-750, i5-2410M, Athlon X4 630).
Sollte jemand Interesse daran haben Platz 4 zu halten waere es sich nicht schlecht wenn sich der eine oder andere Winuser findet der auf das Projekt schwenkt da wir diesen in den naechsten 2 Tagen verlieren (BOINC Synergy macht ca. 90k am Tag, natuerlich mit Win). Kleiner Hinweis der Q6600 von dem ich oben gesprochen habe macht 23-24k am Tag, es ist scheinbar also nicht viel noetig.
Ich werde mich dann nach 2 Monaten bei diesem Projekt erstmal etwas frustriert zurueckziehen (sehen uns dann bei WEP & PG). Sollte Eric (Projektadmin) noch etwas auf meinem Post antworten (sofern es nicht das uebliche ist) werde ich das hier natuerlich noch posten.


Hinzugefügter Post:

So es gab eine Antwort von Eric:
Win & Linux-App sind mittlerweile gleich schnell. Die Credits werden auf Basis der CPU-Zeit und der Einschaetzung vom Server wie schnell der Host ist. Durch eine Reihe schneller WUs kommt dann die Statistik wohl etwas durcheinander was in hoeheren Credits resultiert.
Nach der Erklaerung sollte es eigentlich immernoch egal sein mit welchem OS man cruncht.
Warum dies in letzter Zeit scheinbar immer die gleichen Hosts betrifft und nicht mehr alle ist mir aber noch unklar.

pschoefer
31.10.2011, 06:03
So ist eben das neue Supercreditsystem. David Anderson wollte damit projektübergreifende Gleichheit schaffen (was bei einfacher Betrachtung schon unmöglich ist), und hat stattdessen sogar die wenigstens näherungsweise Fairness innerhalb des einzelnen Projektes aufgehoben. :sad:

Selbst gecruncht habe ich von den Projekten mit diesem System bisher nur YAFU, aber durchaus auch mal in die Statistiken anderer Projekte geschaut. Meine generelle Beobachtung ist, dass neu angemeldete Rechner immer erstmal deutlich zuviel Credits bekommen. Mit der Zeit bekommen sie dann immer weniger, irgendwann wird es dann wieder leicht mehr. Richtig schlimm wird es, wenn man mit einem i7 zunächst ohne HT, dann mit HT cruncht, dann dauert es noch länger, bis die Credits halbwegs sinnvolle Werte annehmen. Das mag vielleicht gemittelt über alle Rechner und einen langen Zeitraum noch vernünftige Werte ergeben, aber für einzelne WUs ist es eine Lotterie. :rolleyes:

tocx
31.10.2011, 08:22
Das es mit dem neuen Creditsystem zu so einem durcheinander kommt (zumindest innerhalb eines Projektes) konnte ich noch nicht feststellen (ok NumberFields hat noch andere Probs und Yafu habe ich wegen vieler fehlerhafter WUs schnell abgebrochen). Bei NumberFields hatten aehnliche Host ueber 2-3Tage gesehen eigentlich auch aehnliche Credits, einen Tag war der eine eine halt beser an einem anderen Tag der andere. Die Probleme bei NumberFields sind sozussagen gleichverteilt ueber alle Hosts aufgetreten. Als Ursache dafuer das einzelne Hosts neuerdings so stark sind wuerde ich das Creditsystem erstmal auszuschliessen (einige sind schon seit Wochen dabei). Es gibt natuerlich noch die Aussage langsame & schnelle WUs, aber wie gesagt hier gab es mal eine gleichverteilung ueber die Hosts (auf 2-3 Tage gesehen), evtl. verstehe ich es aber auch nur einfach nicht.

shka
01.11.2011, 11:56
Sollte jemand Interesse daran haben Platz 4 zu halten waere es sich nicht schlecht wenn sich der eine oder andere Winuser findet der auf das Projekt schwenkt da wir diesen in den naechsten 2 Tagen verlieren (BOINC Synergy macht ca. 90k am Tag, natuerlich mit Win). Kleiner Hinweis der Q6600 von dem ich oben gesprochen habe macht 23-24k am Tag, es ist scheinbar also nicht viel noetig.

Bin mal mit dabei. (mit lauter Win's) :x)

Aber neben BOINC Synergy dreht auch LAF auf. Weitere Cruncher sind willkommen.

Bis dann.. shka

taurec
01.11.2011, 15:44
Bin seit vorgestern mit einem Dual-Core unter XP mit drauf :D

shka
01.11.2011, 16:05
kann hinkommen bei deinem Output, viel mehr habe ich ja auch nicht für das Projekt über gehabt :D:D:D

Bis dann.. shka

Hoshione
22.03.2012, 17:43
Hallo zusammen,
so langsam bekomme ich Bedenken....

habe noch 6 NumberFields - Get Decic Fields 1.02 am laufen.....

haben mit 6 Stunden begonnen, sind mittlerweile zwischen 78 und 83 Stunden bei 54 bis 59 % und einer Restlaufzeit von im Moment 55 bis 65 Stunden, die sich ständig erhöht und die Deadline ist heute Abend....nicht zu schaffen!

Kann ich hier eine Verlängerung durch bekommen ...was meint ihr den Admin mal anfunken ?

Schönen Abend noch

Hoshione:):rolleyes:

Dr. Frank-N-Furter
22.03.2012, 18:30
Hallo zusammen,
so langsam bekomme ich Bedenken....

habe noch 6 NumberFields - Get Decic Fields 1.02 am laufen.....

haben mit 6 Stunden begonnen, sind mittlerweile zwischen 78 und 83 Stunden bei 54 bis 59 % und einer Restlaufzeit von im Moment 55 bis 65 Stunden, die sich ständig erhöht und die Deadline ist heute Abend....nicht zu schaffen!

Kann ich hier eine Verlängerung durch bekommen ...was meint ihr den Admin mal anfunken ?


lass laufen!

die %-anzeige ist vollständig nichtlinear.

wenn sie in den timeout geht, hast du wenigstens 48 stunden (auf einem sehr schnellen 64-bit host) zeit bis der nächste sie abliefert.

wenn sie am samstag immernoch nicht fertig ist, solltestdu mal 'ne PM an eric schicken.

Hoshione
22.03.2012, 18:37
Nabend und Danke für die Info, habe eben in deinem alten Threat schon ne Info ähnlich wie hier gepostet, mal sehen......werde dann mal am Samstag ne PN loslassen.

Danke dir! Halt dich auf dem laufenden.

Gruß

Hoshione;):x)

Dr. Frank-N-Furter
22.03.2012, 18:43
Nabend und Danke für die Info, habe eben in deinem alten Threat schon ne Info ähnlich wie hier gepostet, mal sehen......werde dann mal am Samstag ne PN loslassen.

ich hatte anfang der woche eine auf einem E8400 (3.4 GHz), die hat fast 4 tage gebraucht.
dummerweise fährst du offensichtlich einen relatvi großen buffer auf dem host, sodaß die WU erst realtiv spät gestartet wurde. aktuell angezeigte maximallaufzeit ist übrigens 133.46 h..


ps.: nicht THREAT - bedrohung sondern THREAD - Diskussionsfaden. ;)

Hoshione
22.03.2012, 18:48
Sorry, Sorry....wenn man(n) zu schnell tippt....;)

Dr. Frank-N-Furter
22.03.2012, 18:55
Sorry, Sorry....wenn man(n) zu schnell tippt....;)

wenn ich auch was kann, dann das.. ;)

dein 1090T ist ja nun auch keine lahme mühle - wird schon passen.


der ersteller des threads hatte übrigens einen Intel(R) Atom(TM) CPU D510 mit aktivem HT - und die grace-period dann auch verpasst..

Hoshione
31.03.2012, 23:07
Mal zur Info für euch, die erste dieser Monster WUs ist durch :

Update die nächste ist geschafft ;)

http://numberfields.asu.edu/NumberFields/result.php?resultid=799178
http://numberfields.asu.edu/NumberFields/result.php?resultid=799152

Laufzeit (sek) : 788,907.21 CPU Zeit (sek) : 305,730.30 Punkte : 5,462.15
Laufzeit (sek) : 879,713.76 CPU Zeit (sek) : 305,569.10 Punkte : 6,802.95

Ist ja schon mal was oder ?


Hoshione;)

shka
07.06.2012, 08:33
Es sieht so aus, dass es auch bei Numberfield bald auf die Badge-Jagd geht.
Info-Text (http://numberfields.asu.edu/NumberFields/forum_thread.php?id=76#662)

HJL
19.10.2014, 10:46
SG ist unter den Top Ten :D
1 Mio rechne ich noch, dann erst mal Pause ....

:x) hl

desktop64
19.04.2015, 01:11
Hallo @ all,

nachfolgend mal eine Auflistung verschiedener Boinc Manager Versionen im Bezug auf NumberFields@home.

Hierbei ist der 1. Rechner meiner , die 3 anderen stammen aus den Statistiken des Projekts selbst.


Version BM 7.4.42 Windows




Memory Leaks Detected!!!

Memory Statistics:
0 bytes in 0 Free Blocks.
1119 bytes in 5 Normal Blocks.
832 bytes in 15 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 300806386 bytes.
Total allocations: 526386173 bytes.

Dumping objects ->

Version BM 7.4.36 Windows


Memory Leaks Detected!!!

Memory Statistics:
0 bytes in 0 Free Blocks.
1033 bytes in 4 Normal Blocks.
832 bytes in 15 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 300806300 bytes.
Total allocations: 2014406567 bytes.


Version BM 7.2.42 Windows


Memory Leaks Detected!!!

Memory Statistics:
0 bytes in 0 Free Blocks.
1119 bytes in 5 Normal Blocks.
832 bytes in 15 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 300806386 bytes.
Total allocations: 383530117 bytes.

Version BM 7.2.42 Linux

kein Memory Leaks Detected!!!



Nun meine Frage:

1. ist das ein Bug vom BM ?
2. ein Bug vom Projekt , also Programmfehler ?
3. ist das bekannt , also ein " alter Hut " ?
4. kann das von Euch jemand bestätigen oder auch nicht ?

Gruß desktop64

pons66
23.04.2015, 06:13
Die aktuellen WUs "Get Decics with Bounded Discriminant v3.02" und "Get Decic Fields v2.00" laufen bei mir problemlos. Die Rechenzeiten schwanken wie eh und je (2 - 26k Sekunden).

pschoefer
18.01.2017, 19:32
Die Website von NumberFields@home hat eine Auffrischung erfahren und verwendet nun die neueste Version der BOINC-Serversoftware:

Aktualisierung auf neueste BOINC-Serversoftware
Ihr habt vielleicht mitbekommen, dass das Projektforum fast einen Monat lang nicht erreichbar war.

Das wurde hauptsächlich durch ein Upgrade auf PHP7 verursacht. Nachdem wir alles andere probiert hatten, haben wir uns schließlich entschlossen, auf den neuesten BOINC-Webcode zu aktualisieren.
10.01.2017, 17:04:35 MEZ


Außerdem gibt es eine Zusammenfassung der Fortschritte, die das Projekt im letzten Jahr gemacht hat:

Das Jahr 2016 im Rückblick
Ich wollte dies kurz vor Neujahr abschicken, aber das Forum funktionierte nicht. Besser spät als nie...

Das letzte Jahr war ein sehr produktives Jahr für NumberFields@home. Eine Zusammenfassung unserer Leistungen:
1. Im letzten Mai hat die beschränkte Anwendung ihre mehrjährige Suche vollendet. Sie hat alle nicht primitiven Körper mit dem Grad 10 mit absoluten Diskriminanten kleiner oder gleich 1,2⋅10^11 gefunden.
2. Im Juli hat dann wie durch ein Wunder eine spezielle Suche den hypothetisch angenommenen Körper gefunden, nach dem sie gesucht hat. Diese Suche lief etwa 10 Monate lang ab und zu. Der Körper war eine A5-Erweiterung von Q(√421), nur bei 2 verzweigt. Ihr könnt in diesem Post mehr darüber lesen:
https://numberfields.asu.edu/NumberFields/forum_thread.php?id=234
3. Die Anwendung zu regulären Polynomen zehnten Grades verbrachte den Großteil des Jahres mit dem letzten Stufe von "Datensatz 11" (die WUs mit DS-11x271 im Namen). Ihr habt vielleicht auf der Batch-Status-Seite gesehen, dass dieser Teil der Suche nahezu abgeschlossen ist - ein wirklich großer Meilenstein. Die Suche wird mit den höheren Stufen über Q(√2) fortgesetzt.

Danke an all unsere Freiwilligen, die 2016 zu einem so erfolgreichen Jahr gemacht haben!
15.01.2017, 00:24:12 MEZ


Originaltexte:

Upgrade to latest BOINC server
You may have noticed the forums have been down for almost a month now.

This was mainly caused by an upgrade to PHP7. After trying everything else, we finally decided to upgrade the BOINC web code.
10 Jan 2017, 16:04:35 UTC

2016 year in review
I meant to send this just before the new year, but the boards were down. Better late than never...

Last year was a productive year for NumberFields@home. To summarize our accomplishments:
1. Last May the bounded app completed its multi-year search. It found all imprimitive degree 10 fields with absolute discriminant less than or equal to 1.2E11.
2. Then in July a special search miraculously found the hypothesized field it had been searching for. This search had been running off and on for about 10 months. This field was an A5 extension of Q(√421), ramified only at 2. You can read more about it on this post:
https://numberfields.asu.edu/NumberFields/forum_thread.php?id=234
3. The regular decics app spent the majority of the year on the final tier of "Data Set 11" (those WUs with DS-11x271 in the name). You may have noticed on the batch status page that this subsearch is just about done - a really big milestone. The search will continue with the higher tiers over Q(√2).

Thank you to all our volunteers who made 2016 such a successful year!
14 Jan 2017, 23:24:12 UTC

pschoefer
05.03.2017, 09:46
Ein weiterer Abschnitt des Subprojekts Get Decic Fields wurde in Angriff genommen. Außerdem hofft der Administrator, später im Jahr eine GPU-Anwendung anbieten zu können.

Neue Unterkörper-Suche
Wie ihr vielleicht bemerkt habt, hat sich die Suche über ℚ(√2) (Unterkörper 3) verlangsamt und das Warten auf Ergebnisse ist so wie Farbe beim Trocknen zuzusehen. Bei der aktuellen Geschwindigkeit wird es vielleicht länger als 10 Jahre dauern, diese Suche abzuschließen. Um Fortschritt zu machen, habe ich beschlossen, die Suche über den Unterkörper ℚ(√-2) zu starten. Das ist der vierte von sieben Unterkörpern der Menge {2,5}. Wir werden parallel mit der Bearbeitung von Unterkörper 3 weitermachen, aber wir können so wenigstens weiterhin Fortschritt bei anderen Unterkörpern machen, um das Gesamtziel des Projektes zu erreichen.

Ich hoffe, in diesem Jahr Zeit für die Entwicklung einer GPU-Anwendung zu finden, um die Suche zu beschleunigen. Allerdings sage ich das natürlich seit Jahren...
04.03.2017, 18:03:58 MEZ

Originaltext:

New subfield search
As you may have noticed, the search over ℚ(√2) (subfield 3) has started to slow down and waiting for results is like watching paint dry. At the current rate it will probably take over 10 years to finish that search. In the interest of making progress, I have decided to start the search over subfield ℚ(√-2). This is the 4th of 7 subfields for the set {2,5}. We will continue to process subfield 3 in parallel, but at least we will be able to maintain progress on other subfields for the overall goal of this project.

The hope is that I can find time this year to develop a GPU app that will help to speed up the search. Of course I've been saying this for years...
4 Mar 2017, 17:03:58 UTC

pschoefer
02.01.2018, 14:13
Da der Server etwas überlastet war, ist das automatische Auffrischen von Serverstatus und Projektfortschritt zurzeit deaktiviert und die maximale Zahl der gleichzeitig auf dem Rechner befindlichen WUs wurde verringert.

Kleineres Serverüberlastungsproblem
In den letzten paar Tagen hatten wir einige Überlastungsprobleme mit dem Server. Um die Serverlast zu verringern, habe ich die Cronjobs für batch_status und server_status temporär deaktiviert. Ich werde diese etwa einmal pro Tag manuell erzeugen. Bitte entschuldigt die Unannehmlichkeiten. Ich habe auch die maximale Anzahl der in Bearbeitung befindlichen WUs (max_wus_in_progress) von 24 auf 6 reduziert, sodass ihr möglicherweise weniger WUs in eurer Warteschlange habt.

Für diejenigen, die der Grund für die Überlastung interessiert, es war eine Kombination mehrerer Ereignisse:
1. Ein Laufwerk in unserem RAID geht kaputt, was zu Problemen mit der Festplattenleistung führt. Wir arbeiten an einer Lösung.
2. Es haben über 10000 WUs fast gleichzeitig die Rückmeldefrist überschritten. Der Server beginnt dann mit dem Erzeugen neuer Aufgaben für all diese WUs, was zu einem Arbeitsrückstand führt. Das ist der Grund für das Herabsetzen von max_wus_in_progress.
3. Der Transitioner-Dienst konnte nicht schnell genug auf die Datenbank zugreifen, wodurch er abgestürzt ist, was den Arbeitsrückstand weiter vergrößert hat.
4. Da ich nicht verstanden hatte, weshalb die WUs nicht vom Transitioner behandelt wurden, habe ich dummerweise das Verwaltungsskript "transition_all" ausgeführt, welches feststeckende Aufgaben lösen soll. Ein großer Fehler - dieses Skript hat den Transitioner-Zeitstempel für alle 600000 WUs in der Datenbank zurückgesetzt, wodurch der Transitioner nun alle WUs erneut bearbeiten musste. Das hat den Arbeitsrückstand nur verschlimmert.

Die gute Nachricht ist, dass der Server den Arbeitsrückstand fast aufgeholt hat. Ich werde euch auf dem Laufenden halten.
30.12.2017, 18:55:35 MEZ

Originaltext:

Minor server overload problems
Over the last couple days we have been having some overload problems on the server. To help reduce the server load I temporarily disabled the batch_status and server_status cron jobs. I will be manually generating those about once a day. Sorry for the inconvenience. I also reduced the "max_wus_in_progress" from 24 to 6, so you may see fewer WUs in your job queues.

For those who are interested in the cause of the overload, it was a combination of things:
1. One of the drives in our RAID is failing, causing HD performance issues. We are working to get this fixed.
2. There were 10k+ WUs that all timed out at about the same time. The server then proceeds to generate new results for all these, causing a backlog. This is the reason for reducing max_wus_in_progress.
3. The transitioner had a DB timout which caused it to crash, increasing the backlog further.
4. Not understanding why WUs were not transitioning, I stupidly ran the "transition_all" admin script since it said this would "unstick" jobs. Big mistake - this script changed the transition time of all 600k WUs in the DB, forcing the transitioner to now reprocess every WU. That only made the backlog worse.

The good news is the server is almost caught up with the backlog. I will keep you posted.
30 Dec 2017, 17:55:35 UTC

pschoefer
06.01.2018, 09:52
Auf die Überlastung folgte der Absturz. Die Reparaturarbeiten sollten in ein paar Stunden abgeschlossen sein, allzu viele Daten wurden glücklicherweise nicht verloren. Jedoch könnten in den letzten Tagen neu erstellte Benutzerkonten verloren gegangen sein.

Datenbankabsturz
Unsere Datenbank ist abgestürzt. Wir arbeiten hart daran, sie zu reparieren.
05.01.2018, 2:19:20 MEZ

Wir sind beinahe fertig. Die gute Nachricht ist, dass die meisten Tabellen intakt waren. Die einzigen problematischen Tabellen waren die WU- und die Ergebnistabelle, welche beschädigt waren und meine Sicherung war veraltet. Daher dauerte die Reparatur eine Weile und wir haben etwa 200 Zeilen verloren (von fast einer Million). Es wird interessant sein, die Reaktion der Projektdienste darauf zu sehen.

Die Datenbank wurde auf einem anderen Rechner wieder aufgebaut. Um die Arbeit abzuschließen, müssen wir MySQL auf unserem Hauptrechner neu installieren und dann die neu aufgebaute Datenbank importieren. Es ist spät hier, sodass ich nicht davon ausgehe, das vor heute Nachmittag (MEZ; in etwa 8 Stunden) zu schaffen.

Eine Nebenwirkung der neuen Datenbank ist, dass vermutlich alle Beiträge der letzten paar Tage sowie neu erstellte Benutzerkonten verloren gegangen sind. Ich bitte um Entschuldigung!

Ich bin wirklich überrascht, dass ich das hier posten kann, weil MySQL nur in Wiederherstellungsstufe 6 gestartet werden konnte, welche die Datenbank schreibgeschützt machen sollte.
06.01.2018, 7:53:12 MEZ

Originaltexte:

Database crash
We had a database crash. We are working hard to get it fixed.
5 Jan 2018, 1:19:20 UTC
We are just about done. The good news is most tables were intact. The only problematic tables were the workunit and result tables which were corrupted and my backup was out of date. So those took a while to repair and we lost about 200 rows (out of almost a million). It will be interesting to see how the project daemons respond to that.

The database has been rebuilt on another machine. To complete the process, we need to reinstall mysql on our main host and then import the newly built database. It is late over here so I don't expect this to get done until tomorrow morning (about 8 hours from now).

A side effect of the new database is that any posts over the last several days will probably be gone and the same goes for any new user accounts. Sorry about that!

I'm actually surprised I can even post this because the only way to get mysql to start was to use recovery level 6, which is supposed to make the database read only.
6 Jan 2018, 6:53:12 UTC

pschoefer
13.01.2018, 15:22
Nachdem die zum Jahresbeginn aufgetretenen Serverprobleme ausgestanden sind, nun ein inhaltlicher Rückblick auf das letzte und ein Ausblick auf das neue Jahr:

Das Jahr 2017 im Rückblick
Obwohl die Liste nicht beeindruckend aussieht, wurde im Jahr 2017 viel erreicht. Die fertiggestellten Suchabschnitte gehörten zu den bisher längsten. Zusammengefasst:
1. In der Suche über ℚ(√2) (Unterkörper 3 von 7) wurden einige weitere Stufen abgeschlossen. Es verbleiben noch etwa 9 Stufen.
2. Die Suche über ℚ(√-2) (Unterkörper 4 von 7) hat einige weitere Zeilen gefüllt. Bei dieser Suche verbleiben noch 7 Stufen.

Das sind die Ziele für das neue Jahr:
1. Entwickeln einer GPU-Anwendung. Ich habe dafür die Hilfe eines Teilnehmers angeworben. Das ist ein hehres Ziel und es könnte viele Monate dauern, bis die GPU-Anwendung verfügbar ist. Diese Anwendung wird wichtig sein, um die Suche über ℚ(√2) abzuschließen.
2. Abschließen der Suche über ℚ(√-2).
3. Die Suche über ℚ(√-5) beginnen (Unterkörper 5 von 7).
13.01.2018, 1:14:21 MEZ

Originaltext:

2017 year in review
Although the list does not look impressive, much was accomplished in 2017. The sub-searches that were completed were some of the longest so far. In summary:
1. The search over Q(sqrt(2)) (subfield 3 of 7) completed several more tiers of the search. There are about 9 tiers left to go.
2. The search over Q(sqrt(-2)) (subfield 4 of 7) filled in a bunch more rows. This one has 7 tiers left to go.

Here are the goals for the new year:
1. Develop a GPU app. I have enlisted the help of a fellow user for this. This is a lofty goal and it could be many months before the GPU app is available. This app will be critical in completing the search over Q(sqrt(2)).
2. Complete the search over Q(sqrt(-2)).
3. Start the search over Q(sqrt(-5)) (subfield 5 of 7).
13 Jan 2018, 0:14:21 UTC

pschoefer
30.01.2018, 16:46
Die fehlerhafte Festplatte, die Anfang des Jahres zu Problemen führte wird am kommenden Freitag ersetzt.

Serverwartung am kommenden Freitag
Wir werden den Server am Freitag, den 2. Februar, ab etwa 17 Uhr MEZ für einige Stunden vom Netz nehmen.

Grund dafür ist der Austausch der fehlerhaften Festplatte in unserem RAID.
30.01.2018, 2:21:26 MEZ

Originaltext:

Server Maintenance This Friday.
We will be taking the server down for several hours on Friday, Feb 2nd, starting around 9am (AZ time).

This is to replace the failing hard drive in our RAID.
30 Jan 2018, 1:21:26 UTC

pschoefer
24.03.2018, 11:34
Ein neues, eher kurzzeitiges Subprojekt, das sich mit septischen Zahlkörpern befasst, wird in den nächsten Tagen beginnen.

Neue Anwendung in Kürze
In den nächsten Tagen werden wir eine neue Zahlkörper-Anwendung einführen. Diese wird sich mit Zahlkörpern siebten Grades (auch septische Zahlkörper genannt) beschäftigen. Der beste Grenzwert ist aktuell 5*10^6 und diese Anwendung wird ihn auf 200*10^6 anheben. Das bedeutet, sie wird alle Zahlkörper siebten Grades finden, deren Diskriminante kleiner als 200*10^6 ist.

Einige weitere Informationen:
1. Diese Suche sollte nur etwa 5 bis 6 Monate laufen (könnte aber länger dauern).
2. Sie wird parallel zur aktuellen Anwendung zu decischen Zahlkörpern laufen.
3. Sie wird nur 64-Bit-Windows und 64-Bit-Linux unterstützen.
24.03.2018, 7:21:03 MEZ

Originaltext:

New application coming soon
In the coming days we will be introducing a new number field application. This one will target degree 7 fields (called septics). The current best bound is 5E6, and this app will increase that to 200E6. This means it will find all degree 7 fields whose discriminant is bounded by 200E6.

Here is some additional information:
1. This search is expected to run for only 5 to 6 months (but could take longer).
2. It will run side-by-side with the current decic app.
3. It will only support the 64bit Windows and 64 bit Linux platforms.
24 Mar 2018, 6:21:03 UTC

HJL
24.03.2018, 13:05
schön zu hören, mal wieder ein Grund, NumberFields zu rechnen,
wenn ich mit meinem jetzigen Projekt fertig bin, werde ich mal 100' h investieren ....

Urs
02.04.2018, 22:19
Ein neues, eher kurzzeitiges Subprojekt, das sich mit septischen Zahlkörpern befasst, wird in den nächsten Tagen beginnen.

Ich gaub die wus sind septisch. Die laden nicht hoch. Noch jemand?

MichaelR
03.04.2018, 18:04
Nein,alles ganz normal

Flaeminger
30.04.2018, 18:01
Ist dies das Projekt für den Marathon des 9. BOINC Pentathlon?

nexiagsi16v
30.04.2018, 18:16
Jup...

Handicap SG-FC
30.04.2018, 19:00
Ist dies das Projekt für den Marathon des 9. BOINC Pentathlon?

Ja,

Siehe auch hier: https://www.seti-germany.de/boinc_pentathlon/

KidDoesCrunch
30.04.2018, 20:07
Jau. So hab ich es verstanden.

No_Name
08.05.2018, 15:04
Ich habe bei vielen WUs auf den Clients eine drei Tage kürzere Deadline, als auf der HP angezeigt wird.
Haben andere das gleiche Problem?

Edit: Hab es hier gefunden https://numberfields.asu.edu/NumberFields/forum_thread.php?id=340#2030

Pjotr Panski
08.05.2018, 15:37
Ich habe bei vielen WUs auf den Clients eine drei Tage kürzere Deadline, als auf der HP angezeigt wird.
Haben andere das gleiche Problem?

Edit: Hab es hier gefunden https://numberfields.asu.edu/NumberFields/forum_thread.php?id=340#2030

Ist bei mir das Gleiche.. Denk aber mal das auf der HP das korrekt ist.

Gruß René

HJL
08.05.2018, 19:05
Ist bei mir das Gleiche.. Denk aber mal das auf der HP das korrekt ist.

Gruß René

verlass dich da lieber nicht drauf, hatte letztens ähnliches bei latinsquares, da war die Zeit des BM ausschlaggebend ...

Felix_M_
29.07.2018, 16:26
in etwa 11 tagen ist der batch an septics fertig, ich vermute das bleibt der einzige, d.h. wenn noch jmd seinen count erhöhenmöchte, ab gehts

pschoefer
09.09.2018, 18:28
Nach etwas über fünf Monaten sind die Berechnungen zu Zahlkörpern siebten Grades (septische Zahlkörper) jetzt vollständig.

Septic-Subprojekt abgeschlossen
Das Subprojekt zu septischen Zahlkörpern ist nun offiziell abgeschlossen. Die endgültigen Ergebnisse sind wie folgt:


38.136.713.961.009 Polynome wurden untersucht
Anzahl Polynome nach Test der Zahlkörperdiskriminante: 36.163.948
Anzahl Polynome nach Verfeinerung: 1.009.140
vergangene Zeit (Summe aller Clients) = 33,1043 Millionen Stunden


Der wichtigste Punkt ist, dass es 1.009.140 septische Zahlkörper mit einer Diskriminante kleiner als 200*10^6 gibt. Wir haben eine Textdatei mit diesen Zahlkörpern, falls jemand daran interessiert ist. Sie werden auch zur Zahlkörper-Datenbank hinzugefügt:
https://hobbes.la.asu.edu/NFDB/

Wir planen, diese Ergebnisse (mit einer ausführlicheren Diskussion) in einer Fachzeitschrift zu veröffentlichen. Ich werde mich hier mit Einzelheiten dazu melden, wenn ich weitere Informationen habe.
09.09.2018, 16:15:41 MEZ

Originaltext:

Septic App Complete
The septic app is now officially complete. The final tally of results are as follows:


Inspected 38136713961009 polynomials.
# Polys passing field disc test = 36163948.
# Polys after refinement = 1009140.
Elapsed Time (summed over all clients) = 3.31043e+07 hours


The key piece of information here is that there are 1,009,140 septic fields with discriminant less than 200E6. We have these fields available as a text file to anyone who might be interested. They will also be added to the numberfields database:
https://hobbes.la.asu.edu/NFDB/

We plan on submitting these results (with a more detailed discussion) in the form of a journal article. I will report back here with details of that as I get more information.
9 Sep 2018, 15:15:41 UTC

pschoefer
09.12.2018, 16:04
Kurz bevor der eine oder andere von uns im Rahmen des Adventscrunchens bei diesem Projekt vorbeischaut, wurde ein größerer Abschnitt in der Suche nach Zahlkörpern zehnten Grades abgeschlossen:

Neuer Rekord für Decic-Subprojekt
Das Decic-Subprojekt hat seine bisher größte Suche abgeschlossen, nämlich diejenige über ℚ(√-2), Datensatz 13x271. Dieser Durchgang hatte beinahe 5 Millionen WUs. Die aufsummierte Laufzeit aller Rechner betrug 2890 Jahre. Es wurden insgesamt 148 einzigartige Zahlkörper gefunden. Gute Arbeit, alle miteinander!
08.12.2018, 17:20:26 MEZ

Originaltext:

New record for the decic app
The decic app has completed its biggest search yet, the one over Q(√-2), dataset 13x271. This batch had almost 5 million WUs. Total run time summed over all hosts was 2890 years. It unearthed a total of 148 unique fields. Good job everyone!
8 Dec 2018, 16:20:26 UTC

pschoefer
07.01.2019, 12:05
Zum Beginn des neuen Jahres hat NumberFields@home die Erfolge des Vorjahres zusammengefasst:

Das Jahr 2018 im Rückblick
Das waren die wesentlichen Leistungen in 2018:
1. Wir haben ein neues Subprojekt durchgeführt, um alle septischen (Grad 7) Zahlkörper mit einer Diskriminante kleiner als 200*10^6 zu finden. Diese Suche dauerte etwa 6 Monate und hat die bisherige Obergrenze für die Diskriminante um einen Faktor 40 verbessert. Viele neue Zahlkörper siebten Grades wurden gefunden und in die Datenbank eingetragen. Wir sind gerade dabei, die Ergebnisse zu veröffentlichen.
2. Das Decic-Subprojekt hat die bisher größte Suche über ℚ(√-2) abgeschlossen, Datensatz 13x271. Das Decic-Subprojekt hat auch einige kleinere Suchbereiche über ℚ(√-5) mit kleineren Diskriminanten abgeschlossen.
3. Wir haben etwas Fortschritt bei der GPU-Anwendung gemacht. Wir haben jetzt eine Programmbibliothek mit änderbarer Genauigkeit (Danke Dan!) und ich habe damit begonnen, Wege zum Übertragen einiger PARI-Funktionen zu finden. Das ist kein triviales Problem und ich rechne damit, dass das mindestens noch einige weitere Monate dauern wird.

Allen ein frohes neues Jahr!
01.01.2019, 20:53:45 MEZ

Originaltext:

2018 year in review
Here are the main achievements for 2018:
1. We created a new app to find all septic (degree 7) fields with discriminant less than 200E6. This search took about 6 months to complete and extended the previous best discriminant bound by a factor of 40. Many new degree 7 fields were found and added to the database. We are currently in the process of having the results published.
2. The decic app completed the largest search to date over ℚ(√-2), dataset 13x271. The decic app also completed a bunch of smaller searches over the lower discriminant bounds for ℚ(√-5).
3. We made some progress on a GPU app. We now have a multi-precision library (thanks Dan!) and I have started looking into how to port some of the pari functions. This is not a trivial problem and still expect it to take at least several more months.

Happy New Year everyone!
1 Jan 2019, 19:53:45 UTC

Uwe-Bergstedt
12.01.2019, 17:54
NumberFields@home: User consent required for stats export
If you want your stats exported, you will need to check the consent box on the project preferences page.

In a couple days, the stats export mechanism will be changed, and if this consent is not given, then the default will be to NOT export your stats.

Sorry for the inconvenience, but this was necessary due to the recent GDPR regulations.
12.01.2019 17:01:00 · weiterlesen...


https://numberfields.asu.edu/NumberFields/forum_thread.php?id=355

Handicap SG-FC
12.01.2019, 20:22
Done

Topper
12.01.2019, 21:29
Ja , danke für den Hinweis. Habe ich auch direkt mal umgestellt.

pschoefer
12.01.2019, 21:34
Ebenfalls erledigt, auch für den Booster-Account. Hier noch die Übersetzung für den Blog:

Zustimmung des Benutzers zum Statistikexport benötigt
Wenn ihr wünscht, dass eure Statistiken exportiert werden, müsst ihr die entsprechende Option auf der Projekteinstellungsseite aktivieren.

In einigen Tagen wird der Mechanismus zum Export der Statistiken geändert und, wenn diese Zustimmung nicht erteilt wurde, werden eure Statistiken standardmäßig NICHT exportiert.

Bitte entschuldigt die Unannehmlichkeiten, aber das war nötig aufgrund der DSGVO-Regeln.
12.01.2019, 18:01:00 MEZ

Originaltext:

User consent required for stats export
If you want your stats exported, you will need to check the consent box on the project preferences page.

In a couple days, the stats export mechanism will be changed, and if this consent is not given, then the default will be to NOT export your stats.

Sorry for the inconvenience, but this was necessary due to the recent GDPR regulations.
12 Jan 2019, 17:01:00 UTC

KidDoesCrunch
13.01.2019, 11:04
Done! Thanks!

pschoefer
14.03.2019, 21:55
Ein Artikel über die Ergebnisse der im vergangenen Jahr durchgeführten Suche nach septischen Zahlkörpern kann in Kürze in der Fachzeitschrift Journal of Number Theory erscheinen:

Ergebnisse der Suche nach septischen Zahlkörpern zur Veröffentlichung angenommen
Ich hatte vor einiger Zeit erwähnt, dass wir die Ergebnisse der Suche nach septischen Zahlkörpern zur Veröffentlichung eingereicht haben. Ich freue mich, euch nun mitteilen zu können, dass der Artikel zur Veröffentlichung im Journal of Number Theory angenommen wurde.

Ich werde weitere Einzelheiten bekanntgeben, sobald diese verfügbar sind.

Danke an all unsere Freiwilligen, die das ermöglicht haben!
12.03.2019, 17:23:33 MEZ

Originaltext:

Septic Results Paper Accepted for Publication
I mentioned a while back that we submitted the results of the septic search for publication. I am now happy to report that the paper has been accepted for publication in the Journal of Number Theory.

I will continue to post additional details as they become available.

Thank you to all our volunteers for making this possible!
12 Mar 2019, 16:23:33 UTC

pschoefer
23.03.2019, 06:15
Es gibt nun klar erkennbaren Fortschritt bei der seit langem angekündigten GPU-Anwendung, nämlich eine Testanwendung für NVIDIA-GPUs unter 64-Bit-Linux. Verteilt werden einige Test-WUs mit bekannten Ergebnissen, dafür ist mindestens die Treiberversion 418.39 erforderlich und Testanwendungen müssen in den Projekteinstellungen (https://numberfields.asu.edu/NumberFields/prefs.php?subset=project) aktiviert werden.

GPU-Anwendung - Beta-Version für NVIDIA unter Linux
Nach all den Jahren haben wir endlich unsere erste GPU-Anwendung. Es ist nur eine Beta-Version für 64-Bit-Linux mit NVIDIA-GPUs. Unterstützung für andere Plattformen und GPUs wird bald folgen.

Wenn ihr beim Testen dieser Anwendung helfen möchtet, müsst ihr die Option "Die Ausführung von Testanwendung erlauben?" in den Projekteinstellungen aktivieren. Ich habe etwas Arbeit für diese Anwendung aus älteren WUs erzeugt, für welche ich die Ergebnisse kenne. Das wird helfen, mögliche verbliebene Fehler zu finden.

Einige mögliche Probleme:
1. Die Anwendung wurde mit der CUDA-SDK-Version 10.1 erzeugt und benötigt daher einen relativ neuen NVIDIA-Treiber und unterstützt nur Grafikkarten mit mindestens Compute Capability 3.0. Falls dies zu viele Teilnehmer ausschließt, werde ich die Anwendung mit einem älteren SDK bauen.
2. Ich konnte keine komplett statisch gelinkte Anwendung bauen, habe aber die Bibliotheken statisch gelinkt, die sonst am wahrscheinlichsten fehlen würden (d.h. pari, gmp, std c++).

Bitte meldet etwaige Probleme. Ich beschäftige mich immer noch nicht lange mit GPU-Anwendungen, daher bin ich mir sicher, dass es einige Probleme geben wird.

Ihr könnt auch gerne Kommentare hinterlassen, auf welche Plattformen und Grafikkarten ich mich als nächstes konzentrieren sollte. Ich plane, als nächstes OpenCL unter Linux (für ATI/AMD) anzugehen, da sich schnell übertragen lassen sollte, was ich für NVIDIA gemacht habe. Ich denke, dass die Windows-Version länger dauern wird, da ich normalerweise mingw zum Cross-Kompilieren verwende, das aber meines Wissens nicht mit dem NVIDIA-Compiler kompatibel ist.
22.03.2019, 19:53:12 MEZ

Originaltext:

GPU app - beta version for linux nvidia
After all these years, we finally have our first GPU app. It's only a beta version for 64bit linux with Nvidia GPUs. Support for other platforms and GPUs will be coming soon.

If you'd like to help test this app, you will need to check the "run test applications" box on the project preferences page. I generated a special batch of work for this app from some older WUs that I have truth for. This will help to find any potential bugs that are still there.

A few potential issues:
1. This was built with the Cuda SDK version 10.1, so it uses a relatively new Nvidia driver version and only supports compute capability 3.0 and up. If this affects too many users out there, I will need to rebuild with on older SDK.
2. I was not able to build a fully static executable, but I did statically link the ones most likely to be a problem (i.e. pari, gmp, std c++)

Please report any problems. I am still relatively new to the whole GPU app process, so I am sure there will be issues of some kind.

Also, feel free to leave comments regarding what platform, GPU, etc I should concentrate on next. I was thinking I would attack linux OpenCL (i.e. ATI/AMD) next as that should be a quick port of what I did with Nvidia. I think the windows port will take much longer, since I normally use mingw to cross-compile but I don't think that's compatible with the nvidia compiler.
22 Mar 2019, 18:53:12 UTC

-jb-
25.03.2019, 08:39
Ich lasse seit zwei Tagen die GPU-Version laufen. Bei 620 WUs waren bisher nur drei kaputt. Wer noch eine Grafikkarte in einem passenden System hat, kann sich gerne anschließen.
Aktuell gibt es auch überdurchschnittlich viele Punkte. Mit meiner 780 GTX bin ich bei deutlich über 2 Mio pro Tag.

Felix_M_
27.03.2019, 11:54
ich warte auf ne windows version, leider kein linux

Freezing
27.03.2019, 11:54
same here, muss warten...

pschoefer
29.03.2019, 14:35
Die GPU-Anwendung hat die Schwächen im bisherigen Punktevergabesystem noch stärker betont. Daher gibt es nun eine feste Punktzahl pro WU (derzeit 8000), was bei den beachtlichen Laufzeitunterschieden zwar auch nicht optimal, aber wenigstens im Mittel schon deutlich fairer ist.

taurec
30.03.2019, 11:41
Ich lasse seit zwei Tagen die GPU-Version laufen. Bei 620 WUs waren bisher nur drei kaputt. Wer noch eine Grafikkarte in einem passenden System hat, kann sich gerne anschließen.
Aktuell gibt es auch überdurchschnittlich viele Punkte. Mit meiner 780 GTX bin ich bei deutlich über 2 Mio pro Tag.

Bin jetzt mal mit 970 und 1060 dabei ...

Dennis-TW
06.04.2019, 06:21
GPU App Status Update

In der letzten Woche hat es einige neue Entwicklungen gegeben. Sie sind sowohl gut als auch schlecht.

Zuerst einmal etwas Geschichte. Der Grund, warum ich so lange gewartet habe, um eine GPU-App zu entwickeln, ist, dass die Berechnung stark von Multipräzisionsbibliotheken (gmp) und zahlentheoretischen Bibliotheken (pari/gp) abhängig war. Beide verwenden dynamisch zugewiesenen Speicher, was bei GPUs ein großes Tabu ist. Ich fand online eine Multi-Präzisionsbibliothek, die ich verwenden konnte, indem ich die Genauigkeit bis zum maximal erforderlichen Wert (ca. 750 Bit) fest kodierte und so die Abhängigkeit von Speicherzuweisungen beseitigte. Das nächste Teil des Puzzles bestand darin, eine polynomale Diskriminanzfunktion zu kodieren. Danach konnte ich endlich einen Kernel für die GPU kompilieren. Das ist die Historie für die aktuelle GPU-App. Sie ist etwa 20 bis 30 mal schneller als die aktuelle CPU-Version (abhängig von WU und CPU/GPU-Geschwindigkeiten).

Aber dann dachte ich nach.... mein GPU polynomialer Diskriminanzalgorithmus unterscheidet sich von dem in der PARI-Bibliothek (ihrer funktioniert für jeden Grad und meiner ist auf Grad 10 spezialisiert). Um also einen direkten Vergleich zu machen, habe ich den PARI-Algorithmus durch meinen in der CPU-Version des Codes ersetzt. Ich war schockiert von dem, was ich fand.... die CPU-Version war jetzt etwa 10x schneller als früher. Ich hätte nie gedacht, dass ich in der Lage wäre, einen Algorithmus zu schreiben, der 10x schneller wäre als eine gut etablierte Bibliotheksfunktion. WTF? Jetzt trete ich mir in den Hintern, weil ich das nicht früher gemacht habe!

Das bringt gemischte Emotionen mit sich. Auf der einen Seite ist es toll, dass ich jetzt eine CPU-Version habe, die 10x schneller ist. Aber es bedeutet auch, dass mein GPU-Code totaler Mist ist. Mit all der Leistung in einer heutigen GPU würde ich erwarten, dass sie mindestens 10x schneller ist als die entsprechende CPU-Version. Im Vergleich zur neuen CPU-Version ist die GPU nur 2 bis 3 mal schneller. Das ist inakzeptabel.

Der neue Plan sieht also wie folgt aus:
1. Neue CPU-Ausführungsdateien bereitstellen. Da sie um das 10-fache schneller sind, muss ich die Credits um den Faktor 10 reduzieren. (Die Credits pro Stunde bleiben für die CPU gleich, fallen aber für die GPU offensichtlich ab).
2. Entwicklung neuer und verbesserter GPU-Kernel.

Ich kann es den GPU-Benutzern nicht verübeln, dass sie an dieser Stelle das Schiff verlassen haben. Offen gesagt, die Ineffizienz der aktuellen GPU-App macht es einfach nicht wert (für sie oder das Projekt).

Wie dem auch sei, ich hatte openCL-Versionen gebaut. Die Nvidia-Version funktioniert perfekt. Die AMD-Version ist aus irgendeinem Grund fehlerhaft, ebenso wie die Windows-Version. Da ich die Kernel sowieso ändern werde, hat es keinen Sinn, sie noch zu debuggen.

Für Original hier klicken (https://numberfields.asu.edu/NumberFields/forum_thread.php?id=366)

:undecided::undecided::undecided:

pschoefer
06.04.2019, 07:32
Danke für die Übersetzung, ich war so frei, sie auch in den Blog zu übertragen. Du hast mir allerdings einen Schreck eingejagt, weil du im Thread zum falschen Projekt gelandet warst. ;)

Natürlich schon sehr ärgerlich, wenn man bedenkt, wie viel weiter das Projekt sein könnte, wenn früher jemand auf diese Idee gekommen wäre. :undecided:

Neuigkeiten gibt es auch zu dem Artikel im Journal of Number Theory: Er ist nun auf der Webseite des Journals einsehbar (https://www.sciencedirect.com/science/article/pii/S0022314X19300988), allerdings nur mit entsprechenden (kostenpflichtigen) Zugang. Soweit rechtlich möglich will Eric ihn aber auch bald kostenlos zur Verfügung stellen.

Dennis-TW
06.04.2019, 08:33
Oh...naja halt Mathe.....alles irgendwie dasselbe :D

Danke fürs umgehende Verschieben an die richtige Stelle.

Ja, ist schon ärgerlich, aber besser spät als nie.

Dennoch drängt sich natürlich die Frage auf, um wie viel mehr insbesondere wohl Mathe-Anwendungen effizienter rechnen könnten (siehe auch die optimierten Apps bei RakeSearch), wenn entsprechende Optimier-Gurus daran arbeiten würden. So ein Boinc App Kompetenzteam wäre schon eine feine Sache.

Major
06.04.2019, 11:05
.... Aber dann dachte ich nach.... mein GPU polynomialer Diskriminanzalgorithmus unterscheidet sich von dem in der PARI-Bibliothek .......

Sorry ... aber bei diesem Satzkonstrukt musste ich unwillkürlich auf den Kalender schauen, ob nicht vielleicht doch der 1.April ist https://www.smiliesuche.de/smileys/lachende/lachende-smilies-0008.gif

Handicap SG-FC
06.04.2019, 11:34
Könnte der Kram, ich kann nicht mal die Wörter aussprechen geschweige den schreiben ^^, dafür gesorgt haben das es für CPU von 270 - 8000 Punkte gab ??

Das war in den letzten Wochen schon ein arges Hin u. Her.

pschoefer
06.04.2019, 12:02
Dennoch drängt sich natürlich die Frage auf, um wie viel mehr insbesondere wohl Mathe-Anwendungen effizienter rechnen könnten (siehe auch die optimierten Apps bei RakeSearch), wenn entsprechende Optimier-Gurus daran arbeiten würden. So ein Boinc App Kompetenzteam wäre schon eine feine Sache.
Ja, wobei das durchaus auch auf nicht-mathematische Projekte zutrifft: Der Entwickler der RakeSearch-Anwendung hat kürzlich ja auch optimierte Anwendungen für Acoustics@home herausgegeben, ansonsten waren TN-Grid (dort werden die optimierten Anwendungen inzwischen ja freundlicherweise direkt vom Projekt verteilt) und DENIS@HOME die letzten Fälle solch deutlicher reiner Softwareoptimierungen (ohne Ausnutzung neuer Hardware-Features), an die ich mich erinnern kann.


Könnte der Kram, ich kann nicht mal die Wörter aussprechen geschweige den schreiben ^^, dafür gesorgt haben das es für CPU von 270 - 8000 Punkte gab ??

Das war in den letzten Wochen schon ein arges Hin u. Her.
Ja. Der Admin hat nun temporär wieder auf das alte (laufzeitabhängige) Creditsystem umgestellt, da jetzt parallel WUs mit der alten und der neuen CPU-Anwendung unterwegs sind und er niemanden dafür übermäßig bestrafen bzw. belohnen möchte.

Handicap SG-FC
06.04.2019, 12:18
Danke Patrick

xii5ku_AT
28.04.2019, 17:04
Der Admin hat nun temporär wieder auf das alte (laufzeitabhängige) Creditsystem umgestellt, da jetzt parallel WUs mit der alten und der neuen CPU-Anwendung unterwegs sind und er niemanden dafür übermäßig bestrafen bzw. belohnen möchte.
Kurz nach Freigabe der GPU-Anwendung hat er auf CreditNew umgestellt, dann auf fixe Credits/Task, und jetzt wieder auf CreditNew. -- So habe ich es jedenfalls den verschiedenen Foren-Threads entnommen. Und ein kurzer Check der neuesten 20 gültigen Ergebnisse von Eric's Host (https://numberfields.asu.edu/NumberFields/show_host_detail.php?hostid=553685) zeigt leicht variable Verhältnisse von Credits zu Laufzeit.

(Man kann von CreditNew halten was man will, aber laufzeit-proportionale Credits gehen nun wirklich gar nicht. Schlimm, dass so etwas auch schon mal beim Pentathlon zugelassen wurde.) ;-) :-(

joe_carnivore
28.04.2019, 17:17
Lief bei mir, entweder extrem credits oder extrem wenig. Abgewählt ,weis nicht wie die Lage zur Zeit ist ?

pschoefer
05.05.2019, 17:45
Der fünfte Unterkörper (ℚ(√-5)) bei der Suche nach Zahlkörpern zehnten Grades ist nun fast abgearbeitet. Die WUs der letzten Serie wurden wegen der kürzlich optimierten Anwendung deutlich verlängert, sodass aber auch deutlich weniger WUs berechnet werden müssen. Allerdings werden auch einige bereits vor einiger Zeit vorbereitete WUs für den sechsten Unterkörper (ℚ(√10)) eingestreut, die im Schnitt deutlich kürzer sind.

Unterkörper 5 erreicht die Schlussphase
Die letzte Serie von Unterkörper 5 ist angebrochen (16x12).

Dies ist die erste WU-Serie, die nach der Optimierung der Anwendung erzeugt wurde. Daher werden die Laufzeiten steigen. Diese WUs laufen durchschnittlich 2 Stunden auf meinem AMD Ryzen 2990WX. Es gibt 1,6 Millionen dieser WUs; mit der nicht optimierten Anwendung hätte es 16 Millionen gebraucht, das ist also eine riesige Verbesserung.

Ich werde in diese Serie einige WUs zu Unterkörper 6 einstreuen. Diese wurden vor einiger Zeit für die nicht optimierte Anwendung erzeugt und werden daher vergleichsweise schnell laufen. Falls ich diese separat laufen lassen würde, könnte dies zu hohe Serverlast erzeugen, daher habe ich mir das als einen guten Weg überlegt, um diese WUs zu erledigen (ohne sie neu erzeugen zu müssen, was mühsam sein kann).
04.05.2019, 19:25:13 MEZ

Originaltext:

Subfield 5 entering final phase
Subfield 5 is now on it's final batch (16x12).

This is the first batch of WUs generated since the app was optimized. As a result, run times will be going up. These WUs average 2 hour run times on my AMD Ryzen 2990WX. Note there are 1.6 million of them; with the unoptimized app it would have required 16 million, so this is a huge improvement.

I will be mixing in some subfield 6 WUs with this batch. These were generated a while ago for the unoptimized app, so will run very quickly by comparison. If I were to run them independently, it might put too much of a strain on the server, so I figured this is a good way to get them done (without having to re-generate them which can be tedious).
4 May 2019, 18:25:13 UTC

pschoefer
28.05.2019, 18:16
Nachdem der erste Versuch einer GPU-Anwendung letztlich nur zu einer signifikanten Optimierung der CPU-Anwendung geführt hatte, gibt es nun einen neuen Versuch. Mittlerweile werden Anwendungen für NVIDIA-GPUs (Windows und Linux) und AMD-GPUs (nur Linux) verteilt, wobei in den Projekteinstellungen (https://numberfields.asu.edu/NumberFields/prefs.php?subset=project) derzeit noch die Option Die Ausführung von Testanwendung erlauben? aktiviert sein muss.

Neuigkeiten zur GPU-Anwendung
Seit den letzten Neuigkeiten ist mehr als ein Monat vergangen, aber ich habe jetzt einige gute Nachrichten. Ich habe einige Verbesserungen am GPU-Quellcode vorgenommen und bin nun bereit, die neuen GPU-Anwendungen zu verteilen.

Ich werde mit der AMD-OpenCL-Version für Linux beginnen. Es wird eine Beta-Version sein. Ich hatte einige Schwierigkeiten damit, wie AMD OpenCL implementiert, und diese Anwendung funktioniert immer noch nicht auf meinem Fedora-System, was meiner Überzeugung nach am Grafiktreiber liegt. Aber ich hatte Hilfe von einem Freiwilligen namens Wiktor und sie funktioniert problemlos bei ihm (ich glaube, er nutzt Ubuntu). Bitte vergesst nicht, dass AMD offiziell nur RHEL und Ubuntu unterstützt, daher wird es interessant sein, ob diese Anwendung bei jemandem mit einer "nicht unterstützten" Linux-Distribution wie meiner funktioniert.

Ich habe auch OpenCL-Windows-Anwendungen, die mit MinGW cross-kompiliert wurden. Ich habe keine Möglichkeit, diese zu testen, und bin daher noch nicht so weit, diese auszurollen. Aber falls jemand diese offline ausprobieren möchte, lasst es mich wissen und ich schicke sie euch.
15.05.2019, 23:05:56 MEZ

Originaltext:

GPU status update
It's been over a month since our last update, but I now have some good news. I have made some improvements to the GPU code and am ready to start deploying the new GPU apps.

I will start with the AMD OpenCL version for Linux. This will be a beta version. I have had a hell of a time with the AMD implementation of openCL, and this app still doesn't work on my Fedora system, and I believe strongly it's due to the graphics driver. But I have had the help of a volunteer named Wiktor and it runs fine for him (I believe he runs Ubuntu). Please keep in mind that AMD officially only supports RHEL and Ubuntu, so I will be interested to hear if this app works for anyone with an "unsupported" linux distro like myself.

I also have openCL Windows apps that were cross compiled using mingW. I have no means of testing these, so I am not ready to deploy them just yet. But if anyone would like to take them for a spin offline, please let me know, and I can send them to you.
15 May 2019, 22:05:56 UTC

pschoefer
17.06.2019, 20:36
Wie vor einigen Wochen angekündigt, wurden die letzten WUs für Unterkörper 5 (ℚ(√-5)) bei der Suche nach Zahlkörpern zehnten Grades nun verschickt. Weiter geht es mit ein paar kurzen WUs für eine Serie zum Unterkörper 6 (ℚ(√10)) und danach mit dem Rest von Unterkörper 4 (ℚ(√-2)). Der Projektverlauf kann auf dieser Seite (https://numberfields.asu.edu/NumberFields/batch_status.html) verfolgt werden.

Unterkörper 5 fast fertig
Wie ihr vielleicht bemerkt habt, nähert sich Unterkörper 5 der Fertigstellung. In den nächsten Stunden werden die letzten WUs verschickt. Natürlich wird es noch etwa 2 Wochen dauern, während die letzten Ergebnisse eintrudeln, bis er offiziell fertig ist.

Das ist ein großer Meilenstein! Die Zeit für die Fertigstellung dieses Unterkörpers wurde ursprünglich auf über ein Jahr geschätzt. Wegen der neuen optimierten Anwendungen (auch für GPUs) hat es nur wenige Monate gedauert.

Wir werden mit Unterkörper 4 weitermachen. Aber zunächst machen wir einen kleinen Umweg und bringen Serie DS7 von Unterkörper 6 zu Ende. Lasst euch nicht von den etwa 2,5 Millionen WUs abschrecken. Diese wurden für die alten Anwendungen erzeugt und hätten etwa 2 Stunden pro Stück gebraucht, sollten mit den neueren Anwendungen aber zehnmal schneller sein. Das heißt, dass wir etwa 350000 WUs pro Tag schaffen sollten. Falls sich herausstellt, dass das zu viel Serverlast verursacht, werden wir sofort zu Unterkörper 4 springen (und Serie DS7 von Unterkörper 6 nebenher laufen lassen).

Danke euch allen für eure Beiträge! Wir hätten das nicht ohne unsere Freiwilligen schaffen können.
16.06.2019, 17:38:42 MEZ

Originaltext:

Subfield 5 almost complete
As you may have noticed, subfield 5 is nearing completion. In the next few hours the last of the work units will be sent out. Of course it will still take ~2weeks for the final results to trickle in before it's officially complete.

This is a huge milestone! This subfield was originally estimated to take over a year to complete. Due to the new optimized apps (including GPU apps), this was completed in just several months.

We will be moving on to subfield 4. But first we will make a short detour and finish off subfield 6 DS7. Don't let the ~2.5mil work units scare you. These were generated for the old apps, and would have taken about 2 hours a pop, but with the newer apps they should be about 10x faster. That means we should blow through about 350k work units per day. If this turns out to be too much of a strain on the server, then we will jump straight to subfield 4 (and run sf6 DS7 in parallel).

Thanks everyone for your contributions! We couldn't have done this without our volunteers.
16 Jun 2019, 16:38:42 UTC

lugu
19.06.2019, 23:46
Die (neue) GPU-Anwendung für Windows läuft sowohl auf meiner GTX 1060 6 GB, als auch auf der GTX 1050 Ti schön stabil. Und von der Creditausbeute her lohnt sich das auf den ersten Blick ebenfalls.

Uwe-Bergstedt
20.06.2019, 07:46
weis jemand ob die RTX2080 auch schon geht??

Sie geht bzw sie rechnet fehlerfrei :thumbup:

von 2,03sek=0,05 Credits bis 243,15sek=26,53 Credits ist alles dabei :thumbup::x)

pschoefer
18.07.2019, 18:59
Nach der Fertigstellung von Unterkörper 5 (ℚ(√-5)) werden nun neben den WUs zu Unterkörper 4 (ℚ(√-2)) auch einige Serien zu Unterkörper 7 (ℚ(√-10)) verteilt. Die Serien-Statusseite (https://numberfields.asu.edu/NumberFields/batch_status.html) wurde entsprechend aktualisiert und die fertigen Unterkörper auf eine Archivseite (https://numberfields.asu.edu/NumberFields/batch_status_tables_archive.html) ausgelagert.

Aktualisierung des Serienstatus
Ich habe die Status-Tabellen der fertigen Serien auf einer eigenen Seite archiviert - der Link befindet sich oben auf der Serienstatusseite. Das sollte die Haupt-Serienstatusseite übersichtlicher halten.

Ich habe auch eine Tabelle für die letzte Suche über {2,5} hinzugefügt (Unterkörper 7). Das unmittelbare Ziel ist immer noch die Fertigstellung von Unterkörper 4 gefolgt von Unterkörper 3, aber ich werde regelmäßig einige kleine Serien von Unterkörper 7 einstreuen, um die zukünftige Suche über Unterkörper 7 vorzubereiten.
14.07.2019, 00:04:24 MEZ

Originaltext:

Batch Status Update
I have archived the completed batch status tables to their own page - the link is at the top of the batch status page. This should help to clean up the main batch status page.

I have also added a table for the final search over {2,5} (subfield 7). The immediate goal is still to complete sf4, followed by sf3, but I will be dropping in some small batches for sf7 periodically to help set the stage for the future search over sf7.
13 Jul 2019, 23:04:24 UTC

Uwe-Bergstedt
27.07.2019, 17:16
UUUUPPPPS-- bin ich doch tatensachlich der Einzige SGler der NumberFields cruncht?!?! heute jedenfalls:shocked:

https://www.boincstats.com/stats/122/user/list/12/0/14


noch eine Projektinfo:

NumberFields-Home: Schwarze Firewall-Liste
Es ist mir aufgefallen, dass einige Benutzer vom Firewall-System der Universität auf der schwarzen Liste stehen. Dies bedeutet in der Regel, dass die Freiwilligen nicht können Download-Aufgaben oder sogar eine Verbindung mit der Website.

Wir suchen derzeit nach Möglichkeiten, die Firewall-Einschränkungen zu reduzieren, damit dies nicht mehr geschieht. In der Zwischenzeit ist es für mich eine Möglichkeit, die IT-Abteilung aufzufordern, eine IP-Adresse auf individueller Basis aufzulisten.

Wenn Sie oder jemand, den Sie kennen, Verbindungsprobleme haben, lassen Sie es mich bitte wissen, damit ich sie der weißen Liste hinzugefügt habe.
27.07.2019 03:07:06 Weiterlesen...

Achtung----Achtung: Boincstats listet nur 52 SGler von 195 Mitgliedern bei Numberfields, das bedeutet das 143 den Statsexport noch nicht zugestimmt haben :

Do you consent to exporting your data to BOINC statistics aggregation Web sites? zu finden in den Numberfields Einstellungen

AxelS
28.07.2019, 07:06
Danke für den Hinweis. Nur ich komme nicht auf die Webseite:

Seiten-Ladefehler

Fehler: Verbindung unterbrochen

Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.

Ich befürchte, ich stehe offenbar ab jetzt auf der Firewall-Schwarzliste, obwohl ich dieses Projekt seit Monaten nicht gerechnet hatte. :(:shocked:

- - - Aktualisiert - - -

Die Webseite ist abgeschaltet.

Handicap SG-FC
28.07.2019, 07:43
Hier läuft die Webseite

Felix_M_
28.07.2019, 08:52
auch bei mir keine probleme

Uwe-Bergstedt
28.07.2019, 11:03
Danke für den Hinweis. Nur ich komme nicht auf die Webseite:


Ich befürchte, ich stehe offenbar ab jetzt auf der Firewall-Schwarzliste, obwohl ich dieses Projekt seit Monaten nicht gerechnet hatte. :(:shocked:

- - - Aktualisiert - - -

Die Webseite ist abgeschaltet.

Auszug aus dem Forum:
It must be several months i got my last wu to crunch. Maybe I am blocked.

The last time they updated the firewall was on July 19th. It looks like your last contact was before that, so you may have a different issue. If you are black listed then your event log will say the connection timed out and that the "project servers appear to be down". Also, as marsinph pointed out, if you have a dynamic IP then the blocking would be temporary.

auf Goggledeutsch:
Es muss einige Monate dauern, bis mein letzter Wu knirscht. Vielleicht bin ich gesperrt.

Die letzte Aktualisierung der Firewall erfolgte am 19. Juli. Es sieht so aus, als ob Ihr letzter Kontakt davor war, also haben Sie möglicherweise ein anderes Problem. Wenn Sie auf der schwarzen Liste stehen, wird in Ihrem Ereignisprotokoll das Zeitlimit für die Verbindung angezeigt und "die Projektserver scheinen inaktiv zu sein". Wenn Sie eine dynamische IP-Adresse haben, ist die Blockierung vorübergehend.

Dennis-TW
28.07.2019, 11:58
Auszug aus meinem RSS Feed:


It has come to my attention that some users have been black listed by the university firewall system. This usually means that the volunteer cant download tasks or even connect to the website.

We are currently looking at ways to reduce the firewall restrictions so this will stop happening. In the meantime, the work around is for me to request the IT department to white list an IP address on an individual basis.

If you or someone you know is experiencing connection problems, please let me know so I can have them added to the white list.

Ich wurde darauf aufmerksam gemacht, dass einige Benutzer vom Firewall-System der Universität auf die schwarze Liste gesetzt wurden. Dies bedeutet in der Regel, dass der Freiwillige keine Aufgaben herunterladen oder sich gar mit der Website verbinden kann.

Wir prüfen derzeit Möglichkeiten, die Einschränkungen der Firewall zu reduzieren, damit dies nicht mehr der Fall ist. In der Zwischenzeit ist es meine Aufgabe, die IT-Abteilung zu bitten, eine IP-Adresse individuell auf eine Whitelist zu setzen.

Wenn Sie oder jemand kennen, von dem Sie wissen, dass er Verbindungsprobleme hat, lassen Sie es mich bitte wissen, damit ich ihn in die Whitelist aufnehmen kann.

Uwe-Bergstedt
28.07.2019, 12:18
hallo Dennis les doch mal den Post 88:D

Dennis-TW
28.07.2019, 13:51
Uuups.....naja, ich komm jetzt in das Alter, wo man das als normal ansehen muss :D

Auf der anderen Seite "Doppelt hält besser", "Einmal ist kein Mal" und "Aller guten Dinge sind .... äh .... zwei" :P

pschoefer
28.07.2019, 22:29
Hoffentlich wird die Firewall rasch weniger aggressiv eingestellt. Wenn man mit täglich wechselnder IP-Adresse unterwegs ist, lohnt es sich im Falle einer Sperre ja kaum, sich auf die Weiße Liste setzen zu lassen.

AxelS
29.07.2019, 20:28
ka, was das gestern früh war. Auf jeden Fall ist die Webseite jetzt erreichbar als ob nichts gewesen wäre.

pschoefer
07.08.2019, 07:07
Eine neue Version der GPU-Anwendungen behebt ein Problem, das dazu führen konnte, dass große Teile der WU auf CPU berechnet werden:

neue Version der GPU-Anwendungen
Ich habe festgestellt, dass die bisherige Version der GPU-Anwendungen beim Datensatz 15x271 sehr langsam war. Ich habe das Problem gefunden - ein großer Teil der Diskriminanten war zu groß für die fest programmierte Genauigkeit. Wenn das passiert, übergibt die GPU an die CPU, um damit umzugehen. Daher verbrachte die GPU mehr Zeit im Leerlauf, während sie darauf wartete, dass die CPU die Aufgabe beendet. Als Nebeneffekt konnten die WUs auch fast einen ganzen CPU-Kern nutzen.

Ich habe die fest programmierte Genauigkeit erhöht und mit den schwierigen Datensätzen sowie dem neuesten Datensatz 16x271 getestet. Das Problem scheint behoben, aber bitte meldet etwaiges unerwartetes Verhalten.
07.08.2019, 6:39:56 MEZ

Originaltext:

new GPU app versions
I was noticing a slow down with the GPU app versions on the 15x271 data set. I found the problem - a large fraction of the discriminants were exceeding the hard coded precision. When this happens the GPU kicks it back to the CPU to handle. As a result, the GPU spent more time idling as it waited on the CPU to finish the task. A side effect of this was that the WU would also use almost an entire CPU core.

I increased the hard coded precision and tested on the troublesome data sets as well as the newest 16x271 data set. The issue seems to be fixed, but please report any unexpected behavior.
7 Aug 2019, 5:39:56 UTC

pschoefer
13.10.2019, 14:14
Für diejenigen, die anhand des Serienstatus (https://numberfields.asu.edu/NumberFields/batch_status.html) den Fortschritt des Projektes nachvollziehen möchten, wurde ein Fahrplan für den Rest dieses Jahres bekanntgegeben:

Ablaufplan
Ich weiß, dass einige von euch gern wissen, welche Serien als nächstes bearbeitet werden, hier ist der Plan...

Serie 13x270 von Unterkörper 3 ist fast vollständig bearbeitet. Danach werden wir ein, zwei Wochen lang einige niedrig hängenden Früchte für Unterkörper 7 einsammeln. Anschließend geht es zurück zu Unterkörper 3, Serie 13x271. Das ist eine sehr große Serie, sodass ich erwarte, dass das bis Ende Dezember, vielleicht in den Januar hinein, reichen wird.
09.10.2019, 1:33:36 MEZ

Originaltext:

Batch plan
I know some of you like to know the batch plan, so here it is...

Batch 13x270 is nearing completion for subfield 3. After that, we will spend a week or two picking some of the low hanging fruit on subfield 7. Then it's back to subfield 3, batch 13x271. This is a very big batch, so I expect it to last until the end of December, possibly into January.
9 Oct 2019, 0:33:36 UTC

pschoefer
03.11.2019, 06:31
Ab sofort unterstützt NumberFields@home auch AMD-GPUs unter Windows, wobei derzeit noch in den Projekteinstellungen das Ausführen von Testanwendungen erlaubt sein muss, um die entsprechende Anwendung zu erhalten. Auch die schon vorher verfügbaren OpenCL-Anwendungen wurden aktualisiert.

Neue Versionen der OpenCL-GPU-Anwendungen verfügbar
Ich habe soeben die OpenCL-Version für AMD-GPUs unter Windows als Testanwendung eingepflegt. Ich werde beobachten, ob es fehlerhafte Ergebnisse gibt, aber bitte meldet etwaiges merkwürdiges Verhalten.

Ich habe auch neuere OpenCL-Versionen für AMD-GPUs unter Linux und NVIDIA-GPUs unter Windows eingepflegt. Der OpenCL-Code enthält einige kleinere Optimierungen; nichts größeres.
03.11.2019, 5:36:57 MEZ

Originaltext:

New GPU OpenCL versions available
I just deployed the windows AMD openCL version as a beta app. I will monitor results for errors, but please report any strange behavior.

I also deployed newer openCL versions for AMD linux and Nvidia windows. The openCL code had a couple minor tweaks; nothing major.
3 Nov 2019, 4:36:57 UTC

nexiagsi16v
03.11.2019, 19:24
Die Test-WUs sind Quorum 1 und werden gültig.
Beim Großteil der Laufzeit passiert nur was hinterm Komma, dann springt die Fortschrittsanzeige. Kaum bei 90 % angekommen, schwupps 100%.
Auslastung 470er ~80%, 5700er 70%....entsprechend geringe Temps und Lüfterspeeds. RAM-Bedarf so bis 600MB.

Evtl. wird die Auslastung mit einer besseren CPU vorn dran auch höher.

Wegen den Lufzeiten muss man mal schauen. Mein Problem, beide Karten stecken in einem Rechner, daher kann ich die LZ nicht der entsprechenden Karte zuordnen. Somit kann ich nur sagen, dass die Laufzeiten zwischen 300 und 1300 Sekunden liegen...Punkte 18 bis 42.

Ob sich die GPUs damit lohnen, kann ich schlecht einschätzen, da ich keine Statistiken von dem Projekt habe und nicht weiß wie LZ/Punkten bei einer CPU-WU ist.

Bis jetzt sieht es so aus, dass hier auch ältere AMD-Karten was leisten können.

Dj Ninja
15.11.2019, 08:41
Numberfields war eines meiner Lieblingsprojekte für CPUs... bis sie unbedingt eine GPU-Version herausbringen mussten. Seit dem interessiert es mich leider nicht mehr.

pschoefer
15.01.2020, 18:15
Wie gewohnt warf der Projektadministrator einen Blick zurück auf das Vorjahr, welches recht ertragreich war:

Das Jahr 2019 im Rückblick
Ein weiteres Jahr ist vorübergegangen. Es war ein sehr produktives Jahr. Das waren die Höhepunkte:
1. Die Ergebnisse der Suche nach septischen Zahlkörpern, die 2018 beendet wurde, wurden vom Journal of Number Theory angenommen und veröffentlicht.
2. Eine GPU-Anwendung für die Suche nach decischen Zahlkörpern wurde entwickelt. Letztlich wurden Versionen sowohl für NVIDIA- als auch AMD-Grafikkarten und sowohl für Linux als auch für Windows eingeführt. Während der Entwicklung fand ich eine Möglichkeit zur Optimierung der CPU-Version, welche daraufhin umgesetzt wurde.
3. Das Decic-Subprojekt hat die Suche über ℚ(√-5) (Unterkörper 5) abgeschlossen.
4. Das Decic-Subprojekt hat die Suche über ℚ(√-2) (Unterkörper 4) abgeschlossen.
5. Die Suchen an der Untergrenze der Diskriminanten für die Unterkörper 6 und 7 wurden abgeschlossen.
6. Die Suche über ℚ(√2) (Unterkörper 3) ist zu höheren Stufen vorgedrungen. Es verbleiben jetzt nur noch 3 Stufen in dieser Suche.

Vielen Dank an alle und ein großartiges neues Jahr!
01.01.2020, 23:30:05 MEZ

Originaltext:

2019 Year in Review
So another year has come and gone. It has been a very productive year. Here are the highlights:
1. The results for the septic search, which were completed in 2018, were accepted and published in The Journal of Number Theory.
2. A GPU app was developed for the decic search. Versions were eventually introduced for both Nvidia and AMD cards, and for both the Linux and Windows Platforms. During development, I discovered an opportunity for optimizing the CPU version which was subsequently implemented.
3. The decic app completed the search over ℚ(√-5) (subfield 5).
4. The decic app completed the search over ℚ(√-2) (subfield 4).
5. Searches were completed over the lower discriminant bounds for subfields 6 and 7.
6. The search over ℚ(√2) (subfield 3) progressed further into the higher tiers. We now only have 3 more tiers to go in that search.

Thanks everyone and have a wonderful New Year!
1 Jan 2020, 22:30:05 UTC

nexiagsi16v
06.03.2020, 15:29
Nur zur Info, RX 5xxx und AMD Adrenali höher als 19.10.1, funktioniert nicht. Auch die aktuelle Version 20.2.2. läßt die WUs nur bis 10% kommen und da verbleiben sie auch, obwohl die GPU bei 100% cruncht.

Flaeminger
12.05.2020, 14:25
Mal ne saublöde Frage von mir:
Warum sehe ich meinen Stand von diesem schicken Projekt weder bei FreeDC noch bei BOINCStats, kann in meinem Konto bei NumberFields@home wunderbar die exakten Punkt meiner anderen aktuellen Projekte sehen.
Mache ich mal wieder was falsch (die Hin- und Her-Aktualisierung habe ich bereits ein paar mal vorgenommen, es ändert sich nix.

Dank und Gruß

No_Name
12.05.2020, 14:28
Datenexport im Projekt zugestimmt? (Ich meine auch bei NF ist es erforderlich, kann es aber gerade wg. blockiertem DNS Eintrag nicht sehen :D )

Flaeminger
12.05.2020, 14:34
"Datenexport im Projekt zugestimmt?"

Ich bin soooo dumm.

DANKE, auch für die schnelle Antwort:x)

Urs
18.08.2020, 23:30
In Sachen Plazierung rollt da einiges von hinten herran.

Da GPUGrid ja grade keine wus hat könntet ihr eure GPU`s ja hier mal zwischenparken.;)

taurec
19.08.2020, 22:13
In Sachen Plazierung rollt da einiges von hinten herran.

Da GPUGrid ja grade keine wus hat könntet ihr eure GPU`s ja hier mal zwischenparken.;)

Ich denke bei AMICABLE sieht es derzeit noch ein bisschen brenzliger aus ...
Und jetzt wird es auch wieder wärmer :cry:

KidDoesCrunch
21.08.2020, 09:21
Hab mal zwei GPU's auf Number geschaltet.

pschoefer
13.11.2020, 15:50
Eine neue Version der CPU-Anwendung beschleunigt die Berechnungen bei NumberFields@home um etwa ein Drittel. Eine ähnliche Verbesserung der GPU-Anwendung ist in Arbeit.

Neue und verbesserte Anwendungen in Vorbereitung
Ich habe einige Verbesserungen am CPU-Code vorgenommen. Damit sehe ich je nach Situation eine Beschleunigung irgendwo zwischen 30% und 40%.

Ich habe die neue Anwendung für 64-Bit-Linux ausgerollt. Gerade versuche ich, sie für 64-Bit-Windows gebaut zu bekommen. Ich hoffe, das irgendwann morgen fertig zu haben (Anm. d. Übersetzers: die neue Anwendung für 64-Bit-Windows wurde inzwischen auch ausgerollt).

Der nächste Schritt ist, die gleichen Tricks bei den GPU-Versionen zu verwenden. GPUs können sehr pingelig sein, daher könnte es einige Wochen dauern, bis ich dafür etwas habe, das der Mühe wert ist.
13.11.2020, 3:51:56 MEZ

Originaltext:

New and improved apps coming soon
I have made some improvements to the cpu code. I am seeing somewhere between 30% and 40% speedup, depending on the case.

I have deployed the new executable for 64bit linux. I am currently trying to get it to build for 64bit windows. I hope to have that ready by tomorrow sometime.

The next step is to use these same tricks on the GPU versions. GPUs can be very finicky, so this might take several weeks before I have something worthwhile.
13 Nov 2020, 2:51:56 UTC

pschoefer
02.01.2021, 16:55
Wieder einmal ist ein neues Jahr angebrochen und der Projektadministrator fasst zusammen, was sich im vergangenen Jahr bei NumberFields@home ereignet hat. Die erste der unter Punkt 4 erwähnten verbesserten GPU-Anwendungen wurde noch gestern Abend ausgerollt, sodass NVIDIA-GPUs unter Linux nun etwa 33% schneller unterwegs sind als bisher. Die neuen OpenCL-Anwendungen für NVIDA-GPUs unter Windows und für AMD-GPUs dürften innerhalb einer Woche hinzukommen.

Das Jahr 2020 im Rückblick
Der Albtraum 2020 ist zu Ende gegangen. Dies waren die Höhepunkte des Jahres bei NumberFields@home:

Die sonstigen Suchen wurden abgeschlossen. Außer für {2,5} ergeben sich daraus die Körper für alle bei {p}, {q} oder {p,q} verzweigten imprimitiven decischen Zahlkörper.
Viele der unteren Stufen in der Suche über ℚ(√-10) (Unterkörper 7) wurden abgeschlossen.
Einige weitere WU-Sätze für die Suche über ℚ(√2) (Unterkörper 3) wurden abgeschlossen, sodass praktisch nur noch ein abschließender Monster-Satz aussteht. In unserem aktuellen Tempo wird dieser Satz etwa die erste Hälfte des Jahres 2021 benötigen.
Die CPU-Anwendungen (für 64-Bit-Machinen) wurden verbessert, sodass die Geschwindigkeit um durchschnittlich etwa 35% zunahm. Verbesserte GPU-Anwendungen werden in Kürze herausgegeben.

Danke an alle für eure Beiträge und ein wunderbares neues Jahr!
01.01.2021, 19:12:28 MEZ

Originaltext:

2020 Year in Review
The 2020 shit show has come to an end. Here are the NumberFields highlights for the year:

The miscellaneous tables were completed. Except for the {2,5} case, this gives the fields for all imprimitive decics ramified at {p}, {q}, or {p,q} for all primes p < q < 13.
Finished many of the lower tiers for the search over ℚ(√-10) (subfield 7).
Completed a few more batches for the search over ℚ(√2) (subfield 3), essentially leaving the final monster batch. At our current rate, this batch will take approximately the first half of 2021 to complete.
The CPU apps (for 64bit machines) were improved to give an average speed increase of about 35%. Improved GPU apps will be rolled out in the near term.

Thanks everyone for your contributions and have a wonderful New Year!
1 Jan 2021, 18:12:28 UTC

pschoefer
15.01.2021, 23:02
NumberFields@home ist derzeit wegen einer defekten Festplatte nicht erreichbar. Ersatz sollte im Laufe der nächsten Woche eintreffen.

pschoefer
27.01.2021, 07:37
Etwa zwei Wochen nach einem Festplattenschaden ist das Projekt nun wiederhergestellt. Da zur Wiederherstellung auf eine wenige Tage ältere Datensicherung zurückgegriffen werden musste, gibt es noch Probleme mit WUs, die in der Zeit zwischen der Sicherung und dem Ausfall zurückgemeldet oder neu verschickt wurden.

Endlich zurück nach Festplattenausfall
Der Ausfall war so schlimm, dass die Datenbank nicht repariert werden konnte. Die erste nicht beeinträchtigte Datensicherung war 2 Tage alt. Die Wiederherstellung scheint funktioniert zu haben, aber es gibt möglicherweise Probleme, weil dieser Stand nicht mit den WUs, die zurückgemeldet werden, übereinstimmt.

Ich habe die Meldefrist für alle ausstehenden WUs um weitere 4 Tage verlängert, um den Leuten mehr Zeit zum Zurückmelden zu geben, aber alle WUs, die in den 2 Tagen vor dem Ausfall verschickt wurden, sind nicht in der Datenbank und ich bin unsicher, was damit passiert.

Bitte entschuldigt die Unannehmlichkeiten!
26.01.2021, 23:45:59 MEZ

Originaltext:

Finally recovering from hard drive crash.
The crash was so bad that the database could not be repaired. The first non-corrupted backup was 2 days old. Restoring from there seems to have worked but there are probably issues since it will be out of sync from results that get returned.

I pushed the deadline back another 4 days for any outstanding WUs to give people time to return them, but anything issued 2 days prior to the crash will not be in the database so I am not sure how that will play out.

Sorry for the inconvenience!
26 Jan 2021, 22:45:59 UTC

lugu
04.07.2021, 11:52
Hier gibt es mittlerweile auch was für alle Badge-Jäger. :x)

Urs
04.07.2021, 16:23
Was wünscht der Herr mitzuteilen?

Die badges gibt es doch schon lange und haben sogar einen eigenen tread.
Dort hast du auch schon gepostet (https://www.seti-germany.de/forum/threads/6313-Badges-NumberFields-Home/page2?p=320554#post320554).

lugu
05.07.2021, 08:23
Ha, tatsächlich. Ich werd alt... :D

Aber sie haben wohl die Badges ausgetauscht (https://signature.statseb.fr/index.py?badge=147).

Dennis-TW
22.08.2021, 15:50
Aber sie haben wohl die Badges ausgetauscht (https://signature.statseb.fr/index.py?badge=147).
Da ich gerade im entsprechenden Thread im NumberFields Forum (https://numberfields.asu.edu/NumberFields/forum_thread.php?id=405) bin:

Ja, das Aussehen der Badges wurde im Juli geändert und auch ein paar weitere Stufen eingebaut/erweitert.

Die aktuellen Stufen für ein neues Badge sind jetzt:

10k, 100k, 500k, 1M, 2M, 5M, 10M, 25M, 50M, 100M, 250M, 500M, 1G, 2G, 5G, 10G

Wäre übrigens auch eine Änderung im SG Wiki (https://www.seti-germany.de/wiki/NumberFields@home) wert :Pfeif:

walli
22.08.2021, 18:10
Wäre übrigens auch eine Änderung im SG Wiki (https://www.seti-germany.de/wiki/NumberFields@home) wert :Pfeif:

Eingepflegt - zumindest rudimentäre Vorarbeit geleistet :).

pschoefer
18.11.2021, 08:20
Die OpenCL-Anwendung kann jetzt auch auf Intel-GPUs genutzt werden, sofern in den Projekteinstellungen die Ausführung von Testanwendungen erlaubt ist. Offen ist die Frage, ob auch dafür ein CPU-Kern reserviert werden muss und ob dieser nicht mit der CPU-Anwendung allein mehr leisten würde.

Unterstützung für Intel-GPUs
Ich habe gerade Unterstützung für Intel-GPUs eingerichtet. Es gibt zwei Versionen, 64-Bit-Linux und 64-Bit-Windows, beide benötigen OpenCL 1.1 oder höher.

Ich habe keine Intel-GPU, kann sie also nicht testen. Es ist aber der gleiche OpenCL-Code, der auf anderen GPUs funktioniert, theoretisch sollten sie also funktionieren. Für die Linux-Version musste ich nur das Intel-OpenCL-SDK herunterladen und die Anwendung gegen die Include-Dateien und Bibliotheken von Intel linken. Die Windows-Version habe ich wie für AMD- und NVIDIA-Karten mit mingw64 cross-kompiliert.

Da die Anwendungen neu und ungetestet sind, habe ich sie als Beta markiert.
17.11.2021, 23:57:27 MEZ

Originaltext:

Support for Intel GPUs
I just added support for Intel GPUs. There are 2 versions - 64 bit linux and 64 bit windows, both require openCL 1.1 or higher.

I don't have an Intel GPU, so I can't test them. But it's the same openCL code that works on other GPUs, so in theory they should work. For the linux version, it was just a matter of downloading the Intel openCL SDK and then linking against Intel's include files and libraries. For the windows version, I cross compiled using mingw64 as I do with AMD/Nvidia cards.

Since they are new and untested, I made them beta apps.
17 Nov 2021, 22:57:27 UTC

pschoefer
01.01.2022, 22:50
Auch an diesem Neujahrstag bleibt der Projektadministrator den Rückblick auf das alte Jahr nicht schuldig:

Das Jahr 2021 im Rückblick
Ein weiteres Jahr ist also gekommen und gegangen.

Dieses war nicht das beste Jahr. Wir haben das Jahr mit einem ernsten Festplattenproblem begonnen, dessen Behebung mehrere Wochen dauerte. Danach haben wir das Jahr mit der Suche über ℚ(√2) (Unterkörper 3) verbracht. Diese Suche sollte innerhalb einiger Monate erledigt sein. Eine einzelne Suche sieht nach einer kleinen Leistung aus, aber ich sollte darauf hinweisen, dass diese eine gigantische Suche ist, die vor einigen Jahren noch außer Reichweite schien.

Ansonsten werden seit November Intel-GPUs unterstützt. Die Anwendung funktionierte größtenteils, aber die Leistung war enttäuschend. Wir freuen uns auf die in diesem Jahr erscheinenden Intel-Arc-GPUs, die deutlich besser abschneiden sollten.

Danke an alle für eure Beiträge und ein wunderbares neues Jahr!
01.01.2022, 21:27:19 MEZ

Originaltext:

2021 Year in Review
So another year has come and gone.

This was not the best year. We started the year with a severe hard drive crash that took weeks to recover from. After that, the year was spent on the search over ℚ(√2) (subfield 3). This search should be complete within several months. A single search seems like a small accomplishment, but I should point out that this is a gigantic search that just several years ago seemed out of reach.

Other than that, in November support was added for Intel GPUs. The app worked for the most part but performance was disappointing. We look forward to the new Intel Arc GPUs coming out this year which should perform much better.

Thanks everyone for your contributions and have a wonderful New Year!
1 Jan 2022, 20:27:19 UTC