yoyo@home mit ecm

[[SG] MO]

Klasse, auch unseren herzlichen Glückwunsch


VG
MO & NEYTIRI

[pons66]

Hab gerade das hier in den News auf yoyo's Seite gefunden...

02 Jan 2014 ECM: First found factor this year.
A Happy New Year to all crunchers!
User [SG-FC] hl found a 57 digit prime as a factor of the Near Repdigit Number 8*10242+9, which is the first found number in this year.

Na dann mal Gratulation, hl

+1

[iz-germany-timo]

Hab jetzt 7 ECM, davon stehen 4 auf 80% und stehen und stehen.
Wie ich herauslese ist das durchaus üblich? Eine steht schon ne ganze Zeit bei 20%

bei i7-3770K auf 3,9 GHz mit 16 GB Ram ( müsste doch reichen oder?)

[pschoefer]

Hab jetzt 7 ECM, davon stehen 4 auf 80% und stehen und stehen.
Wie ich herauslese ist das durchaus üblich? Eine steht schon ne ganze Zeit bei 20%

Ja, die Fortschrittsanzeige läuft immer in 20%-Schritten.

bei i7-3770K auf 3,9 GHz mit 16 GB Ram ( müsste doch reichen oder?)

Sollte reichen, selbst wenn alle WUs gleichzeitig in die speicherintensive Phase kommen (jeweils kurz vor dem nächsten Sprung der Fortschrittsanzeige).

[pschoefer]

Ein Primfaktor der Zahl (10^593+1)/11 ist einer der größten bisher mit ECM gefundenen Faktoren:

P73-Rekordzahl mit gmp-ecm gefunden
Der Teilnehmer astroboylok hat eine 73-stellige Primzahl für das ECM-Repunit-Projekt gefunden. Diese Zahl erreicht die Liste der größten mit gmp-ecm gefundenen Primzahlen.
07.11.2017

Originaltext:

P73 record number found with gmp-ecm
For the ECM repunit project user astroboylok found a 73 digit prime. This number will make it into the largest primes list ever found with gmp-ecm.
07 Nov 2017

[No_Name]

Profitiert ECM eigentlich von SMT?

Laut meinen kurzen Test ist es eher nachteilig, kann das jemand bestätigen?

[Major]

Kann es sein, dass wir grad ein klein wenig mit der Speichernutzung übertreiben?



Ich habe 16 GB RAM verbaut, aber an ein Arbeiten an den Rechnern ist kaum zu denken. Sehr nostalgisch die ganze Ruckelei.
Bis zuletzt lief es noch normal.
Auf beiden Rechnern laufen die ecm_op-WUs. Ich hätte ja nicht gedacht dass "op" wirklich sooo OP ist ^^

[yoyo[RKN]]

Hast Du den neusten BOINC drauf?
Die WUs werden eigentlich nur gedownloaded bzw. gestartet, wenn der Rechner auch die entsprechende Menge RAM frei hat.

[Major]

Hast Du den neusten BOINC drauf?

NEIN. Ich habe den 7.6.22 und gedenke momentan auch nicht zu wechseln.

Der RAM ist vorhanden (16 GB sollten ja wohl bei 8 zur Verfügung stehenden Kernen ausreichend sein), aber wenn die Anforderungen inzwischen so extrem sind wird es vermutlich Zeit sich anderen (weniger ressourcenhungrigen) Projekten zuzuwenden. Zeitweise haben sich die WUs soweit gegenseitig ausgebremst dass nur noch 3 Stück zeitgleich laufen konnten.
Alter Schwede, die Meldung "warte auf Speicher" habe ich schon seit Jahren nicht mehr im BOINC-Manager lesen müssen

[Felix_M_]

bei lhcb sieht man das regelmäßig....

ich werd auch mal wieder zu yoyo schauen und dieses subprojekt etwas rechnen

[Major]

Der Unterschied ist: bei LHCb weiß ich das von vornherein und (nicht zu vergessen) es läuft in vbox.
Da gehe ich schon etwas vorsichtiger heran und lasse nur eine vbox mit einer WU laufen.

Bis vor wenigen Tagen kannte ich auch bei den ecm_op keine Probleme und ich rechne schon eine Weile only ECM.
Keine Ahnung ob da irgendetwas an den WU-Parametern seitens des Projektes geschraubt wurde oder ob die Dinger so selten waren dass es nicht auffallen konnte.

Yoyo schrieb ja auch so schön:

Hast Du den neusten BOINC drauf?
Die WUs werden eigentlich nur gedownloaded bzw. gestartet, wenn der Rechner auch die entsprechende Menge RAM frei hat.

Mit "eigentlich" macht man eigentlich jeden Satz kaputt!

Wenn ich (ab und an) den Rechner neu starte und es starten 8 WUs gleichzeitig ... und jede schaut quasi zur selben Zeit ob genug RAM vorhanden ist ... soll ich weitermachen ?

[AxelS]

Bei mir sind vor einigen Tagen auf meinem Hauptrechner einige wenige ECMs gecrascht. Ich musste die Anzahl der gleichzeitig laufender ECM auf 3 reduziert, um andere speicherhungrige Programme nicht zu gefährden.

[yoyo[RKN]]

