• SETI.Germany News RSS-Feed

    von Veröffentlicht: 05.07.2017 17:25
    1. Kategorien:
    2. Projekte

    Wie in letzter Zeit üblich, gab es auch zum gerade vergangenen Monatswechsel einen GFN-Megaprimzahlfund, dieses Mal sogar eine Nummer größer bei GFN-18:

    GFN-262144-Megaprimzahl!
    Am 30. Juni 2017 um 03:54:43 MEZ hat PrimeGrids Generalized Fermat Prime Search eine verallgemeinerte Fermat-Megaprimzahl gefunden:

    3060772^262144+1

    Die Primzahl hat 1700222 Dezimalstellen und erreicht Chris Caldwells Datenbank der größten bekannten Primzahlen auf Platz 5 für verallgemeinerte Fermat-Primzahlen und Platz 50 insgesamt.

    Die Entdeckung gelang Sean Humphries (No.15) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Xeon E5-2670 @ 2,60 GHz mit 32 GB RAM unter Linux. Diese GPU brauchte etwa 16 Minuten für den PRP-Test mit GeneferOCL3. Sean ist Mitglied des Teams Overclock.net.

    Die Primzahl wurde am 1. Juli 2017 um 19:49:46 MEZ von John Hall (JH30895) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 680 in Verbund mit einem Dual-Intel Xeon X5680 @ 3,33 GHz mit 24 GB RAM unter Mac OS Sierra bestätigt. Diese GPU brauchte etwa 52 Minuten für den PRP-Test mit GeneferOCL5. John ist Mitglied des Teams Ars Technica.

    Die Primalität dieser PRP wurde mit einem Intel Core i7-7700K @ 4,20 GHz mit 16 GB RAM unter Windows 10 bewiesen. Dieser Rechner brauchte etwa 4 Stunden 18 Minuten für den Primalitätstest mit LLR.

    Für weitere Einzelheiten siehe bitte die offizielle Bekanntgabe.
    05.07.2017 | 14:24:53 MEZ


    Darüber hinaus sind die im Rahmen von SGS-LLR gefundene Primzahlen inzwischen nur noch für wenige Tage hinreichend groß für einen Eintrag in die Top-5000-Liste, weshalb dem Erstfinder nicht mehr die üblichen 19 Tage gewährt werden, um auf die E-Mail-Benachrichtigung zu reagieren. Das Projekt empfiehlt daher, den Namen in den Projekteinstellungen zu hinterlegen, und die automatische Meldung zu erlauben.

    Dringend: Aktiviert die Primzahlmeldung, bevor es zu spät ist
    Wir sagen es immer wieder, aber jetzt könnt ihr etwas verlieren, wenn ihr die Primzahlmeldung nicht aktiviert habt.

    SGS-Primzahlen sind derzeit nur für ein paar Tage auf der Top-5000-Liste, bevor sie herausfallen. Wenn ihr die Primzahlmeldung nicht aktiviert habt, bleibt möglicherweise nicht genug Zeit, euch zu kontaktieren, bevor es zu spät zum Melden eurer Primzahl ist. Statt die Primzahl gar nicht zu melden, werden wir SGS-Primzahlen unter dem Namen des Doublecheckers melden, wenn ihr die Primzahlmeldung nicht aktiviert habt. Wenn auch der Doublechecker die Primzahlmeldung nicht aktiviert hat, werden wir die Primzahl anonym melden. Die Alternative ist, dass die Primzahl gar nicht gemeldet wird.

    Für weitere Einzelheiten und zur Diskussion siehe bitte den Thread 4888 in unserem Forum zu Sophie Germain Prime Search.

    Um die Primzahlmeldung zu aktivieren, geht bitte im Menü links [auf der PrimeGrid-Webseite] auf "Ihr Konto" und wählt dann "PrimeGrid Einstellungen" aus. Scrollt etwas herunter zu der Stelle "Primäreinstellungen (Standard):" und wählt "PrimeGrid Einstellungen bearbeiten".

    Scrollt herunter zu "Reporting primes to the Prime Pages" und hakt beide Kästchen an, um das Melden von Primzahlen zu erlauben und eine E-Mail zu bekommen, wenn eine Primzahl gefunden wurde. Ihr müsst euren Realnamen angeben. Die Top 5000 akzeptieren keine erfundenen oder Benutzernamen. Bitte gebt euren Namen im Format "Vorname Nachname" ein. (Nehmt zur Kenntnis, dass wir auch in Kulturkreisen, wo üblicherweise der Nachname zuerst genannt wird, erst den Vornamen und dann den Nachnamen benötigen.)

    Wenn ihr aus irgendeinem Grund nicht möchtet, dass wir euren Namen verwenden, können wir anonym für euch melden -- hakt einfach das Kästchen für die Erlaubnis an und tragt in das Namensfeld etwas wie "report anonymously" ein.

    Scrollt schließlich bis zum Ende der Seite und klickt auf "Einstellungen aktualisieren".
    02.07.2017 | 19:55:10 MEZ


    Originaltexte:
    Zitat Zitat von https://www.primegrid.com/
    GFN-262144 Mega Prime!
    On 30 June 2017, 02:54:43 UTC, PrimeGrid’s Generalized Fermat Prime Search found the Generalized Fermat mega prime:

    3060772^262144+1

    The prime is 1,700,222 digits long and enters Chris Caldwell's The Largest Known Primes Database ranked 5th for Generalized Fermat primes and 50th overall.

    The discovery was made by Sean Humphries (No.15) of the United States using an NVIDIA GeForce GTX 1080 in an Intel(R) Xeon(R) E5-2670 CPU at 2.60GHz with 32GB RAM, running Linux. This GPU took about 16 minutes to probable prime (PRP) test with GeneferOCL3. Sean is a member of the Overclock.net team.

    The prime was verified on 1 July 2017, 18:49:46 UTC by John Hall (JH30895) of the United States using an NVIDIA GeForce GTX 680 in a dual Intel(R) Xeon(R) X5680 CPU @ 3.33 GHz with 24GB RAM, running macOS Sierra. This GPU took about 52 minutes to probable prime (PRP) test with GeneferOCL5. John is a member of the Ars Technica team.

    The PRP was confirmed prime by an Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz with 16GB RAM, running Microsoft Windows 10 Professional. This computer took about 4 hours 18 minutes to complete the primality test using LLR.

    For more details, please see the official announcement.
    5 Jul 2017 | 13:24:53 UTC
    Zitat Zitat von https://www.primegrid.com/
    Urgent: Enable Prime Reporting Before It's Too Late
    We say it all the time, but now you can lose out if you don't have prime reporting enabled.

    SGS primes are currently only on the T5K list for a few days before falling off the list. If you do not have prime reporting enabled, there may be no time to contact you before it's too late to report your prime. Rather than let the prime go unreported, we will report SGS primes under the DCer's name if you don't have prime reporting enabled. If the DCer also doesn't have prime reporting enabled, we will report the prime anonymously. The alternative is that the prime doesn't get reported at all.

    For more details and discussion please see the 4888 thread in our Sophie Germain Prime Search topic.

    To enable prime reporting, please go to "Your account" on the menu on the left, then select "PrimeGrid Preferences". Scroll down a bit to where it says "Primary (default) preferences:" and select "Edit PrimeGrid Preferences".

    Scroll down to "Reporting primes to the Prime Pages" and click the two checkboxes for granting permission to report primes and to send you an email when a prime is found. You must enter your real name. T5K will not accept fake names or user names. Please enter your name as "given-name surname". (Note that even in cultures where the surname is normally put first, we need the given name first and the surname last.)

    If for any reason you don't want us to use your name, we can report anonymously for you -- just check the permission box and enter something like "report anonymously" in the name box.

    Finally, scroll down to the bottom and click on the "Update preferences" button.
    2 Jul 2017 | 18:55:10 UTC
    von Veröffentlicht: 03.07.2017 17:45
    1. Kategorien:
    2. SETI.Germany

    Nach einigen Tagen hochtouriger Hintergrundarbeit im Rahmen der Übergabe der SETI.Germany-Webseitenadministration von DirkS und Hoc an aendgraend und Zero2Cool war es so weit: Heute vor genau 10 Jahren öffnete das neue SG-Forum für die Allgemeinheit die Pforten und wurde schnell mit neuen Inhalten gefüllt. Trotz des Verlustes der Inhalte des alten Forums und auch der SG-eigenen Statistikseiten sollte dieses Ereignis letzten Endes den Grundstein für die Entwicklung der Community in den folgenden Jahren legen.

    Einige Zahlen:
    3.653 Tage
    7.589 Threads (~2,08 Threads pro Tag)
    292.213 Beiträge insgesamt (~79,99 Beiträge pro Tag)

    1.987 Benutzer schrieben mindestens einen Beitrag, der durchschnittliche Benutzer schrieb also 147,1 Beiträge (0,04 pro Tag), wobei diese Statistik natürlich reichlich verzerrt ist, nicht nur wegen der Vielschreiber, sondern auch, weil natürlich nicht jeder Benutzer die vollen 10 Jahre Zeit hatte. Immerhin 277 Benutzer haben jedoch überdurchschnittlich viel geschrieben, die Aktivität stammt also auch nicht nur von einigen wenigen.

    Und nun lasst uns das Forum auch die nächsten zehn Jahre mit Inhalten füllen, dazu allzeit Happy Vollgascrunching!
    von Veröffentlicht: 01.07.2017 00:00
    1. Kategorien:
    2. SETI.Germany

    Liebe Mitcruncher,

    zum Beginn der zweiten Jahreshälfte erschlägt die Teamwork-Projektempfehlung nach zuletzt der Erforschung von Asteroiden nun ein weiteres Themengebiet, nämlich die Mathematik. Im internen Subforum für alle SETI.Germany-Mitglieder wurde für die nächsten drei Monate ein noch recht junges Projekt ausgewählt: Stop@home.

    Projekt-URL: http://stop.inferia.ru/
    SETI.Germany beitreten: http://stop.inferia.ru/team_join_form.php?id=12
    Artikel im SG-Wiki: https://www.seti-germany.de/wiki/Stop@home

    Team-Vergleichstats von XSmeagolX: https://timo-schneider.de/sgstats/quartal201703/

    Wer keinen eigenen Account erstellen möchte, kann den SG-Booster-Account benutzen.

    Anwendungen gibt es für Windows, Linux und MacOS (jeweils 64 Bit).

    Dieses Projekt soll eine zwanglose Empfehlung für alle sein, die noch etwas für arbeitslose Rechner suchen, oder auch als Backupprojekt während anderer Aktionen dienen.

    Wir laden alle SETI.Germany-Mitglieder ein, für die eine oder andere WU vorbeizuschauen. Happy Vollgascrunching!
    von Veröffentlicht: 30.06.2017 22:55
    1. Kategorien:
    2. Projekte

    Ein veränderter Datensatz führt zu größeren WUs:

    Vitis vinifera: neuer Datensatz
    Wir beginnen mit der Verteilung eines weiteren Experiments (Einzelgen-Expansion) mit einem neuen Weinreben-Datensatz (Vitis vinifera). Dieser Datensatz enthält die gleiche Anzahl Gene, aber mehr Expressionsdaten; daher sind deutlich längere Laufzeiten zu erwarten (etwa doppelt so lang).
    29.06.2017, 10:08:20 MEZ

    Originaltext:
    Zitat Zitat von http://gene.disi.unitn.it/test/
    Vitis vinifera: new dataset
    We are starting to distribute another experiment (single gene expansion) with a new Vitis vinifera dataset. This dataset contains the same number of genes but a much larger expression data; running times are therefore expected to be much longer (around twice).
    29 Jun 2017, 9:08:20 UTC
    von Veröffentlicht: 30.06.2017 22:55
    1. Kategorien:
    2. Projekte

    Derzeit könnte es Probleme mit den WUs des nur für CPU verfügbaren N-Body-Subprojektes geben, alle alten WUs wurden serverseitig abgebrochen:

    Serverwartung
    Hallo zusammen,

    aus irgendeinem Grund bekomme ich keine Ergebnisse von der Nbody-Anwendung. Der Validator stürzte am Wochenende ab und verursachte einen großen Rückstand in der Warteschlange. Ich denke, dass das das Problem ist, da wir schon einmal etwas ähnliches hatten. Ich werde alle WUs in der Warteschlange abbrechen und sie neu auffüllen. Wenn ihr in den nächsten 24 Stunden etwas merkwürdiges bei Nbody-WUs beobachtet, ist das der Grund dafür.

    Sidd
    30.06.2017, 17:23:04 MEZ

    Originaltext:
    Zitat Zitat von http://milkyway.cs.rpi.edu/milkyway/
    Server Maintenance
    Hey All,

    For some reason I am not getting any return results from the Nbody app. The validator went down over the weekend and caused a huge backlog in the queue. I think this may be the issue as we have had something similar before. I am going to cancel the workunits in the queue and let it refill. If you see anything strange in the next 24 hrs with nbody workunits this is the reason.

    Sidd
    30 Jun 2017, 16:23:04 UTC
    von Veröffentlicht: 30.06.2017 22:55
    1. Kategorien:
    2. Projekte

    Wie bereits angekündigt, erweitert das Projekt mit einer neuen Anwendung seinen Suchbereich bis 10^20. Die neue Anwendung wird die Standardanwendung für GPUs werden, wohingegen der Rest des alten Suchbereichs bis 2^64 nur noch von CPUs bearbeitet wird.

    Die Suche bis 10^20
    Es wird morgen (1. Juli) losgehen!

    Ich habe beschlossen, den Start der neuen Suche wegen der derzeitigen GPU-Leistungsprobleme zu beschleunigen.

    Was am 1. Juli geschehen wird:

    1) Es wird Aufgaben für die Anwendung "Amicable Numbers up to 10^20" geben.
    2) Alle GPU-Versionen der alten Anwendung "Amicable Numbers up to 2^64" werden nicht mehr akzeptiert.
    3) Die Credits für beide Anwendungen werden neu ausbalanciert, damit sich der RAC nicht ändert.

    Es sollten also alle GPUs automatisch zur neuen Anwendung wechseln und die alte Anwendung wird bis zum Ende ihrer Suche nur für CPU verfügbar bleiben.
    30.06.2017, 17:11:33 MEZ

    Originaltext:
    Zitat Zitat von https://sech.me/boinc/Amicable/
    The search up to 10^20
    It will be started tomorrow (July 1st)!

    I've decided to speed up the launch of the next search due to performance issues with GPU version that everyone experiences now.

    What will happen on July 1st:

    1) "Amicable Numbers up to 10^20" application will start receiving tasks.
    2) All GPU versions for the old application "Amicable Numbers up to 2^64" will be deprecated.
    3) Credit points for both applications will be re-balanced to make sure that RAC doesn't change.

    So all GPUs should automatically switch to the new application, and the old application will remain as CPU-only until it finishes.
    30 Jun 2017, 16:11:33 UTC
    von Veröffentlicht: 27.06.2017 18:55
    1. Kategorien:
    2. Projekte

    Die Anwendung wird derzeit aktiv weiterentwickelt (jetzt bereits Version 1.05 bzw. 1.07 für MacOS), inzwischen gibt es die Möglichkeit, mittels app_config.xml die CPU-Auslastung der OpenCL-Anwendung zu verringern, was allerdings auf Kosten der Bedienbarkeit des Rechners geht.

    CPU-Belastung der GPU-Anwendungen
    Die neue CUDA-Anwendung 1.03 benutzt keinen CPU-Kern mehr außer zur Berechnung des Atom-Ensembles zu Beginn.
    Die neue OpenCL-Anwendung 1.03 hat eine Kommandozeilenoption --nowait, welche die CPU-Last auf null reduziert, aber gleichzeitig das System aufgrund verzögerter Reaktion nahezu unbenutzbar macht. Wenn ihr euren Rechner während des Crunchens nicht anderweitig nutzt, könnt ihr folgendes zu eurer app_config.xml hinzufügen:
    Code:
    <app_version>
        <app_name>xansons_gpu</app_name>
        <plan_class>opencl_ati_102_windows</plan_class>
        <cmdline>--nowait</cmdline>
    </app_version>
    Ersetzt 'opencl_ati_102_windows' durch die passende Klasse: opencl_ati_102_mac, opencl_ati_102_linux, opencl_intel_gpu_102_windows, opencl_intel_gpu_102_linux, opencl_intel_gpu_102_mac oder opencl_nvidia_102_linux.

    Aktualisierung
    Alle OpenCL-Anwendungen der Version 1.03 wurden aufgrund eines möglichen Speicherleck-Problems als Beta-Anwendungen markiert.


    Aktualisierung 2
    Die Anwendung 1.03 belegt genau so viel Speicher wie Version 1.02, also gibt es kein Speicherleck. Die Speicherauslastung hängt von der WU ab. Die Aufgaben mit 'solid_material' im Namen können abhängig von den Startwerten bis zu 1,5 GB Speicher belegen. Bitte beachtet dies, wenn ihr mehrere WUs gleichzeitig ausführt.
    Ich werde versuchen, die Speicherauslastung in der nächsten Version zu verringern.
    26.06.2017, 00:13:15 MEZ

    Originaltext:
    Zitat Zitat von http://xansons4cod.com/xansons4cod/
    CPU usage in GPU apps
    The new CUDA app 1.03 does not use the CPU core anymore except for the computation of the atomic ensemble in the beginning.
    The new OpenCL app 1.03 has a command line option --nowait which when specified reduces the CPU load to zero but at the same time makes the system almost unusable due to lagging. If you do not use the system while crunching, you may add this to your app_config.xml:
    Code:
    <app_version>
        <app_name>xansons_gpu</app_name>
        <plan_class>opencl_ati_102_windows</plan_class>
        <cmdline>--nowait</cmdline>
    </app_version>
    Replace 'opencl_ati_102_windows' with the appropriate plan class: opencl_ati_102_mac, opencl_ati_102_linux, opencl_intel_gpu_102_windows, opencl_intel_gpu_102_linux, opencl_intel_gpu_102_mac or opencl_nvidia_102_linux.

    Update
    All OpenCL 1.03 versions are marked as beta due to potential memory leak problem.


    Update 2
    The 1.03 app uses exactly the same amount of memory as 1.02 does, so there is no memory leak. The memory consumption depends on the WU. Those tasks which have 'solid_material' in their names may consume up to 1.5 GB of memory depending on the initial data. Please take this into consideration when launching multiple WUs in parallel.
    I'll try to reduce memory consumption in the next version.
    25 Jun 2017, 23:13:15 UTC
    von Veröffentlicht: 27.06.2017 16:45
    1. Kategorien:
    2. Projekte

    Seit gestern wird die neue GPU-Anwendung für NVIDIA-GPUs unter Windows verteilt. Dazu muss in den Projekteinstellungen neben der Benutzung der Grafikkarte derzeit auch die Ausführung von Testanwendungen erlaubt werden.

    GPU-Anwendung
    Wie einige von euch vielleicht schon mitbekommen haben, ist eine GPU-Version der Enigma-Software zum Testen verfügbar. Sie benötigt eine NVIDIA-GPU und funktioniert vermutlich auf allem, was CUDA unterstützt; ich selbst habe sie auf einigen schwachen Karten getestet und sie funktionierte gut, auch wenn das System dadurch etwas verzögert reagierte und die WU-Laufzeiten sehr lang waren.

    Bis gestern wurde eine app_info benötigt, das wurde nun geändert und derzeit wird sie an alle Rechner geschickt, für die Beta-Arbeit in den Einstellungen erlaubt ist. Ich habe vorher die Beta-Einstellung für alle auf "aus" zurückgesetzt.

    Diese Anwendung ist als "Beta" markiert, weil es noch immer ein paar Probleme sowohl auf Client- als auch auf Serverseite gibt. Außerdem läuft die GPU-Anwendung derzeit mittels Wrapper und das verursacht ein paar Probleme, z.B. erwähnt diese Seite, dass das Unterbrechen der GPU-Anwendung, während ein Kernel läuft, zum Systemabsturz führen kann. Das ist der schlimmstmögliche Fall und bisher habe ich das noch nicht selbst gesehen, nehme aber an, dass es möglich ist.

    Ansonsten läuft die Anwendung friedlich, wenn sie unangetastet bleibt. Momentan läuft sie nur auf dem CUDA-Gerät #0.

    Der Fortschrittsbalken funktioniert nicht mit der aktuellen Version des Wrappers, aber das ist derzeit unwichtig, da die Aufgaben relativ kurz sind: von etwa 20 Minuten auf GTX 1050 bis etwa 3:30 Minuten auf 1080 Ti. Die Anwendung setzt intern Checkpoints und setzt im Falle eines Neustarts automatisch vom letzten Checkpoint fort.
    26.06.2017, 19:22:48 MEZ

    Originaltext:
    Zitat Zitat von http://www.enigmaathome.net/
    GPU app
    As some of you may have already noticed, there is a GPU version of Enigma software available for testing. It requires nvidia GPU, and probably will run on anything that supports CUDA, I have tested it myself on a couple of low end cards and it ran just fine, except that the system was lagging and WU runtime was very long.

    Until yesterday it required app_info to run, this was changed and currently it will be sent to any host that has 'beta work' allowed in preferences. I have reset the beta flag to off for everyone.

    The app is marked as "beta" because there are still some issues both on the client and server side. Also, currently the GPU app runs via wrapper and that causes some issues, for example, this page says that interrupting GPU app while it is running the kerney may cause system crash. This is worst case scenario and so far I haven't seen it myself, but I assume it's possible.

    Other than that, if left untouched, the app runs smoothly. At this moment it'll only run on CUDA device #0.

    Progress bar does not work with the current version of the wrapper, but it's not a high priority thing at this moment, as tasks are relativery short: from ~20 minutes on GTX1050 to around 3m30s on 1080Ti. The app uses internal checkpoints and will automatically resume from the last checkpoint if restarted.
    26 Jun 2017, 18:22:48 UTC
    von Veröffentlicht: 26.06.2017 21:20
    1. Kategorien:
    2. Projekte

    Der neue Sixtrack-Validator funktionierte noch nicht richtig und führte zu einer erhöhten Zahl von als ungültig markierten WUs. Im Laufe des Tages wurden einige Rechner mit hoher Fehlerquote gesperrt, das wurde inzwischen wieder rückgängig gemacht. An einer dauerhaften Lösung wird weiterhin gearbeitet.


    Außerdem wird es in wenigen Stunden wegen einer Softwareaktualisierung zeitweise keine Aufgaben für die vbox-WUs des Subprojektes CMS Simulation geben. Um auszuschließen, dass man zeitweise leere vbox-WUs bekommt, empfiehlt es sich, so lange keine neuen Aufgaben des Projektes zuzulassen.

    Aufgabenwarteschlange der CMS-Anwendung läuft leer.
    Wir wollen die WMAgent-Aufgabensteuerung aktualisieren, daher habe ich (hoffentlich) den nächsten Aufgabenstapel angehalten. Es sollte in 10-12 Stunden keine neuen Aufgaben mehr geben, setzt daher bitte sobald wie möglich alle Rechner, die CMS-Aufgaben bearbeiten, auf "keine neue Arbeit". Es sollte morgen wieder laufen.
    26.06.2017, 16:59:30 MEZ


    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/
    CMS application job queue is being run down.
    We want to update the WMAgent job controller, so I've stopped the next batch (I hope). We should run out of jobs in 10-12 hours, so set any machine running CMS tasks to No New Tasks as soon as practicable. Should be up again tomorrow.
    26 Jun 2017, 15:59:30 UTC
    von Veröffentlicht: 26.06.2017 20:50
    1. Kategorien:
    2. Projekte

    In den letzten Tagen wurden einige fehlerhafte WUs mit Namen ps_modfit* verteilt, diese wurden nun aus dem System genommen.

    Fehlerhafte Durchläufe am Wochenende verteilt
    Hallo zusammen,

    ihr könntet einige ungültige Ergebnisse und Fehler bei Durchläufen, die mit ps_modfit* beginnen, sehen, da es einige fehlerhafte Durchläufe gab. Von diesen Durchläufen sollte nichts mehr verschickt werden, da ich alle zugehörigen WUs abgebrochen habe. Entschuldigung, dass ich das nicht früher bemerkt habe.

    Jake
    26.06.2017, 16:36:04 MEZ

    Originaltext:
    Zitat Zitat von http://milkyway.cs.rpi.edu/milkyway/
    Bad Runs Put Up Over The Weekend
    Hey Everyone,

    You can expect to see invalid results and erros from any runs starting with ps_modfit* as they were a bad batch of runs. No more of these runs should be sent out as I have cancelled all workunits associated with these runs. I apologize for not catching this sooner.

    Jake
    26 Jun 2017, 15:36:04 UTC

    Seite 51 von 107 Erste ... 41 49 50 51 52 53 61 101 ... Letzte
Single Sign On provided by vBSSO