• Projekte

    von Veröffentlicht: 21.10.2017 21:50
    1. Kategorien:
    2. Projekte

    In den letzten Tagen gab es Validierungsprobleme, hier ist eine ausführlichere Beschreibung, was dazu geführt hat:

    Neuigkeiten zu den Problemen dieser Woche
    Hallo zusammen,

    ich möchte euch allen schnelle und technischere Neuigkeiten dazu geben, was uns in der letzten Woche beschäftigt hat.

    Unser Projekt läuft nun seit mehr als 10 Jahren und wir über die Jahre buchstäblich Milliarden von WUs gecruncht. Als Ergebnis all eurer harten Arbeit und Hingabe haben wir tatsächlich genug Ergebnisse berechnet, dass uns der Platz ausgegangen ist, die IDs all dieser Ergebnisse als normale vorzeichenlose Ganzzahlwerte (der Standard-Datentyp, mit dem IDs in BOINC-Datenbanken gespeichert werden) zu speichern. Daher habe ich am Dienstagabend unsere Datenbank aktualisiert, um die IDs als einen viel größeren Datentyp zu speichern, um zu vermeiden, dass dieses Problem in der restlichen Projektlaufzeit nochmals auftritt. Ich musste daher auch schnell den BOINC-Code flicken, den wir auf dem Server ausführen, damit er mit diesem neu verfügbaren Datentyp in der Datenbank umgehen kann.

    Bei diesem Vorgang habe ich einen der Fremdschlüssel übersehen, der sich auf die Ergebnisse bezieht, speziell beim Validierungsprozess. Das hat zu einem Problem bei der Validierung von WUs in den letzten Tagen geführt. Ich hatte Probleme, dieses Problem festzustellen, da vor dem Leerlauf der WU-Warteschlange alles funktionierte, jedoch nach dem Leerlauf der WU-Warteschlange, als die neuen WUs mit großen IDs zurückgemeldet wurden, stillschweigend aufhörte, WUs zu validieren.

    Ich habe eine Lösung für das letzte Problem eingebaut und hoffe, dass ab jetzt an dieser Front Ruhe herrscht. Natürlich besteht immer die Möglichkeit, dass ich einen anderen Fehler in diesem Ablauf übersehen habe, oder ich könnte feststellen, dass ich die Validierung von in den letzten Tagen erhaltenen WUs erzwingen muss. Ich werde den Server auf jeden Fall in den nächsten Tagen genau beobachten, um sicherzustellen, dass alles funktioniert.

    Entschuldigt bitte all die Schwierigkeiten der letzten Tage und ich hoffe, dass ihr alle unsere wichtige Forschung weiterhin unterstützt.

    Jake
    21.10.2017, 19:11:25 MEZ

    Originaltext:
    Update on This Weeks Errors
    Hey Everyone,

    I just wanted to give you all a quick and more technical update on what we have been dealing with over the last week.

    Our project has been running for upwards of 10 years now and we have been crunching literally billions of workunits over those years. As a result of all of your hard work and dedication, we have actually calculated enough results that we have run out of room to store the IDs of all of these results in a normal unsigned integer value (the default data type used for storing IDs in BOINC databases). As a result, on Tuesday night, I updated our database to be able to store IDs in a much larger data type to prevent this issue from happening again during the remaining life of the project. As a result, I also had to quickly patch the BOINC code we run on the server to allow it to use this newly available data type in the database.

    During this process, I missed one of the foreign keys that refers to the results, specifically in the validation process. This led to an issue in validation of work units over the last couple days. I had trouble diagnosing this issue because before the workunit queue clear, everything was running fine however, after the workunit queue clear, when new work with large IDs was being returned, it silently failed to validate workunits.

    I have implemented a fix for this last issue and my hope is that things will be smooth sailing from here on with regards to this issue. Of course, there is always the possibility I missed another bug in this pipeline, or I might realize I need to force validation on workunits received over the last couple days. In any case, I will be watching the server pretty closely over the next couple days to make sure its running correctly.

    Sorry for all of the trouble over the last couple days and I hope you all continue to support the important research we are doing into the future.

    Jake
    21 Oct 2017, 18:11:25 UTC
    von Veröffentlicht: 19.10.2017 08:50
    1. Kategorien:
    2. Projekte

    In dieser Woche wurde die Benennung der WUs etwas verändert, außerdem wird das in der Vorwoche beschriebene Determinismus-Problem nun von den SoFiA-Entwicklern untersucht. Nächste Woche könnte der Produktivbetrieb beginnen.

    Neuigkeiten zum SoFiA-Betatest, Teil 6
    Entschuldigt, ich habe meine gestrige Änderungsmeldung vergessen!

    Es gab ein Problem mit Überschneidungen der WU-Namen zwischen Duchamp und SoFiA. Die ursprüngliche Namenskonvention war "Durchlauf-ID_Würfelname", aber es gab keine Unterscheidung zwischen SoFiA- und Duchamp-WUs.
    Die neue Namenskonvention ist einfach "Anwendungsname_Durchlauf-ID_Würfelname", um die Möglichkeit künftiger Überschneidungen auszuschließen.

    Ich habe auch die SoFiA-Entwickler wegen des in der letzten Woche beschriebenen Determinismus-Problems kontaktiert und sie arbeiten daran.

    Ich möchte so schnell wie möglich mit der echten Arbeit beginnen, daher peile ich an, in der nächsten Woche auf produktive Arbeit umzustellen, wenn in dieser Woche alles glatt läuft.
    19.10.2017, 1:26:12 MEZ

    Originaltext:
    Zitat Zitat von https://sourcefinder.theskynet.org/duchamp/
    SoFiA Beta Update 6
    Apologies, I forgot to post my changelog for yesterday!

    There was an issue with workunit name clashes between duchamp and sofia. The original naming convention was "runid_cubename", but there was no differentiation between SoFiA and Duchamp workunits.
    The new naming convention is simply "appname_runid_cubename" to avoid the possibility of future clashes.

    I've also contacted the SoFiA devs about the determinism issue I outlined last week and they're looking in to it.

    I want to get started on real work as soon as possible, so if this week's work goes smoothly, I'll see about moving on to production work next week.
    19 Oct 2017, 0:26:12 UTC
    von Veröffentlicht: 19.10.2017 08:30
    1. Kategorien:
    2. Projekte

    Zur Behebung von Serverproblemen müssen alle WUs aus dem System genommen werden:

    Warteschlange wird geleert
    Hallo zusammen,

    wir müssen die WU-Warteschlange sowohl für Separation als auch für Nbody leeren. Das wird viele ungültige WUs verursachen. Wir bitten um Entschuldigung dafür, leider ist dies der einzige Weg, das System aufzuräumen und zum normalen Ablauf zurückzukehren.

    Danke für eure anhaltende Unterstützung,
    Jake und Sidd
    18.10.2017, 20:21:21 MEZ


    Vorausgegangen waren Probleme mit dem Transitioner-Dienst:

    Transitioner ausgefallen
    Hallo zusammen,

    es sieht so aus, als ob wir einige Probleme mit dem Transitioner haben. Ich arbeite daran, ihn zu reparieren.

    Jake

    [edit]

    Es sieht so aus, als ob jetzt alles funktioniert. Hoffentlich ist dies kein Problem für die nächsten 100 Jahre nach all den Änderungen, die ich vorgenommen habe. Ich werde für den Rest des Tages ein Auge darauf haben.

    Außerdem habe ich nun ein E-Mail-Benachrichtigungssystem für die Serverdienste eingerichtet. Wenn sie in Zukunft ausfallen, sollten wir das schneller bemerken.

    Danke, dass ihr bei uns bleibt, und entschuldigt bitte die längere Auszeit.

    Jake
    [/edit]
    17.10.2017, 19:42:56 MEZ


    Originaltexte:
    Zitat Zitat von http://milkyway.cs.rpi.edu/milkyway/
    Clearing the Queue
    Hey All,

    We will have to clear the workunit queue for both separation and nbody. This will cause many invalid workunits. We apologize for this, as this is the only way to clear the system for it to return to normal operation.

    Thanks for your continued support,
    Jake and Sidd
    18 Oct 2017, 19:21:21 UTC
    Zitat Zitat von http://milkyway.cs.rpi.edu/milkyway/
    Transitioner Down
    Hey Everyone,

    Looks like we are having some trouble with the transitioner. I'm working on getting it back up and running.

    Jake

    [edit]

    Everything looks like it's working now. Hopefully this shouldn't be an issue for another 100+ years given the changes I've made. I'll keep an eye on things for the rest of the day.

    In other news, I've implemented an email notification system for the server daemons. If they go down in the future, we should know about it faster.

    Thanks for sticking with us and sorry for the extended downtime.

    Jake
    [/edit]
    17 Oct 2017, 18:42:56 UTC
    von Veröffentlicht: 18.10.2017 20:05
    1. Kategorien:
    2. Projekte

    Die zweite Proth-Megaprimzahl des Monats wurde gefunden:

    Weitere PPS-Megaprimzahl!
    Am 17. Oktober 2017 um 14:48:48 UTC hat PrimeGrids Subprojekt PPS Mega Prime Search eine Megaprimzahl gefunden:
    1147*2^3435970+1

    Die Primzahl hat 1034334 Dezimalstellen und erreicht Chris Caldwells Datenbank der größten bekannten Primzahlen auf Platz 208 insgesamt.

    Die Entdeckung gelang Randall Scalise (Randall J. Scalise) aus den Vereinigten Staaten mit einem Intel Core i5-4590 @ 3,30 GHz mit 8 GB RAM unter Linux. Dieser Rechner brauchte etwa 1 Stunde 6 Minuten für den Primalitätstest mit LLR.

    Die Primzahl wurde am 17. Oktober 2017 um 15:57:02 MEZ von Amy Chambers (Buckeye74) aus den Vereinigten Staaten mit einem Intel Core i7-4770K @ 3,50 GHz mit 16 GB RAM unter Windows 10 bestätigt. Dieser Rechner brauchte etwa 1 Stunde 13 Minuten für den Primalitätstest mit LLR. Amy ist Mitglied des Teams Sigma Omicron Chapter of Tau Kappa Epsilon.

    Für weitere Einzelheiten siehe bitte die offizielle Bekanntgabe.
    18.10.2017 | 19:30:25 MEZ

    Originaltext:
    Zitat Zitat von https://www.primegrid.com/
    Another PPS-Mega Prime!
    On 17 October 2017, 13:48:48 UTC, PrimeGrid’s PPS Mega Prime Search project found the Mega Prime:
    1147*2^3435970+1

    The prime is 1,034,334 digits long and will enter Chris Caldwell's The Largest Known Primes Database ranked 208th overall.

    The discovery was made by Randall Scalise (Randall J. Scalise) of the United States using an Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz with 8GB RAM, running Linux. This computer took about 1 hour 6 minutes to complete the primality test using LLR.

    The prime was verified on 17 October 2017, 14:57:02 UTC by Amy Chambers (Buckeye74) of the United States using an Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz with 16GB RAM, running Microsoft Windows 10 Core Edition. This computer took about 1 hour 13 minutes to complete the primality test using LLR. Amy is a member of the Sigma Omicron Chapter of Tau Kappa Epsilon team.

    For more details, please see the official announcement.
    18 Oct 2017 | 18:30:25 UTC
    von Veröffentlicht: 18.10.2017 16:30
    1. Kategorien:
    2. Projekte

    In Kürze gibt es neue WUs, die sich statt mit der Weinrebe mit dem Darmbakterium Escherichia coli befassen.

    Weiteres Experiment zu E. coli
    Wir werden ein weiteres Experiment zu Escherichia coli beginnen, wobei wir den gleichen Expressionsdatensatz wie im vorherigen Experiment verwenden, aber einen der Parameter des Algorithmus verändern.
    Die Laufzeiten sollten etwas kürzer sein als bei den letzten WUs zu Vitis vinifera.
    18.10.2017, 10:53:02 MEZ

    Originaltext:
    Zitat Zitat von http://gene.disi.unitn.it/test/
    Another experiment on E. coli
    We are ready to start another experiment on Escherichia coli, using the same expression dataset of the previous one but changing one of the algorithm's parameters.
    Execution times should slightly faster than the last one on Vitis vinifera.
    18 Oct 2017, 9:53:02 UTC
    von Veröffentlicht: 18.10.2017 16:10
    1. Kategorien:
    2. Projekte

    Derzeit führt eine bestimmte Version der Anti-Malware-Software Malwarebytes zu vielen Berechnungsfehlern. Mit der neuesten Malwarebytes-Version sollte das Problem nicht mehr auftreten.

    Probleme mit Malwarebytes und POGS
    Hallo zusammen,

    in den letzten Wochen habe ich einige Forenthreads zu Problemen mit einer neuen Version von Malwarebytes gesehen, welche schlecht mit POGS zusammenspielt.

    Wenn ihr gerade dieses Problem habt, schaut bitte in diesem Thread nach Ratschlägen: https://pogs.theskynet.org/pogs/foru...stid=5310#5310 (engl.).

    Die derzeitig beste Lösung ist eine weitere Aktualisierung von Malwarebytes, um die Version loszuwerden, welche Probleme mit POGS verursachte.

    Frohes Crunchen!
    18.10.2017, 00:53:51 MEZ

    Originaltext:
    Zitat Zitat von http://pogs.theskynet.org/pogs/
    Issues with Malwarebytes and POGS
    Hi everyone,

    Over the last few weeks I've seen several forum threads concerning issues with a new update of Malwarebytes interfering negatively with POGS.

    If anyone is currently having issues, please see this thread for advice: https://pogs.theskynet.org/pogs/foru...stid=5310#5310.

    The current going solution is to update Malwarebytes again to get past the version that was causing POGS issues.

    Happy Crunching!
    17 Oct 2017, 23:53:51 UTC
    von Veröffentlicht: 15.10.2017 01:00
    1. Kategorien:
    2. Projekte

    Anlässlich des hinduistischen Lichterfestes Diwali steht der sechste Abschnitt der PrimeGrid Challenge Series 2017 vor der Tür. Dies ist die letzte LLR- und reine CPU-Challenge in diesem Jahr, bevor dann bei den beiden verbleibenden Stationen auch Grafikkarten eingreifen können.

    Diwali/Deepavali Challenge
    Beginn: 18.10.2017, 00:00 UTC = 01:00 MEZ = 02:00 MESZ
    Ende: 23.10.2017, 00:00 UTC = 01:00 MEZ = 02:00 MESZ
    Subprojekt: The Riesel Problem LLR (TRP)


    Der offizielle Thread zur Challenge im PrimeGrid-Forum ist hier zu finden.

    Es zählen für diese Challenge nur WUs des Subprojekts The Riesel Problem LLR (TRP), die nach dem 18.10. um 02:00 Uhr heruntergeladen und vor dem 23.10. um 02:00 Uhr zurückgemeldet werden! Das gewünschte Subprojekt kann in den PrimeGrid-Einstellungen festgelegt werden.

    Anwendungen gibt es für Windows, Linux und MacOS (Intel), jeweils 32- und 64-Bit. Wer in letzter Zeit keine WUs von einem PrimeGrid-LLR-Subprojekt berechnet hat, sollte dies vielleicht schon vor der Challenge nachholen, um die relativ große Anwendung (~35 MB) bereits auf dem Rechner zu haben.

    Die verwendete LLR-Anwendung belastet die CPU sehr stark und toleriert keinerlei Fehler. Daher bitte nicht zu stark übertakten und auf gute Kühlung achten!

    Zu erwarten sind WU-Laufzeiten von bis zu 15 Stunden auf den schnellsten CPU-Kernen, über einem Tag auf langsameren und älteren CPUs. Moderne Intel-CPUs haben durch die automatisch benutzten Optimierungen (AVX, FMA3) einen erheblichen Vorteil. CPUs, die Hyperthreading unterstützen, laufen in der Regel effizienter, wenn Hyperthreading nicht benutzt wird. Während standardmäßig jeder CPU-Kern eine WU bearbeitet, ist es oft von Vorteil, eine WU von mehreren CPU-Kernen bearbeiten zu lassen, was natürlich auch die WU-Laufzeit entsprechend verringert. Das lässt sich mit einer app_config.xml erreichen (im Beispiel für 4 Kerne):
    Code:
    <app_config>
      <app_version>
        <app_name>llrTRP</app_name>
        <cmdline>-t 4</cmdline>
        <avg_ncpus>4</avg_ncpus>
      </app_version>
    </app_config>
    Dieser Text muss als app_config.xml im Unterverzeichnis projects\www.primegrid.com des BOINC-Datenverzeichnisses (unter Windows standardmäßig C:\ProgramData\BOINC) gespeichert werden. Die Einstellung wird durch Konfigurationsdatei einlesen oder Neustart für neue WUs übernommen.

    Die Punkte für die Challenge-Statistik sind identisch mit den BOINC-Credits, werden jedoch sofort gutgeschrieben, während die BOINC-Credits erst vergeben werden, wenn das Quorum von 2 übereinstimmenden Ergebnissen erreicht ist. Sollte sich ein Ergebnis als falsch erweisen, werden die Punkte natürlich wieder abgezogen.

    Team-Stats bei PrimeGrid
    User-Stats bei PrimeGrid

    Zum Diskussionsthread
    von Veröffentlicht: 14.10.2017 22:25
    1. Kategorien:
    2. Projekte

    Die Informationen zu den Test-WUs dieser Woche seien hiermit nachgereicht. Es gibt unter anderem noch ein Problem mit SoFiA, dass die Berechnung eines Parameters manchmal funktioniert, manchmal aber fehlschlägt.

    Neuigkeiten zum SoFiA-Betatest, Teil 5
    Ich habe die Aufzeichnung der Assimilator-Meldungen beschränkt, damit ich darin auch tatsächlich etwas finden kann.

    Ein extrem unwahrscheinlicher Fehler im Assimilator wurde behoben, der zuschlug, wenn die S3-Server von Amazon nicht erreichbar sind.
    Ein Fehler, dass der Assimilator nicht existierende temporäre Verzeichnisse zu löschen versuchte, wurde behoben.

    Außerdem scheint einer der SoFiA-Ergebnisparameter, Wm50, nichtdeterministisch zu sein. Einige Durchläufe berechnen ihn ohne Fehler, aber andere schlagen fehl. Hier sind Beispiele der Fehlermeldungen von zwei verschiedenen Durchläufen mit demselben Parametersatz:

    Durchlauf 1 (vom Benutzer emoga):
    Code:
    Warning (Parametrization): Cannot determine kinematic major axis. Source too faint.
    Warning (Parametrization): Measurement of kinematic PA failed.
    Warning (Parametrization): Kinematic major axis derived from just 2 data points.
    Error (Parametrization): Calculation of Wm50 failed (3).
    Warning (Parametrization): Failed to measure source line width.
    Error (Parametrization): Cannot fit ellipse, source flux <= 0.
    Warning (Parametrization): Ellipse fit failed.
    Warning (Parametrization): Cannot determine kinematic major axis. Source too faint.
    Warning (Parametrization): Measurement of kinematic PA failed.
    Durchlauf 2 (vom Benutzer LCB001)
    Code:
    Warning (Parametrization): Cannot determine kinematic major axis. Source too faint.
    Warning (Parametrization): Measurement of kinematic PA failed.
    Warning (Parametrization): Kinematic major axis derived from just 2 data points.
    Error (Parametrization): Cannot fit ellipse, source flux <= 0.
    Warning (Parametrization): Ellipse fit failed.
    Warning (Parametrization): Cannot determine kinematic major axis. Source too faint.
    Warning (Parametrization): Measurement of kinematic PA failed.
    Beachtet, dass im ersten Fall der Parameter Wm50 nicht berechnet werden kann, aber im zweiten Fall kein Problem bei der Berechnung auftritt.
    Ich werde das mit dem SoFiA-Team besprechen, weil das möglicherweise ein Problem ist, das sie beheben können.

    Ich habe außerdem einen Satz von Parameterdateien erhalten, welche die Wissenschaftler von uns bearbeitet sehen wollen, daher werden wir in dieser Woche einen Test dieser Parameter durchführen, um sicherzustellen, dass alles funktioniert.
    Es sind insgesamt 486 Parameter pro Würfelchen zu berechnen (das sind zweimal so viele wie bei Duchamp!), daher werden die WUs etwas länger laufen als üblich. Ich habe die Parameter lokal getestet und die Berechnung einer WU dauerte etwa 30 Minuten.
    11.10.2017, 3:54:41 MEZ

    Originaltext:
    Zitat Zitat von https://sourcefinder.theskynet.org/duchamp/
    SoFiA Beta Update 5
    Reduced logging in the assimilator logs so I can actually find things in them.

    Fixed an extremely unlikely bug in the assimilator that fires if amazon's S3 servers can't be reached.
    Fixed a bug with the assimilator attempting to remove temporary folders that don't exist.

    It also appears as though one of the SoFiA result parameters, Wm50, is non-deterministic. Some runs calculate it without error, but others fail. Here's an example error log from two different runs of the same parameter set:

    Result 1 (courtesy of emoga):
    [...]

    Result 2 (courtesy of LCB001)
    [...]

    Note how in the first case, the Wm50 parameter fails to calculate, but in the second there's no issue calculating it.
    This is something I'll bring up with the SoFiA team, as it might be an issue somewhere that they can address.

    I've also received a set of parameter files that the scientists would like us to run, so for this week we'll be running a test on those parameters to make sure everything works fine.
    There are a total of 486 parameters to run per cubelet (that's 2x more than duchamp!) so work units should take a bit longer to complete than normal. I tested the parameters locally and they took around 30 mins to process one work unit.
    11 Oct 2017, 2:54:41 UTC
    von Veröffentlicht: 09.10.2017 21:45
    1. Kategorien:
    2. Projekte

    Das neue Subprojekt Siever unterstützt das Projekt Conjectures 'R Us beim Aussieben von zusammengesetzten Zahlen aus den zwecks Beweis von verallgemeinerten Riesel- und Sierpinski-Vermutungen zu überprüfenden Primzahlkandidaten. Somit wird Vorarbeit unter anderem auch für das Projekt SRBase geleistet.

    Siever: Neues Subprojekt
    Mit unserem neuen Subprojekt sieben wir Kandidatenlisten für das Projekt CRUS. Wir sieben für verallgemeinerte Riesel/Sierpinski-Vermutungen zur Basis b mit b<1030 (Format: k*b^n-/+1). Die Kandidatenlisten werden zum Beginnen von Primalitätstests benötigt.
    Die ersten Testaufgaben laufen bereits.
    09.10.2017

    Originaltext:
    Zitat Zitat von https://www.rechenkraft.net/yoyo/
    Siever: New subproject
    In our new subproject we produce Sieve Files for the CRUS-project. We are sieving for Riesel/Sierpinski to b conjectures where b<1030. (Form: k*b^n-/+1). Sieve files are needed to start testing for primes.
    First test tasks are already running.
    9 Oct 2017
    von Veröffentlicht: 09.10.2017 21:00
    1. Kategorien:
    2. Projekte

    Sechs Wochen nach seinem letzten Fund war SETI.Germany-Mitglied dh1saj ein weiteres Mal erfolgreich:

    Weitere PPS-Megaprimzahl!
    Am 5. Oktober 2017 um 09:47:45 MEZ hat PrimeGrids Subprojekt PPS Mega Prime Search eine Megaprimzahl gefunden:
    911*2^3432643+1

    Die Primzahl hat 1033331 Dezimalstellen und erreicht Chris Caldwells Datenbank der größten bekannten Primzahlen auf Platz 208 insgesamt.

    Die Entdeckung gelang Jochen Beck (dh1saj) aus Deutschland mit einem Intel Core i5-4670 @ 3,40 GHz mit 8 GB RAM unter Windows 7. Dieser Rechner brauchte etwa 1 Stunde 25 Minuten für den Primalitätstest mit LLR. Jochen ist Mitglied des Teams SETI.Germany.

    Die Primzahl wurde am 6. Oktober 2017 um 23:29:00 MEZ von Georgios Magklaras (georgios) aus Griechenland mit einem Intel Xeon E5-2650 v3 @ 2,30 GHz mit 128 GB RAM unter Linux bestätigt. Dieser Rechner brauchte etwa 2 Stunden 28 Minuten für den Primalitätstest mit LLR. Georgios ist Mitglied von Team Norway.

    Für weitere Einzelheiten siehe bitte die offizielle Bekanntgabe.
    09.10.2017 | 14:15:21 MEZ

    Originaltext:
    Zitat Zitat von https://www.primegrid.com/
    Another PPS-Mega Prime!
    On 5 October 2017, 08:47:45 UTC, PrimeGrid’s PPS Mega Prime Search project found the Mega Prime:
    911*2^3432643+1

    The prime is 1,033,331 digits long and will enter Chris Caldwell's The Largest Known Primes Database ranked 208th overall.

    The discovery was made by Jochen Beck (dh1saj) of Germany using an Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz with 8GB RAM, running Windows 7 Professional Edition. This computer took about 1 hour 25 minutes to complete the primality test using LLR. Jochen is a member of the SETI.Germany team.

    The prime was verified on 6 October 2017, 22:29:00 UTC by Georgios Magklaras (georgios) of Greece using an Intel(R) Xeon(R) E5-2650 v3 CPU @ 2.30GHz with 128GB RAM, running Linux. This computer took about 2 hours 28 minutes to complete the primality test using LLR. Georgios is a member of the Team Norway team.

    For more details, please see the official announcement.
    9 Oct 2017 | 13:15:21 UTC
    Seite 1 von 36 1 2 3 11 ... Letzte
Single Sign On provided by vBSSO