Deswegen fragte ich nach der neusten BOINC version. AFAIK ist dort ein Bugfix bzgl. der RAM Bestimmung drin. Auch wenn 8 WUs gleichzeitig starten, sollte BOINC das sehr häufig überprüfen und WUs mit "warten auf Speicher" anhalten. Wenn das nicht funktioniert, dann solltet Ihr das mal der BOINC Entwicklung melden. Je mehr das machen so besser.
Wie gesagt, der WU ist der entsprechende RAM Bedarf zugewiesen und BOINC sorgt dafür dass nur solche WUs gedownloadet bzw. gestartet werden die auch in den RAM passen.
Evtl. solltest DU eben auch nicht 100% des RAM für BOINC bereitstellen.

[Major]

Meine RAM-Freigabe steht schon immer nur auf 90% !

Das Anhalten der WUs bei "warten auf Speicher" funktioniert ja. Ich wunderte mich nur darüber dass mittlerweile alles was irgendwie möglich ist auch ausgereizt wird.
Quasi ohne Rücksicht auf mögliche Einschränkungen die das auf User-Seite mit sich bringt.

Der BM scheint eben nicht dafür zu sorgen dass nur WUs gestartet werden die in den RAM passen, denn wenn bereits eine WU mit einem Spitzen-RAM-Bedarf von (lt. Task-Manager) von 7.904.068 K läuft, sollte es auch ausgeschlossen sein, dass eine oder mehrere weitere mit ähnlichem RAM-Bedarf starten.

Was war denn so schlimm an den früheren WUs mit knapp über 2GB-Höchstanforderung?
Warum wird eine solche Änderung nirgends kommuniziert?

Bei mir sind vor einigen Tagen auf meinem Hauptrechner einige wenige ECMs gecrascht. ...

Selbiges war mir auch in den letzten Tagen passiert, deshalb war ich ja auch erst auf dieses Problem aufmerksam geworden.
Blöderweise reisst der Crash einer WU meist noch alle anderen gleichzeitig Laufenden mit in den Abgrund. Rechenzeit für NIX ...

[yoyo[RKN]]

1. Es wird nicht alles ausgereizt was geht. Der enorme Speicherbedarf betrifft nur das ecm Projekt und auch dort nur wenig WUs, nur die P2 work units.
2. Es wurde announced, am 23.12. 2016 (http://www.rechenkraft.net/yoyo/old_news.php).
3. Der Grund ist in weitere Dimensionen des ECMens vorzudringen.

PC's werden auch immer schneller und haben mehr RAM. Daher können einige Rechner Workunits mit 10 GB RAM Bedarf auch rechnen.
Wie gesagt, wenn Workunits crashen, sollte das genutzt werden um BOINC zu verbessern, dass das eben nicht passiert. Laut meines Wissens waren gerade im RAM handling einige Fehler in älteren Versionen.

[Felix_M_]

scheinbar werden die ECM wus mit _P2 nun als extra subprojekt ausgegeben

[pschoefer]

scheinbar werden die ECM wus mit _P2 nun als extra subprojekt ausgegeben

Ja, inzwischen gibt es auch eine Meldung dazu:

Neues Subprojekt ECM P2
Wir haben nun ein eigenes Subprojekt für unsere Speichermonster ECM P2 (welche bis zu 10 GB freien RAM benötigen). In den Projekteinstellungen könnt ihr auswählen, ob ihr daran teilnehmen möchtet.
07.10.2019


Zudem wurde ein 67-stelliger Primfaktor der Zahl 149^99+99^149 gefunden:

P67 mit ECM gefunden
Der Teilnehmer Peter Baetz hat eine 67-stellige Primzahl mit ECM gefunden. Diese Zahl erreichte die Top 10 in den größten gefundenen Primfaktoren mit ECM im Jahr 2019.
07.10.2019


Originaltexte:

New app ecm P2
For our ecm P2 memory monster (which require up to 10 GB free RAM) we have now an own application. In the project settings you can choose to run this app or not.
07 Oct 2019

P67 found with ecm
User Peter Baetz found a 67 digit prime with ecm. This number went into the top 10 of the largest found prime factors with ecm for the year 2019.
07 Oct 2019

[Felix_M_]

leider werden dort recht wenig wus ausgegeben

[yoyo[RKN]]

Jetzt gibts glaub ich mehr davon.

[Felix_M_]

super sache

[pschoefer]

Die 67-stellige Primzahl 7 118 712 195 058 078 015 963 765 386 322 444 134  285 243 628 705 404 423 063 643 507 397 (in Worten: sieben Undezillionen einhundertachtzehn Dezilliarden siebenhundertzwölf Dezillionen ... sechshundertdreiundvierzig Millionen fünfhundertsiebentausend-dreihundertsiebenundneunzig) wurde kürzlich als zweitgrößter bekannter Primfaktor der 669-stelligen Cunningham-Zahl 2²²²²+1 identifiziert.

P67 mit ECM gefunden
Simone Bonzanini hat einen 67-stelligen Primfaktor der Cunningham-Zahl 2²²²²+1 gefunden. Das spart eine Menge NFS-Arbeit. Die gefundene Primzahl ist die erste in Paul Zimmermanns ECMNET-Rekordliste für dieses Jahr.
09.01.2023

Originaltext:

P67 found with ecm
Simone Bonzanini found a 67 digits prime factor for the Cuningham number 2²²²²+1. This saves a lot of NFS effort. The found prime is the first for this years ECMNET record list of Paul Zimmermann.
9 January 2023