Seit einigen Tagen schon wird die RC5-Statistik nur noch sehr unregelmässig (statt stündlich) aktualisiert. Die Ursache dafür ist, dass der für die Berechnung verantwortliche Perl-Prozess beim Auswerten der Logfiles mit einem segmentation fault abstürzt. Da das leider immer häufiger passiert, werden auch die zeitlichen Abstände zwischen erfolgreich berechneten Statistiken immer grösser.
Ich vermute, Perl hat ein Problem mit der inzwischen beachtlichen Datenmenge - der Prozess wächst bei einer vollständigen Berechnung auf über 50 MByte an. Für diese Vermutung spricht, dass die immer länger werdenden Logfiles immer seltener komplett eingelesen werden können, der Absturz nicht an einem bestimmten Logfile festzumachen ist, und die viel kleineren OGR-Statistiken einwandfrei berechnet werden. Defekte Hardware schliesse ich als Ursache aus, da das System ansonsten einwandfrei funktioniert: ein 'make build' des ganzen NetBSD lief ohne Fehler durch.
Deswegen werden ich in den nächsten Tagen den Kleinbus wohl booten müssen und 192 Tage uptime opfern, um mehr Speicher einzubauen und zu hoffen, dass die Statistiken dann wieder pünktlich berechnet werden.
Gestern fielen irgendwann zwischen 00:04 und 03:11 (MEZ) die europäischen Keyserver von distributed.net aus. Der RC5-Vorrat auf unserem Proxy dnet.kleinbus.org reichte nur noch bis 04:05. Erst um 14:24 haben die Keyserver wieder funktioniert. Das Problem war auch anderen Teams aufgefallen.
Ich habe deswegen die Buffergrösse verdoppelt, um zumindest kürzere Ausfälle besser überbrücken zu können.
Danke für den Hinweis ;)
Offensichtlich passt es der Düsseldorfer Bezirksregierung nicht, dass ihre Sperrwünsche von Isis zwar befolgt werden, der Provider aber auch per Redirect darauf verweist, wer die Aktion angezettelt hat. "Verbotene" Zugriffe werden jetzt nämlich schlicht geerdet.
soul% nslookup www.rotten.com ns.isis.de Server: issv0099.isis.de Address: 195.158.131.2 Name: www.rotten.com Address: 127.0.0.1
Oder möchte Isis nicht mehr weiter die Logfiles der Bezirksregierung füttern?
Zum Glück steht der Kleinbus nicht in Nordrhein-Westfalen:
soul% nslookup www.rotten.com Server: soul.kleinbus.org Address: 0.0.0.0 Non-authoritative answer: Name: www.rotten.com Address: 216.218.248.174 soul% nslookup www.rotten.com ns.isis.de Server: issv0099.isis.de Address: 195.158.131.2 Name: www.rotten.com Address: 195.158.131.132 soul% telnet 195.158.131.132 http Trying 195.158.131.132... Connected to virtual.isis.de. Escape character is '^]'. HEAD / HTTP/1.1 Host: www.rotten.com HTTP/1.1 302 Found Date: Thu, 22 Nov 2001 13:44:31 GMT Server: Apache/1.3.20 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6a Location: http://www.bezreg-duesseldorf.nrw.de/cat/SilverStream/Pages/themenframe?BeitragsID=2071 Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 Connection closed by foreign host.
Der Nameserver von Isis wurde drei Tage später wieder zunächst repariert, aber nur für ein paar Stunden...
Wegen Wartungsarbeiten am DSL-Anschluss kann es vom 06.09.2001, 22:00 bis 07.09.2001, 05:00 zu einem Ausfall der Anbindung kommen.
kleinbus.org steht wieder am alten Platz, aber an einer neuen Leitung. Die Downtime durch die Umstellung betrug rund 2 Stunden. Die neue IP-Nummer, für die keine weitere Änderung geplant ist, lautet
195.143.242.147
Das AmigaGer-Portal ist derzeit noch nicht unter www.amigager.de erreichbar, aber wie immer unter der bekannten Ausweichadresse http://www.kleinbus.org/~amigager/. E-Business-Consulter mit kaputtem Nameserver können die Seite auch unter http://195.143.242.147/~amigager/ erreichen.
Das reverse resolving wird noch eingerichtet.
Die Domain kleinbus.org und die Subdomains darunter (z. B. dnet.kleinbus.org) sind wieder wie gewohnt erreichbar. Jetzt fehlt noch das reverse resolving und www.amigager.de.
http://www.amigager.de/ ist übrigens ganz normal unter http://www.kleinbus.org/~amigager/ erreichbar.
kleinbus.org wird vorübergehend von einem netten AmigaGerler beherbergt, bis in ein paar Wochen meine eigene Leitung steht. Die Umstellung war mit einer Downtime von ca. 45 Minuten für den Transport durch Karlsruhe verbunden. Die neue IP-Nummer lautet
217.29.34.83
Alles funktioniert wie gewohnt, nur die Nameserver sind noch nicht aktualisiert. Dies betrifft insbesondere kleinbus.org mit allen Subdomains und www.amigager.de. Die zuständigen Nameserver werden so bald wie möglich mit der neuen IP-Nummer versorgt. Ausserdem ist noch kein reverse resolving eingerichtet.
Das bedeutet konkret:
Bedenkt bei Konfigurationsänderungen, dass diese IP-Nummer nur ein paar Wochen gültig sein wird.
Die Kleinbus-Leitung wurde ab sofort gekündigt. Daher ist mit Ausfällen in nächster Zeit zu rechnen. Spendenangebote in Form eines Stellplatz mit gerouteter IP-Nummer sind erwünscht.
kleinbus.org bekommt in den nächsten Tagen eine neue IP-Nummer.
reha.kleinbus.org läuft mit 300 MHz statt 450 MHz stabil. Ausserdem habe ich den de0-Treiber durch dc0 ersetzt, da dieser besser mit der 21143-Ethernetkarte zustammenspielt.
Laut Auskunft meines Händlers ist der defekte L2-Cache bei dieser Mainboard-Serie bereits von anderen Kunden reklamiert worden. Daher werde ich es noch diese Woche austauschen. Ich versuche die Ausfallzeit so kurz wie möglich zu halten.
Spenden in Form von Ersatz-CPUs oder -Netzteilen werden hoffentlich nicht mehr benötigt.
Das Problem mit dem L2-Cache besteht nach wie vor. Folgende möglichen Ursachen bin ich bereits nachgegangen:
Die einzige Komponente, die ich noch nicht ausgetauscht habe, ist also das Netzteil. Das werde ich aber frühestens am 05.03. ausprobieren können. Wenn das auch nicht hilft, geht der Bauteilaustausch in die nächste Runde, d. h. es ist nicht nur das ursprüngliche Bauteil, sondern auch das Ersatzteil defekt. Das erst vor 2 Tagen gekaufte Mainboard sollte sich noch problemlos umtauschen lassen, für die CPU suche ich noch ein Testexemplar.
kleinbus.org läuft jetzt mit einem neuen Mainboard anscheinend problemlos. Allerdings nur mit abgeschaltetem L2-Cache - wenn der angeschaltet ist, kommt das BIOS nicht einmal bis zur Erkennung der PCI-Karten. Entweder ist auch dieses Mainboard nicht ganz in Ordnung, oder beide CPUs (sowohl der K6-2/400 als auch der ersatzweise geliehene K6-2/300) haben den gleichen Fehler.
kleinbus.org läuft zur Zeit mit dem alten K6-2/400 bei 350 MHz und "optimal settings" im BIOS. Einige Programme wie z. B. gunzip und uucico coredumpen zwar, aber das meiste läuft damit.
Folgende Konfigurationen habe ich durchprobiert:
| CPU | MHz | BIOS | L2-Cache | Resultat |
|---|---|---|---|---|
| K6-2/300 | 300 | optimal | an | segfault |
| K6-2/300 | 300 | optimal | aus | ok |
| K6-2/400 | 300 | fail-safe | aus | ok |
| K6-2/400 | 300 | fail-safe | an | ok |
| K6-2/400 | 400 | fail-safe | an | panic |
| K6-2/400 | 400 | fail-safe | aus | panic |
| K6-2/400 | 350 | fail-safe | aus | ok |
| K6-2/400 | 350 | optimal | an | segfault |
Ich tippe auf ein fehlerhaftes Mainboard.
kleinbus.org läuft momentan zu instabil, um die Statistiken zu berechnen.
kleinbus.org läuft vorerst mit einem K6-2/300 und der BIOS-Einstellung "fail-safe" statt dem alten K6-2/400. Immerhin läuft der Rechner überhaupt wieder.
Weitere Tests und Reboots sind geplant.
distributed.net bittet darum, die Version 2.8012.* des dnetc nicht weiter zu verwenden, da darin (mal wieder) ein Bug zu fehlerhaften Ergebnissen führen kann. Stattdessen soll vorerst die Version 2.8010.* verwendet werden, bis ein Bugfix verfügbar ist.
kleinbus.org hat momentan ein Hardwareproblem, vermutlich ein defektes Mainboard. Dadurch bleibt der Rechner regelmässig (jede Nacht) mit kernel panic stehen. Besserung erst, wenn ich die Ersatzteile beschafft habe...
NetBSD 1.5.1_ALPHA (release-1-5 vom 29.01.2001) lässt sich momentan leider nicht compilieren. "make build" bricht mit folgender Fehlermeldung ab:
dependall ===> libexec/ftpd yacc ftpcmd.y mv y.tab.c ftpcmd.c mkdep -a -DHASSETPROCTITLE -DINET6 -DSKEY cmds.c conf.c ftpd.c logutmp.c logwtm p.c popen.c /usr/src/libexec/ftpd/../../bin/ls/ls.c /usr/src/libexec/ftpd/../../ bin/ls/cmp.c /usr/src/libexec/ftpd/../../bin/ls/print.c /usr/src/libexec/ftpd/.. /../bin/ls/stat_flags.c util.c ftpcmd.c cc -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin itialized -Werror -DHASSETPROCTITLE -DINET6 -DSKEY -c cmds.c [...] cc -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin itialized -Werror -DHASSETPROCTITLE -DINET6 -DSKEY -c util.c cc1: warnings being treated as errors In file included from util.c:55: extern.h:124: warning: `struct timeval' declared inside parameter list extern.h:124: warning: its scope is only this definition or declaration, extern.h:124: warning: which is probably not what you want. In file included from util.c:55: extern.h:238: syntax error before `errcatch' extern.h:238: warning: type defaults to `int' in declaration of `errcatch' extern.h:238: warning: data definition has no type or storage class util.c: In function `logcmd': util.c:71: number of arguments doesn't match prototype extern.h:124: prototype declaration *** Error code 1 Stop. [...]
util.c und extern.h passen tatsächlich nicht zusammen: in util.c wird logcmd() mit 4 Parametern benutzt, in extern.h aber mit 6 Parametern deklariert.
Falls es diese Woche noch compilierbare 1.5.1-Sourcen gibt, wird mal wieder kurzfristig ein Reboot fällig.
kleinbus.org läuft endlich unter NetBSD 1.5. Beim anschliessenden pkg-Mikado haben allerdings ein paar Packages gewackelt und sind daher zur Zeit nicht verfügbar. Welches das genau sind, weiss ich selbst nicht so genau...
Die dnet-Statistiken werden zur Zeit nicht aktualisiert; der Proxy läuft aber, und die Logfiles werden gesammelt. Das Logrotationsskript ist beim NetBSD-Upgrade gestolpert.
Einige Packages sind auf einem neueren Stand. Unter anderen funktioniert lynx jetzt wieder.
Netzstatus 2001-01-14 22:40: 0 hosts up (2001-01-13 18:15: 109)
NetBSD 1.4.3 wurde endlich erfolgreich installiert. Die PHP4-Package reagiert auf Startversuche leider noch mit core dumps, deswegen habe ich PHP3 wieder reinstalliert.
Nach einem Update des OS und des Drumherums konnte leider der Apache nicht mehr korrekt starten, weil sein PHP aktualisiert wurde. Um wenigstens auf der Pirsch zu bleiben, liegt bis zur Neuinstallation deshalb die PHP-Feder im Wigwam.
DON'T PANIC
Die RC5-Statistiken wurden seit dem Abend des 28.10. nicht mehr aktualisiert. Zur Fehlereingrenzung hat der Aushilfssysop auf Probe deshalb einen Sprengsatz gelegt, um die Verstopfung zu lösen.
Nach der Detonation wird er aus den Resten neue Statistiken zusammenkleben. Tesafilmspenden herzlich willkommen!
Der Kleinbusoperator trifft sich mit anderen Indianerhäuptlingen zu einem Pow-Wow in London. Um die RC5-Statistiken werden sich hoffentlich der Aushilfssysop auf Probe und der Kanalstatistiker kümmern.
Wegen guter Führung wird Top heute wie befürchtet entlassen. Die Ausweisung erfolgt vermutlich um 10:00 herum, bevor er wirklich auf freien Fuß kommt, ist jedoch noch etwas Papierkram zu erledigen.
Unser operierter Operator wird langsam operabel. Er kann die rechte Hand mittlerweile wieder zum Tippen benutzen, wenn auch nur langsam und nicht sehr lange, weil die Armhaltung schnell zu Verspannungen führt. Das Mausschieben klappt noch nicht sehr gut, aber welcher BOFH (Beschädigter Operator Für Heimarbeit) braucht schon eine Maus ...
Letzter Stand der Planung ist "Entlassung am Montag früh" und dann noch längere Zeit Pyhsiotherapie %-) Mit etwas Glück ist Top also ab Montag Nachmittag wieder zu hause.
Beim letzten Besuch am Freitag sind noch ein paar zusätzliche Bilder entstanden. Leider fehlt immernoch das entscheidende Motiv.
Der Patient macht mittlerweile ausgedehnte Spaziergänge. Dabei muß er nicht einmal mehr die Armschiene tragen. Nach letztem Erkenntnisstand wird er am Samstag wieder auf den Rest der Menschheit losgelassen.
Unter den heutigen Besuchern war auch jemand mit Digitalkamera, so daß sich nun jeder ein Bild machen kann.
Es geht weiter aufwärts. Mittlerweile ist die Anbindung an den Rest der Welt durch ein passendes Terminal gewährleistet. Auch das Telephon ist in Gebrauch. Bisheriger Rekordhalter ist ein Anrufer aus Indien!
Besucher können Lesestoff, Computerspiele, RC5-Blöcke und andere Mitbringsel direkt beim Empfänger im Städtischen Klinikum Karlsruhe, Gebäude C (Altbau), Station C27, (1. OG), Zimmer 217 abgeben.
Operation gelungen, Patient lebt! Der Kleinbusbetreiber ist wieder wohlauf, wenn auch noch etwas groggy und am Tropf hängend.
Nach dem aktuellen Stand der Reparaturarbeiten kann man sich unter der kostenpflichtigen Nummer +49 721/974-55061 erkundigen. Dort gibt ein freundlicher Operator, der sonst nichts zu tun hat und sich deshalb über jeden Anruf freut, Auskunft.
Wegen Reparaturarbeiten am Operator wird es in den nächsten Tagen zu Verzögerungen bei der Kleinbuswartung kommen. Um die Statistiken werden sich wie üblich der Aushilfssysop auf Probe und der Kanalstatistiker kümmern (letzterer weiss allerdings noch nichts von seinem Glück).
ircII und procmail wurden durch neue Versionen ersetzt. mrtg ist neu installiert.
Wer sehen möchte, wieso ein Host als ungültig gekennzeichnet ist, braucht nur auf den Namen zu klicken und dann auf Participants working for this Hostname. Die fehlenden oder fehlerhaften Adressen sind dort aufgelistet.
Wegen eines Gerätefehlers bei der Telekom war heute die Verbindung zum DeCIX von 10:26 bis 12:55 ausgefallen.
Wie einige schon bemerkt haben, läuft kleinbus.org jetzt unter der aktuellen release-Version von NetBSD. Ich bitte die dazu nötigen Reboots zu entschuldigen.
Ausser diesen Reboots hat es mehrere vermutlich wetterbedingte Abstürze gegeben. Diese werden in den nächsten paar Monaten voraussichtlich seltener vorkommen.
Auf vielfachen Wunsch habe ich die Indexseite von kleinbus.org in Index und News aufgeteilt. Ausserdem wurden die Statistikseiten unter dnet.kleinbus.org auf 50 Einträge pro Seite gekürzt.
Meine Bitte, möglichst grosse Blöcke bei RC5 zu verwenden, gilt in diesem Zusammenhang natürlich weiter.
Ja, auch ich habe bemerkt, dass in den letzten Wochen Kleinbus und Amiga-Team mehrmals auf den vorderen Plätzen bei OGR-25 und RC5 lagen. Leider bin ich nicht dazu gekommen, dies in angemessener Form hier zu verkünden. Ich bitte das zu entschuldigen.
Wie aufmerksame Statistiker schon feststellten, markiert meine Version von ppstats jetzt nicht nur OGR-Blöcke, sondern auch bestimmte RC5-Blöcke als ungültig. Diese Blöcke werden im Gegensatz zu OGR von distributed.net zwar nicht weggeworfen, enthalten aber ungültige E-Mail-Adressen. Damit tauchen sie dort nicht in der Statistik für rc5@kleinbus.org auf. Gefiltert werden zur Zeit folgende Adressen:
Für OGR gilt weiter die Regel, dass Stubs erst ab dnetc-Version 2.8009.* gültig sind.
Ich bitte noch einmal darum, die Blockgrössen nicht zu klein zu wählen. Die Verteilung sah in den letzten beiden Monaten so aus:
| August | Juli |
|---|---|
2^ sz blocks %blocks keys %keys 28 1 230111 47.00% 230111 15.66% 29 2 71214 14.54% 142428 9.69% 30 4 133180 27.20% 483509 32.89% 31 8 40191 8.21% 298101 20.28% 32 16 5636 1.15% 87178 5.93% 33 32 9293 1.90% 228537 15.55% sum 489625 100.00% 1469864 100.00% |
2^ sz blocks %blocks keys %keys 28 1 163120 30.55% 163120 9.88% 29 2 72224 13.53% 144448 8.75% 30 4 256783 48.10% 972790 58.94% 31 8 37766 7.07% 286434 17.35% 32 16 2656 0.50% 42085 2.55% 33 32 1315 0.25% 41610 2.52% sum 533864 100.00% 1650487 100.00% |
Die Kleinstblöcke machen also fast den halben Traffic aus, wie an der Spalte "%blocks" zu sehen ist; im Juli sah das noch etwas besser aus. Natürlich liegt das auch daran, dass der Proxy oft kleinere Blöcke verteilt als im Client eingestellt ist, weil sein Vorrat schon fragmentiert ist - aber er fragmentiert ja gerade deswegen, weil andere vorher schon kleine Blöcke angefordert haben.
Grössere Blöcke brauchen auf allen Stufen (Client, Proxy, Keyserver) weniger Bandbreite. Deswegen also bitte möglichst gross einstellen. Der Menüpunkt im aktuellen Client ist 2/12, bzw. preferred-blocksize in der ini-Datei. Ungefähr eine Stunde pro Block ist ein brauchbarer Wert.
Das Amiga-Team hat es geschafft: Platz 1 bei OGR-25 in der Gesamt- und in der Tageswertung. Schade, dass Teamkoordinator Thomas Tavoly noch bis zum Wochenende verreist ist - aber wir werden natürlich dafür sorgen, dass das Amiga-Team den Platz hält, oder?
Zu diesem Erfolg des Amiga-Teams hat der Kleinbus auch einen gewissen Beitrag geleistet: Wir haben bei OGR-25 Platz 2 in der Gesamt- und erstmals Platz 1 in der Tageswertung erreicht. Nächster Meilenstein: Platz 1 gesamt bei OGR-25, und dann ist RC5 an der Reihe!
Wer's noch nicht mitbekommen hat: distributed.net hat vor ein paar Tagen das nächstlängere OGR-Projekt angefangen. Da die offizielle Statistik OGR-24 und OGR-25 getrennt zählt, gibt es auch auf dem Kleinbus eigene Statistiken für die beiden Wettbewerbe.
Die Stubs bei OGR-25 dauernd deutlich länger als bei OGR-24 - ungefähr zehnmal so lang. Dies sollte bei der Client-Konfiguration berücksichtigt werden. Ein 68060 kann durchaus eine Woche für einen Stub benötigen. Also kleine Buffer wählen, Checkpoint-Files aktivieren, oder langsame Rechner für RC5 reservieren.
Das bedeutet übrigens nicht, dass OGR-24 schon fertig ist. Zur Zeit werden nur keine Blöcke ausgeliefert, um erst einmal den Rücklauf von alten Blöcken abzuwarten.
Dank einer kleinen Optimierung dauert die Berechnung der RC5-Statistik jetzt weniger als 8 Minuten. Deswegen gibt es sie wieder zu jeder vollen Stunde. OGR-24 und OGR-25 werden ebenfalls (wie bisher) stündlich aktualisiert.
Nachtrag: Die "By Hour"-Statistik sollte man sich momentan besser nicht anschauen. Ich bastle noch an einer Lösung, die "By Hour" nicht verfälscht und trotzdem die Laufzeit erträglich bleiben lässt.
Der Spiegel berichtet in der Papierausgabe 32/2000 vom 07.08.2000 über verteiltes Rechnen per Internet. In dem Artikel geht es hauptsächlich um SETI@home und mögliche kommerzielle Anwendungen, und auch der Chef von distributed.net David "nugget" McNett darf sich (kurz) äussern. Über den Kleinbus wird kein Wort verloren...
Die Packages ircII, mutt und gnuplot wurden aktualisiert, ausserdem gibt es jetzt den Midnight Commander "mc" und die bunte lynx-Alternative "links".
2000-07-13 22:15:02,Uplink: [1] Server says contest ogr is now open.
Jetzt scheint distributed.net sogar sich selbst überrascht zu haben: heute Nacht wurde um 00:07 MESZ der OGR-Wettbewerb angekündigt, und schon 8 Minuten später trafen die ersten Stubs beim Proxy ein. Dabei war der Start eigentlich erst für 02:00 MESZ geplant. Inzwischen wurde der Termin rückwirkend auf 13.07.2000 23:43 MESZ korrigiert...
Die Proxy-Statistik ist bereits eingerichtet und wird jeweils zur vollen Stunde aktualisiert, zumindest solange, bis der Server wieder unter dem Statistik-Skript zusammenbricht. Weil distributed.net die Daten vom ersten OGR-Versuch im Februar für ungültig erklärt hat und von vorne beginnt, habe ich das gleiche mit der Statistik gemacht. Die alten Ergebnisse bleiben aber weiter abrufbar. Und dieses Mal gibt es auch offizielle OGR-Statistiken.
Wichtig: Clients mit der Version 2.8002 bis 2.8008 sollten unbedingt aktualisiert oder auf RC5 umkonfiguriert werden. Diese Clients können zwar prinzipiell OGR rechnen, produzieren dabei aber nur ungültige Stubs, die vom Masterserver nicht gewertet werden. In der Proxy-Statistik ist zu sehen, wieviele Stubs gerade umsonst gerechnet werden.
| vor 2.8002: | kein Problem, rechnet sowieso nur RC5 |
| 2.8002 - 2.8008: | auf RC5 konfigurieren oder Update! |
| 2.8009 - 2.8010: | kein Problem, rechnet OGR und RC5 |
Wer bei OGR nicht mitmachen möchte oder wegen eines veralteten Clients nur ungültige Daten liefern würde, sollte in der dnetc-Konfiguration unter 2/9 (Load-work precedence) "OGR:0,RC5" eintragen. "OGR" einfach nur aus der Liste zu löschen reicht nicht.
Grundsätzlich wechselt der Client regelmässig zwischen OGR und RC5, indem er erst dann eine Verbindung zum Proxy herstellt, wenn alle Buffer für alle Wettbewerbe leer sind. Wer dies nicht möchte, kann unter 2/10 (Additional buffer-level checking) die Option "4" wählen. Dann holt der Client schon dann neue Daten, wenn der Buffer des ersten Wettbewerbs (siehe 2/9) geleert ist.
Noch etwas: bitte unter 2/13 einen plausiblen Wert für OGR einstellen. Die Stubs sind bei den neuen Clients zwar kleiner, der Default bei "OGR=0" scheint mir trotzdem für langsame Rechner etwas zu gross geraten zu sein (mein 68060 hat sich 25 Stubs geholt - der wird damit sicher nicht an einem Tag fertig). Was plausible Werte sind, wird sich in den nächsten Tagen herausstellen. Die Option 2/14 (Fetch time threshold) existiert für OGR leider nicht.
distributed.net bittet noch einmal darum, die Blockgrössen für RC5 nicht zu klein zu wählen. Grössere Blöcke könnten 30% Traffic sparen, worüber sich deren Bandbreitensponsor sehr freuen würde. Selbstverständlich zählt ein 33er Block mit 2^33 Keys statistisch exakt so viel wie 32 einzelne Blöcke mit je 2^28 Keys.
Am 10.07. kam es durch den instabilen Router (siehe News vom 08.07.) zwischen 13:30 und 14:30 zu mehreren ca. 2-minütigen Ausfällen. Um dies endgültig abzustellen, soll am 12.07. zwischen 7 und 8 Uhr der komplette Router ausgetauscht werden. Dadurch wird es zu einem weiteren Ausfall von ein paar Minuten kommen.
Wer jetzt seinen Client auf grössere Blöcke konfiguriert hat, wird sich vielleicht gewundert haben, wieso der Proxy trotzdem noch so viele Blöcke mit 2^28 oder 2^29 Keys liefert. Der Grund dafür ist, dass die Blöcke bereits auf dem Proxy oder den Keyservern fragmentiert sind, weil andere Clients vorher schon kleine Blöcke gerechnet und wieder zurückgegeben haben. Dadurch bleiben auch für die Clients, die eigentlich grössere Blöcke bestellt haben, nur noch Krümel übrig.
Ändern kann ich daran nichts. Der Proxy arbeitet grundsätzlich mit 2^34 Keys pro Block - so grosse Blöcke lassen sich bei den Clients gar nicht einstellen. Es ist aber geplant, dass die nächste Version des dnetc grundsätzlich die grösstmöglichen Blöcke bestellt, intern in kleinere Portionen zerlegt, und dann wieder am Stück zurückliefert. Damit würden dann wenigstens alle neuen Clients nicht mehr zur Fragmentierung des Keyspace beitragen.
Durch eine minimale Änderung im Statistikprogramm konnte die Laufzeit von 80 auf 60 Minuten gesenkt werden. Die Aktualisierungsfrequenz wurde aber nicht erhöht. Frische Stats gibt's um 1, 5, 9, 13, 17 und 21 Uhr.
Von Perl, vim, mutt und bash sind neuere Versionen installiert.
Falls man den Geburtstag von kleinbus.org am Registrierungsdatum der Domain festmacht, wird der Kleinbus heute 1 Jahr alt. Über Geschenke in Form von RC5-Blöcken würde kleinbus.org sich sehr freuen. ;-)
Und noch ein Anlass zum Feiern: für den Kleinbus wurde gestern der zehnmillionste Block abgegeben.
distributed.net bittet darum, die Clients auf eine sinnvolle Blockgrösse zu konfigurieren, um die Keyserver (auch Proxies) zu entlasten. Im Juni liefen fast alle Clients mit höchstens 2^30 Keys/Block. Auf vielen Rechnern sind solche Blöcke aber in 10 bis 30 Minuten gerechnet, das heisst, es werden 50 bis 150 Blöcke pro Tag an die Keyserver geliefert. Das führt zu zusätzlicher Netzlast, grösseren Logfiles und verzögerten Statistiken.
Einstellbar ist die Blockgrösse unter 2/12, "Preferred packet size". Erlaubt sind Werte von 28 bis 33 (bei sehr alten Clients nur bis 31), default ist 30. Die Variable in dnetc.ini heisst preferred-blocksize unter [rc5].
Was ist nun eine sinnvolle Blockgrösse? distributed.net schlägt vor, dass ein Block mindestens 45 Minuten Rechenzeit benötigen sollte. Das würde in der Praxis folgendermassen aussehen:
| kkeys/s | Blockgrösse | CPU (Beispiele) |
|---|---|---|
| < 100 | 28 | 68040, 80486, P/90 |
| 100-200 | 29 | 68060, P/90-133, PPC 601 |
| 200-400 | 30 | P/133-233, K5, K6/233 |
| 400-800 | 31 | K6/266-450, P-2/266, PPC 603e/604e |
| 800-1600 | 32 | K6/500-, P-2/300-550, G3 |
| > 1600 | 33 | K7, P-2/600-, G4 |
Selbstverständlich darf man grössere Werte als oben vorgeschlagen verwenden - ein 33er Block wird auch auf einem 68060/50 irgendwann fertig, es dauert nur ca. 16 Stunden. Allerdings können dann mehrere Stunden Rechenzeit verloren gehen, falls der Rechner ausfällt. Ist wegen des Betriebssystems oder der Stromversorgung mit häufigen unfreiwilligen Reboots zu rechnen, empfiehlt es sich daher, bei grossen Blöcken das Checkpointfile einzuschalten. Das ist über den Menüpunkt 2/4 oder die Konfigurationsvariable checkpoint-filename in [buffers] einstellbar. Der Client speichert dann in dieser Datei (z. B. "chkpoint.rc5") alle paar Minuten ein Zwischenergebnis.
In letzter Zeit war kleinbus.org mehrmals für kurze Zeit nicht erreichbar. Die Gründe dafür, soweit bekannt:
NetPBM und Metamail waren zwar schon mal installiert, sind aber beim Crash im Januar verlorengegangen. Jetzt gibt es sie wieder.
Dank der Mithilfe eines Kleinbus-Mitfahrers gibt es den aktuellen Client (2.8010.462) jetzt auch für NetBSD/i386. Damit ist es nun nicht mehr nötig, dort die FreeBSD-Version des dnetc zu verwenden.
Der aktuelle Client 2.8010.462 ist nun auch für Windows und FreeBSD (x86) erschienen. Angeblich soll der auf Athlons noch schneller sein, was ich aber nicht feststellen konnte.
Schon 2 Jahre nach dem letzten Update ist heute eine aktuelle Version (v2.8010.461) des dnetc für AmigaOS (68k und PPC) erschienen. Damit ist der Amiga Windows wieder einmal einen Schritt voraus - es geht aufwärts!
Der neue Client ist schneller (+25% auf 68060), stabil, und er unterstützt OGR, falls das irgendwann wieder los geht. Also unbedingt empfehlenswert.
Vom 28.06.2000 23:53 bis 29.06.2000 02:48 war die Verbindung nach Frankfurt aufgrund eines defekten Routers in Stuttgart ausgefallen. Dadurch war der Kleinbus nur noch für einen sehr kleinen Teil des Netzes erreichbar.
In so einem Fall schicken die Clients ihre Blöcke an einen der offiziellen Keyserver von distributed.net. Dadurch gehen sie zwar nicht verloren, werden aber nicht mehr in unserer eigenen Statistik gezählt. Wer das vermeiden möchte, sollte in dnetc.ini im Abschnitt [networking] folgende Option einfügen:
nofallback=true
Diese Option ist in den aktuellen Clients nicht über das Konfigurationsmenü erreichbar.
Nachteil: auch das Abholen neuer Blöcke ist davon betroffen. Falls dem Client die Keys ausgehen, kann er nur noch auf Zufallsblöcke ausweichen.
Für Athlons lohnt sich der Update auf dnetc 2.8009: ungefähr 10% schneller als die älteren Clients. Aufpassen: Nach einem Update unbedingt die Keyserver-Konfiguration kontrollieren. Diese Version schickt nämlich per default alle Blöcke zu den Keyservern von distributed.net statt zu unserem Proxy. Im Konfigurationsmenü sollte bei Punkt 2/6/2 "no" stehen.
Damit der Stats-Rechner ab und zu verschnaufen kann, werden die Statistiken seit kurzem nur noch alle 4 Stunden berechnet.
In der nächsten Zeit kann es sein, dass Hostnamen einen halben Tag oder noch länger unbearbeitet in der byhost-Statistik erscheinen. In diesem Fall bitte Geduld - irgendwann wird sich schon jemand darum kümmern.
Nachdem immer wieder gefragt wird, wieso um 14:30 erst die Statistik von 10:00 abrufbar ist, hier die Begründung:
Punkt 3 werde ich vielleicht irgendwann beheben, wodurch sich automatisch auch Punkt 2 erledigen wird. An Punkt 1 wird sich nichts ändern: das gesamte Statistik- und Proxy-System von distributed.net verwendet GMT als Zeitbasis. Die Proxystatistik "teilweise" auf lokale Zeit umzustellen ist ziemlich knifflig; eine komplette Umstellung wäre noch aufwendiger, und die Proxystats wären dann nicht mehr mit den offiziellen Stats vergleichbar.
In der "By Hour"-Statistik ist die Zeit jetzt im üblichen 24-Stunden-Format statt im am/pm-Format angegeben.
Ab 17.04.2000 läuft der Betatest des nächsten OGR-Clients. Es ist also davon auszugehen, dass es "bald" neue Clients und einen neuen Anlauf des OGR-Wettbewerbs gibt...
Die Wochenstatistik und die Wochentagsstatistik halten sich jetzt an DIN 1355 (Punkt 1.3.3) bzw. ISO 8601 (Punkt 3.17 - Achtung: 1,2 MByte PDF).
Damit der Kleinbus nicht während des IRC-Streik auseinanderfällt, hat obw auf irc.kleinbus.org einen Ersatzserver für die Dauer des Streiks eingerichtet.
Wegen eines Systemfehlers bei der Telekom (was immer das auch bedeuten mag) war der Kleinbus von ca. 12:05 bis 13:35 grösstenteils vom Netz abgeschnitten.
Der Reboot heute gegen 09:15 wurde durch einen kurzen Stromausfall verursacht. Dadurch war der Kleinbus für ca. 3 Minuten nicht erreichbar. Irgendwelche Folgeschäden habe ich nicht bemerkt.
Die Packages ircII, MySQL, Apache und fetchmail wurden aktualisiert. Ausserdem ist jetzt tcl installiert.
Auf Anregung von m-a habe ich diese Seite durch den HTML-Validator geschickt. Der hat nur den fehlenden DOCTYPE bemängelt - jetzt nicht mehr (und nein, ich weiss noch immer nicht, wo der <h1> geblieben ist...).
Heute vormittag hatte der Proxy von 10:35 bis 10:57 keine Blöcke mehr vorrätig. Ursache dafür war, dass von mindestens 10:17 bis 10:57 keiner der drei Keyserver ansprechbar war. Ausserdem hatten drei unserer schnellsten Teilnehmer in diesem Zeitraum frische Blöcke abgeholt; bei durchschnittlichem Verbrauch wären genug Blöcke für über eine Stunde vorrätig gewesen.
Da laut Logfiles in letzter Zeit der Vorrat immer wieder mal für wenige Minuten leer gelaufen ist, habe ich zum einen das Update-Intervall auf 5 Minuten halbiert und zum anderen die Menge der vorgehaltenen Blöcke auf 4000 verdoppelt. Das hilft zwar auch nicht bei einem längeren Ausfall mehrerer Keyserver, Bedarfsspitzen sollten damit aber besser abgesichert sein.
Warum nicht mehr Blöcke? Der Proxy lagert die Blöcke nach dem LIFO-Prinzip, das heisst, frische Blöcke werden zuerst verteilt, und ältere Blöcke werden immer älter. Es wäre zwar möglich, für bis zu 4 Tage Blöcke zu lagern, aber wenn diese dann tatsächlich einmal gebraucht werden sollten, wären sie längst verfallen.
Bemerkt wurde der Ausfall dadurch, weil mindestens ein Client (2.7100.413, AmigaOS) sich beendet hatte, nachdem zwei aufeinanderfolgende Fetch-Versuche fehlgeschlagen waren.
Da dnet.kleinbus.org inzwischen zu 60% der Zeit mit dem Berechnen der Statistiken beschäftigt ist, wurde das Update-Intervall vorübergehend auf 2 Stunden erhöht, bis eine intelligentere Lösung implementiert ist.
Wegen eines Fehlers im dnetc, der beim Austausch von Buffern zwischen unterschiedlichen CPUs auftreten kann, hat distributed.net das OGR-Projekt angehalten, bis eine korrigierte Version des Clients verfügbar ist. Leider müssen die bereits bearbeiteten Blöcke noch einmal verteilt werden; deswegen werde ich die OGR-Statistiken wieder bei Null starten, sobald der zweite Versuch läuft.
Der Kleinbus war heute nacht für längere Zeit nicht erreichbar, da die Verbindung nach Frankfurt ausgefallen war. Ursache war ein Leitungsausfall der Telekom im Bereich Stuttgart. Möglicherweise haben deswegen ein paar Clients vorübergehend auf RC5 umgeschaltet, was ja nicht unbedingt ein Nachteil ist.
Wer mal vi in bunt sehen möchte, kann jetzt vim ausprobieren. PHP-Code sieht damit wirklich grell aus...
Jeweils zur halben Stunde gibt es OGR-Stats für den Kleinbus. Der Autor des Auswertungsprogramms hatte praktischerweise schon kurz nach dem Start des Projekts eine an OGR angepasste Version veröffentlicht, was mir viel Arbeit erspart hat. Von distributed.net gibt es - bis auf die Gesamtgeschwindigkeit - leider noch keine Statistiken.
Wie inzwischen schon einige Leute festgestellt haben, kann die Rechenzeit für einen einzigen OGR-Block ("stub") auch auf schnellen CPUs im Bereich von vielen Stunden liegen. Diese Zeit variiert aber sehr stark: ein anderer Block auf der gleichen CPU ist vielleicht schon nach einer Stunde fertig. Dadurch ist es sehr schwer abzuschätzen, wieviele Blöcke man denn nun am besten buffert - die Option zur automatischen Abschätzung durch den Client existiert aus diesem Grund erst gar nicht. Man sollte aber unbedingt einen Wert angeben, sonst übernimmt der Client nämlich die Einstellungen von RC5, was dazu führen kann, dass er für ein paar Monate beschäftigt ist. Mehr als 10 Blöcke sind vermutlich nicht sinnvoll. In der dnetc.ini wird das so angegeben:
[ogr] fetch-workunit-threshold=10 flush-workunit-threshold=10
Es gibt anscheinend noch einen Bug im Client, wodurch der flush-Wert ignoriert wird; anstelle des konfigurierten flush-Wertes wird der fetch-Wert übernommen. Dieser Bug (und andere) ist bereits an distributed.net gemeldet - also abwarten, ob in den nächsten Tagen neue Clients erscheinen.
Mit einem Tag Verspätung wurde heute morgen kurz nach 7 Uhr das OGR-Projekt gestartet. Das wichtigste kurz zusammengefasst:
Auch diese Nacht ist der Proxy beim Komprimieren der Logs gecrasht. Ich habe diese Funktion vorerst abgestellt.
Der neue distributed.net-Proxy ist gegen 01:00 beim Komprimieren der Logfiles gecrasht. Ursache dafür war eine Änderung im Code der FreeBSD-Version, wodurch der Proxy nun nicht mehr ohne weiteres unter NetBSD läuft. Ich habe jetzt die FreeBSD-Libraries installiert und hoffe, dass die nächste Rotation problemlos funktioniert. Falls nicht, bleibt mir noch die Möglichkeit, die Logs per cron-Job zu komprimieren. Eine aktuelle NetBSD-Version existiert leider nicht. distributed.net ist informiert.
Am 14.02.2000 beginnt das Projekt OGR. Voraussetzung ist der dnetc-Client ab Version 2.8007.458. Der Proxy ist bereits auf OGR vorbereitet, aktuelle Clients schalten also automatisch um. Wie die Stats aussehen werden, weiss ich noch nicht; distributed.net hat selbst noch keine OGR-Stats. Da die Grösse des "Keyspace" nicht im Voraus bekannt ist, ist keine Prognose möglich, wie lange das Projekt dauern wird. Der SQL-Meister von distributed.net hat aber angedeutet, dass das Projekt möglicherweise eher abgeschlossen ist als er die neuen Stats programmiert hat...
Folgende Pakete wurden installiert oder aktualisiert:
Der CSC-Schlüssel wurde von Paul Ilardi mit einer Sparc Ultra 1 gefunden.
Die verschlüsselte Nachricht lautete übrigens vollständig
The secret message is: CS-Cipher a ete presente en mars 97 a 'Fast Software Encryption' (PARIS). Congratulations to the winner!
Was soviel bedeutet wie "CS-Cipher wurde im März 97 auf der 'Fast Software Encryption' (PARIS) vorgestellt" - und gar nicht stimmt, denn CS-Cipher wurde erst auf der FSE '98 vorgestellt. Die FSE '97 fand in Haifa statt.
Am 19.01. wurde zwischen 5:00 und 7:00 an einem Router in Frankfurt gebastelt, wodurch der Kleinbus mehrmals für ein paar Minuten nicht erreichbar war. Das hat hoffentlich niemanden gestört.
Für noch schönere und vor allem schnellere Stats habe ich jetzt MySQL und das passende Python-Modul installiert. PHP3 sollte auch damit gehen. Auch für andere Projekte steht damit endlich eine brauchbare Datenbank zur Verfügung.
Am 16.01.2000 um 07:26:52 MEZ wurde der CSC-Key gefunden. Sieger ist ein noch nicht identifizierter US-Amerikaner, der keinem Team angehört. Der Rechner, auf dem der Schlüssel gefunden wurde, ist eine Sparc mit Solaris. Der richtige Schlüssel ist 00438EF36FE3FC21, der damit verschlüsselte Satz lautet "CS-Cipher a ete presente en mars a Fast SoftwareEncryption (PARIS)". Eine Dekodierung der nächsten Schicht wird hoffentlich noch nachgeliefert.
Der Kleinbus-Proxy hat um 07:42 MEZ zuletzt CSC-Blöcke vom Server bekommen. Um 07:50 MEZ kam die Mitteilung vom Masterserver, dass der Wettbewerb beendet ist. Alle entsprechend konfigurierten Clients sollten danach beim nächsten fetch/flush automatisch auf RC5 umgeschaltet haben.
Ich danke allen für die enorme Beteiligung bei diesem Wettbewerb - Platz 20 hätte ich nie erwartet (und es fehlten nur 54 Blöcke für Platz 19). Das Amiga-Team hat Platz 5 (!) erreicht, ebenfalls ein sehr gutes Ergebnis, wenn man sich die Konkurrenten anschaut. Hoffen wir, dass wir auch bei RC5 noch einige Positionen steigen werden.
Der nächste "kleine" Wettbewerb bei distributed.net wird OGR (Optimal Golomb Ruler) sein. Clients gibt's noch nicht, auch noch keinen Starttermin.
Auf dnet.kleinbus.org gibt es wieder aktuelle RC5- und CSC-Statistiken. Alle Daten (vom alten Proxy, vom Ersatzproxy und vom neuen Proxy) wurden zusammengefügt.
Die Statistiken werden aus Performancegründen nur noch stündlich erzeugt, bis das Skript etwas intelligenter ist. Die Update-Zeiten sehen dabei so aus:
Der Ausfall hat bei allen Hosts eine ungefähr um die Hälfte niedrigere Keyrate am 03.01.2000 verursacht. Die Auswirkung auf die Statistik in den folgenden Tagen hängt von der jeweiligen Client- (bzw. Proxy)-Konfiguration ab:
Möglicherweise ist eine (geringe) Anzahl Blöcke noch nicht richtig zugeordnet; insbesondere bei den freenet-Usern ist das nicht so einfach, weswegen ich die beiden vorerst einfach zusammengefasst habe.
Da laut Logfiles inzwischen alle Clients wieder den richtigen Proxy verwenden, habe ich den Ersatzproxy auf freeomp/nato-oliv stillgelegt. In ein paar Tagen werde ich ihn noch einmal für 48 Stunden anschalten, um zu sehen, ob es noch Connect-Versuche von "vergessenen" Clients gibt.
kleinbus.org ist wieder voll funktionsfähig. Neuer Rechner, neues NetBSD, neue Packages, ansonsten alle Daten (Accounts, Homeverzeichnisse, Mail...) wie vorher. Alle Services (Webserver, Mail, DNS) laufen.
Falls irgendetwas fehlen sollte, bitte mitteilen.
Der RC5-Proxy auf dnet.kleinbus.org bzw. 194.77.84.36 ist wieder in Betrieb. Geschaltet sind Port 2064 und 6667, auf Wunsch kann ich auch noch einen weiteren (unbenutzten) Port aktivieren. Bitte nicht soul.kleinbus.org als Keyproxy einstellen, sondern dnet.kleinbus.org. Die IP-Nummer sollte nur in Notfällen verwendet werden.
Der "Abschleppwagen" auf freeomp/nato-oliv wird in ein paar Tagen wieder abgeschaltet. Wer 194.77.84.37, freeomp oder nato-oliv eingetragen hat, sollte das möglichst bald wieder ändern. Die dort gesammelten Logfiles werden natürlich übernommen.
Die Statistikseiten sind noch nicht wieder online. Die alten Statistiken sind alle noch vorhanden, aber die Auswertungssoftware liegt momentan nur in einer älteren Version vor und muss erst noch angepasst werden.
Tobias Walter