Da ich schon fast alle Seiten auf www.distributed.net durchsucht habe, aber kene konkrete Antwort zu dem Thema gefunden habe, dachte ich vielleicht weiß jemand von euch was...
"RC5-72 is being started with a blocksize of 2^32 instead of 2^28. Initially we will only support 1 block per packet, but this will change in subsequent versions. Since each block is larger, it may appear that RC5-72 is much slower if you pay attention to only the amount of time required for each packet."
Möglicherweise könnte doch jemand nen' Block entfernen, und hätte auch eine UNIT/PACKET gerechnet. Wie bitte soll das nachgeprüft werden, wenn der eine ne' kleine und der andere ne GROßE Unit (eine mit mehr Blöcken) berechent?
Außerdem kam mir noch ein Gedanke... es klingt verrück, aber ich habe in den letzten Jahren etwas mit C & C++ gearbeitet. Da ist mir aufgefallen, dass viele "Zufallsberechnungen" letztendlich von Konstanten wie einer Bestimmten Hardware (z.B. Macadresse) oder de gegenwärtigen Systemzeit abhängig sind. Könnte man ein System so modifizieren, dass man den Code schneller knackt, oder läuft die Analyse ausschließlich mit den in der Unit vorhandenen Daten? - Wenn nicht, brüchte man dann nicht seinerseits erst den richtigen Code um des "optimale" System herauszufinden?
Viel Spaß beim Grübeln!
.::TRON::.&-=TmS=-
Bei RC5-64 war es so, dass:
1 Block= 1 WU
1 Packet = 1..8 Blocks
Dieses System wurde eingeführt um Traffic einzusparen, da schnelle Rechner 8 Blocks auch in wenigen Minuten rechnen konten, auf diese Weise nur 1/8 soviel Traffic verursachten.
Da aber die Blocks gewertet wurden, war es für die Stats egal, ob du kleine oder große Packets bekommen hast.
Solltest du es schaffen, Blocks auszulassen und diese trotzdem als gerechnet zum Server zu schicken(nur dann werden sie ja gewertet), ist das nichts anderes als ein neuer Cheatclient und wenn du den schreibst, gibts von mir mächtig Haue.
Um sich die Tatsache mit den Zufallszahlen zunutze zu machen, müssten wir esrt mal wissen, wie den die Zufallszahl für den Schlüssel überhaupt gewonnen wurde. Wir wissen es leider nicht(es könnte auch mit 72 Münzwürfen gemacht worden sein(Kopf =1, Zahl = 0)) deswegen bleibt uns nichts anderes über, als auf gut Glück drauf los rechnen.
Ciao, Florian
Aha!
Sehr informativ - Danke. Ich habe aber sicher nicht vor zu besch***en. Ich liebe Stats, und will jede vom mir berechnete Unit mein Eigen nennen könne. Dazu gehört auch, sie alle berechent zu haben. Abgesehen davon minn ich kein so guter Programmirer, als dass ich den server, der die Units auswertet betrügen könnte. dazu müsste ich zwar auch wieder zufällige ergebnissse generieren, aber auf dauer würden Inkonsistenzen entstehen, die mich dann verraten würden. (Timestamp) Deshalb lass ich das!
Was den Zufall angeht... da hast du Recht! Es ist wohl wirklich nicht möglich. Da Beispiel mit den Münzen find ich gut. :-) Dennoch muss ich sagen, dass es außer de Bruteforce-Methode (welche wir hier zweifelsohne anwenden - alle keys mal probieren) noch andere Möglichkeiten zur schnelleren Erfassung / Auswertung des richtigen Keys gäbe. Ein gezielter Angriff auf den distri.net-Server... [Ah ja... lasst mich träumen... LOL]
Happy Crackin' an alle!
Gruß vom (fast)Team!
Ein Angriff auf den Distri-Server dürfte nicht viel nützen. du musst es wohl eher hier versuchen:
http://www.rsasecurity.com/rsalabs/node.asp?id=2091
Es gibt mit Sicherheit noch weitere mathematische Angriffsmethoden, die aber wohl rechenaufwendiger wären, als eine Brute-Force-Attacke.
Hmmmmm......
Das ist jetzt Spekulation - wie auch immer. Ich wäre dazu zumindest nicht in der Lage/will dazu nicht in der Lage sein!
Ich liebe Stats und mag den Contest, deshalb mache ich hier mit. Außerdem finde ich das hier um Längen sinnvoller als irgendein Seti@home Dingsdabums-Projekt! Das einzige was diesem noch das Wasser reichen könnte wäre dieses Krebsforschungsprojekt (habe leider Namen und Location vergessen).
Wie auch immer...
Happy Crackin'!
Du meinst warscheinlich Folding@home! Hast aber Recht RC5 macht einfach derbst Laune...
Meine Meinung zum Krebsforschungsprojekt:
Man rechnet Jahre, um endlich ein Gegenmittel für Krebs zu finden.
Dann vermarkten es die grossen Pharma-Konzerne und streichen das
große Geld ein. Wenn es Ihnen wirklich wichtig wäre würden sie selber rechnen!
Ja, das mir dem Geld einstreichen sehe ich genauso! :-(
ausserdem sei mal dahin gestellt ob die wirklich was gegen krebs finden bzw. ob se das überhaupt berechnen da kann ich mir nämlich nicht wirklich vorstellen....
Das sehe ich genauso! Gut das das mal jemand öffentlich sagt!
bei united devices hieß es auch ewigkeiten die suchen gegen aids oder sowas nen heilmittel und was war das ende vom lied...? die haben rechenkraft an firmen verkauft wo es darum ging große projekte zu berechnen... warum soll man sich da auch nen riesen cluster kaufen und hinstellen/betreiben wenn man doch einfach nen dummen user findet ?!
bei distri weiß man wenigstens das es schwachsinnig ist... ;D ::)
:-) Stimmt! Aber sicher nicht schwachsinniger als Seti! *fg*
Nun aber mal was anderes, um meinem "tollen" topic etwas gerecht zu werden.
[..]
Bei Microsoft haben wir keine Definitionen zu diesem oder ähnlichen Problemen gefunden. Wenn jemand auf hardwareecke.de mal was ähnliches erlebt hat, soll er sich bitte melden! - Das könnte der RC5-72 Durchbruch sein. :-)
ähm... dein rechner lief mit 100%iger sicherheit nicht schneller... ich schätze da hat sich irgendein systemtreiber verdreht und dem os nen falsches zeit-takt signal geliefert... (zB falschen ticks/sec - wert). Alle zeitbehafteten Programme (zB winamp, menüs, die sich 0.5 sec einblenden etc) brauchen ja zeitschranken - und laufen daher falsch. das hat nat. nix mit rechnergeschwindigkeit zu tun, sonst würde winamp ja auf jedem rechner die musik anders schnell abspielen... ;)
zu den ideen oben sag ich mal nix und empfehle etwas literatur zum rsa-verfahren... ::)
OK, das kingt überzeugend! (Hätte ich nach 3 Jahren IT auch daruf' kommen sollen!)
Frag mich aber dennoch ob 's nicht auch 'ne Möglichkeit gibt, die Zeitschranke [Restriktion] für den DnetC-Client [Service] zu lockern... Was RSA angeht, das ist aber nicht mein Gebiet :-(
Vielleicht hier noch ein anderer Ansatz:
<<"From my personal experience, OS does contribute significantly to the performance of the client.
I am currently running both Windows 98 SE and Redhat Linux 6.2 on my K6-2/500 system. Under Win98, I get approx. 580K keys; under Linux, I get approx. 860K keys. In both cases, I'm not running anything else. I'm just guessing that Windows start up a lot more "junk".
Another thing I can testify to is how much a GUI does NOT hog CPU. I get about the same performance in Linux regardless of whether I'm in the command-line or in X.">>
Klingt vielversprechender als mortz overclocking Aktionen :-)
...was meint ihr?
Am OS "herumwerkeln"? Oder besser doch den Client verbessern? Hab' gehört der neue Client [> 2.9007-486] soll besser mit AMD CPUs zurechtkommen.
Zitat von: .::TRON::. am 12. Juli 2004, 17:28:03 Uhr
Hab' gehöt der neue Client [> 2.9007-486] soll besser mit AMD CPU's zurechtkommen.
.::TRON::.
Der 486 ist ja schon ein wenig älter. Mit dem 489 (wird aber nicht mehr zum Download angeboten) gab es eine Steigerung von ca. 16-18 %. Aktuell ist der v2.9008.490. Den kannst Du hier downloaden: http://www.distributed.net/download/clients.php
THX!
Den 2.9008-490 hab' ich jetzt. Wie ist das mit dem Buffer-Format? Muss ich im 2.9007-486 jetzt erst alle Packets senden? Kann ich die .ini direkt übernehmen? Bringt auch der 2.9008-490 die ersehnter 16-18%? - Wieso wird nicht allen empfohlen, sofort den neuen Client zu benutzen, da das crunchen mit Intel CPUs ja eh etwas doof ist, und fast jeder AMD Prozessoren verwendet.
Danke für die schnelle Antwort ( ich war fast geschockt :-) )
Zitat von: .::TRON::. am 12. Juli 2004, 18:03:54 Uhr
THX!
Den 2.9008-490 hab' ich jetzt. Wie ist das mit dem Buffer-Format? Muss ich im 2.9007-486 jetzt erst alle Packests senden? Kann ich die .ini direckt übernehmen? Bringt auch der 2.9008-490 die ersehneter 16-18%?
Du kannst normal weiter rechnen und brauchst auch nicht unbedingt vorher flushen.
Die Leistungssteigerung hat auch der 490.
In der dnetc.ini solltest Du den [misc]-Eintrag folgendermaßen abändern:
[misc]
project-priority=RC5-72,OGR=0,OGR-P2=0Zitieren
Wieso wird nicht allen empfohlen, sofort den neuen Client zu benutzen, da das crunchen mit Intel CPU's ja eh etwas doof ist, und fast jeder AMD Prozessoren verwendet.
Das haben wir ja schon Anfang März gemacht. ::)
Neue Cores (http://www.hwe-forum.de/index.php/topic,4320.0)
Ich weiß garnicht wo Du den 486 noch aufgetrieben hast. ???
Krass!
Vielen vielen vielen Dank für die wirklich nützlichen Informationen :D
Jetzt kann ich endlich mit mehr Keys generieren! - Den alten 2.9007-486 habe ich von www.rc5team.de/anleitung. Da kann man den unter Punkt eins oder so herunterlaufen. Das war jetzt vor ca. 30T. :( Wenn ich das mal gewusst hätte... Tja manchmal muss man erst einen eigenen Thread öffnen, um zur "Erkenntnis" zu gelangen!
Zitat von: .::TRON::. am 12. Juli 2004, 17:28:03 Uhr
... was meint Ihr?
Am OS rumwerkeln? Oder besser doch den Client verbessern?
Hab' gehöt der neue Client [> 2.9007-486] soll besser mit AMD CPU's zurechtkommen.
hmm, also das OS ist ziemlich wurscht... Ob du nun Win2k, XP oder ein Linux nimmst, die Performance ist quasi gleich...
Ja und Client verbessern... an den Assembler-Cores wird immer irgendwie rumgedoktort... ist nur nicht so einfach nachzuweisen, dass der algorithmus trotzdem noch korrekt läuft dann... ;) daher die langen entwicklungszyklen dort...
zum link auf www.rc5team.de/?start=howto - da kann ich nat. nur auf die seite mit den fertigen clients verlinken und nicht einfach so auf die prerelease-seite. denn dort steht jetzt zB gar kein win32-client... von daher geht's leider nicht anders. das ist dann sache der rc5-foren, auf neue clients aufmerksam zu machen... und das klappt auch eigentlich ganz gut...
übrigens haben auch die Pentium4- User durch den neuen Client nen Leistungsschub bekommen...
Tag Gudi!
So so... Du bist also ein Verantwortlicher? - Hm... Deine Erklärung klingt einleuchtend. Aber ich verstehe dennoch nicht, wie ich vor 30Tagen noch an 'nen v2.9007-486 gekommen bin, wo doch im April diesen Jahres schon der ...008-490 vorgestellt wurde. Naja was solls...
Das mit dem Leistungsschub kann ich bestätigen! Nun habe ich ca. 16% mehr. Mein Bruder greift auf 'nen "Old P4" (1,5 Ghz) zurück. bei ihm sind es komischerweise 20% - komische Analogie. :)
Was das mit dem OS angeht... ich hab mich da 'n bissel schlau gemacht und gehört, das mit Linux oft bessere Ergebnisse erzielt werden, da das nervige GUI von Windows (welches ja so fehlerhaft ist) entfällt. Was meinst Du dazu?
Interessieren würde mich vielleicht noch, was es mit dem "Client as a Service" (PARM -install) auf sich hat. Bringt das Vorteile mit sich? Würde das bei meinen Teammates, die z.T. kein NT (NT4, NT4.5 also 2000, NT5.1 also XP) verwenden auch funktionieren?
Zum Schluss noch: Wieso ist es nicht so einfach nachzuweisen, dass der Algorithmus nach einer Core-Verbesserung oder -Implementierung noch richtig läuft? Man kann doch ein kleines RC5-(x<64) Projekt durchlaufen lassen, und sehen ob das gewünschte Paket gefunden wird, oder ob die Cruncher Mist bauen, und das ganze Projekt (also alle Units) erneut gerechnet werden müssen. Oder noch einfacher: Ich schicke eine preparierte Unit in den neuen, verbesserten Client, die nach Fertigstellung ein bestimmtes Ereignis (je nach Fertigstellungszustand) auslösen soll. Das kann ja nicht so kompliziert sein. Oder was meinst Du worin das Problem besteht?
Liebe Grüße!
warum du den alten client runtergeladen hast? ich schätze mal, du hast den installer runtergeladen, nicht das zip-file. oft hänt der installer etwas hinterher und enthält noch ne ältere version... siehe auch die release-dates auf der seite.
zum os: das is immer alles hörensagen, dass der client hier oder da schneller läuft. meines erachtens entweder meßungenauigkeiten oder (bei den größeren schwankungen) falsche einstellungen oder komische rahmenbedingungen. unter dos isses zB nicht viel schneller oder langsamer als unter linux... klar, wenn du win9x nimmst, wird's bestimmt ein bissel ekeliger sein... ist halt ein altes os mit nem (schon damals) out-of-date multitasking. das ist so ziemlich auch die gängige erfahrung, die die leute im ghn so gemacht haben im laufe der zeit...
mit dem client als service hat's nur aufsich, dass der client automatisch gestartet wird, wenn das system bootet. dh zB bei winNT, dass der client auch läuft, wenn sich noch niemand eingeloggt hat. das geht auch unter win9x. und der client läuft unsichtbar, ist also nicht im tray zu sehen.
zur verifikation des algorithmus. also in der theoretischen informatik ist die "programmkorrektheit" schonmal ein unendscheidbares problem... ;). das ist in der praxis auch meist zutreffend. wenn ein programm auf x eingaben ein fehlerfreies ergebnis liefert, heißt das ja noch lange nicht, dass auch das x+1 'ste ergebnis richtig ist. dh jemand muß den programmcode (prozessorspezifischer assamblercode an der stelle) per mit zettel und stift durchgehen und verifizieren. gerade bei komplexen asm-anweisungen ist das nicht so leicht... nat. gibt es vorher auch testpatterns, aber wie gesagt ist das keine 100%ige aussage. ein kleineres projekt würde keinen sinn machen, da die cores speziell für rc5-72 geschrieben sind.
Aha... das klingt logisch. Ich habe tatsächlich den Installer heruntergeladen. - Wieso frag' ich mich mittlerweile auch...
Was mich zu den Betriebssystemen noch interessiert ist, ob da ein großer Unterschied zwischen Win9x und DOS (Denk' nicht, dass ich Win9x verwende ;) ) besteht. Klar könnte ich das selber testen (hab' ich auch vor...), aber ich hätte gerne ein paar Erfahrungswerte.
Was das mit dem "o-o-d Multitasking" angeht, da stimme ich vollkommen zu... gut das das mal jemand genauso sieht!
Das der Client als Service schon vor der Anmeldung läuft, ist mir bekannt, ich bin mit der Begrifflichkeit "Service" sehr gut vertraut. Auch programmiere ich... Meine Frage hat 'nen ganz anderen Hintergrund (Sorry ich habe im letzten Posting zu unkonkret gefragt!) Aber die Anspielung auf den "Service" darf ruhig in Verbindung mit der Überschrift dieses Threads gebracht werden. Mit anderen Worten... bringt der Service Geschwindigkeitsvorteile? (Ich möchte es nicht ausprobieren, da ich "-uninstall" nicht traue...) Oder ist mein Misstrauen unbegründet? Wenn es Fehler erzeugt, habe ich die gleich auf mehreren Maschinen. :(
Zum Algorithmus... klar das dasx+1-te nicht korrekt sein muss. Ich finde aber, das das Beispiel nicht konkret genug ist. Naja vielleicht stecke ich meine Nase auch in Dinge, in die ich sie nicht stecken sollte... Zumindest denke ich das das Zettel+Stift Denkmodell sicher 'ne Berechtigung hat, aber doch etwas zu theoretisch für ein, bereits seit vielen Versionen existierendes, Programm ist. Sicherlich weiß ich nicht genau, was an den bestehenden Cores geändert wurde. zumindest aber die neuen müssten sich doch analog zu den alten verhalten, oder?
Was das mit dem kleineren Projekt angeht... was heißt ein kleineres Projekt bringt nichts? Der Keyspace verändert sich, viele Variablen und konstanten haben andere Werte, aber die Funktionen sind doch immer noch die selben, oder würde das im Programm zu viele Anpassungen verlangen? Ist das zu aufwendig?
-uninstall geht ohne porbs....
und eure sorgen möchte ich auch mal haben ;D
mfg
jo, -install und -uninstall machen eigentlich nur den nötigen registry eintrag, mehr nicht.
ja, zum algorithmus. warum ist das beispiel nicht konkret genug? hmm. also es gibt im client (wenn du dir die sourcen runterlädst) ne eingebaute anzahl an testpatterns (ich glaub so bei 20 rum? weiß nicht genau), die den core dann halt schon mal vortesten. läuft da alles glatt, kann der core submitted werden zu distri, dort wird er dann _per hand_ überprüft. ebend genau deshalb, weil sich die korrektheit durch "einfach ausprobieren" nicht beweisen lässt. ja, und am anfang steht ein core, der in c geschrieben ist. da kann man dann noch ziemlich gut sehen, dass der korrekt ist. die weiteren cores werden dann jedoch direkt in asm geschrieben, speziell für gewisse prozessoren. ich weiß nicht, ob du sowas schon mal gesehen hast... aber leg ruhig mal den core vom p4 neben den core vom amd athlon. da siehst du nicht viele parallelen. schlimmer noch beim core für die g4/g5 mac's. der algorithmus für altivec - einheiten ist nicht wirkich simpel... neben dem zettel und nem stift hat man dann nat. auch nen dickes specs-heft des betreffenden prozessors an der hand. und da rechnest du dann tatsächlich nach, was in welchem register steht.
ja und mit dem kleineren projekt... sobald du mit irgendwelchen shift-operationen irgendwas machst und fest damit rechnest, dass deine nutzdaten nun 72 bit lang sind, kannst du da nicht mehr viel mit irgendwelchen umgebungsvariablen ändern... die cores sind da zu sehr optimiert auf das spezielle problem. übrigens wäre es auch nix anderes als x richtige ergebnisse zu rechnen und dann hoffen, dass x+1 auch richtig ist... ;)
Hmmm... klingt interessant!
Ich werde das mal überprüfen. Mit 'c' komme ich ganz gut zurecht. Assembler habe ich nur ein Jahr unterrichtet bekommen - mal sehn ob ich da was verstehe.
Danke für die interessante Antwort!!! :)
Also ich find da keine cores, oder irgendwas, was für mich interessant wäre!
Habe mir [http://www1.distributed.net/source/] angeschaut. Dann [http://www1.distributed.net/source/specs/opcodeauth.html] durchgelesen.
Später bin ich auf [http://cvs.distributed.net/viewcvs.cgi/], wo Fetch/Flush das einzig interessante zu sehn scheint!
Dann bin ich noch hier hin [ftp://ftp.distributed.net/pub/dcti/source/archives/], wobei dich das auf [http://www1.distributed.net/source/] mit dem Teil "Hier ist der Quellcode zu ein paar der anderen, schon veröffentlichten distributed.net-Programmen:" zu beziehen scheint.
Wo sind den nun die Kerne, die ich verbessern muss? O0
.::TRON::.
http://http.distributed.net/pub/dcti/source/pub-20040528.tar.gz runterladen und entpacken,
dann im verzeichnis client\rc5-72\x86 zB für AMD der derzeit beste core: r72-go2.asm
viel spass. ;)
Cool - Danke!
Mal 'ne andere unqualifizierte Frage, wiso existiert die selbe Seite unter http://ghn.ath.cx/ und http://teamproxy.dyns.net/?
Liegt es daran, dass die 2Proxies haben, und eben die gleiche seite unter beiden Addressen erreichbar sein soll?
TXH!
damit erreichst du jeweils den gleichen server. die beiden urls sind aus fallback-gründen da. dh wenn ein dyn-dns dienst mal ausfällt, springt halt der andere ein (der client probiert dann halt den nächsten).
OK... hatte ich mir fast gedacht! Danke!
PS: Wieso ist bei den Clients defaultmäßig ein holländischer Server eingestellt? - Hab' ich da was verpasst? Das schreit doch geradezu nach Protest! >:D
.::TRON::.
Zitat von: .::TRON::. am 14. Juli 2004, 22:44:59 Uhr
PS: Wiso ist bei den Clients defaultmäßig ein holländischer Server eingestellt? - Hab' ich da was vepasst?
Das schreit doch geradezu nach Protest! >:D
Ganz einfach, in Holland steht nunmal ein Server von Distri. Und das ist wohl der für uns "am günstigsten" stehende Server.
Hat nix damit zu tun, das wir den Käsköppen irgendwelche WU schenken oder so.
:D Nein das hatte ich auch nicht vermutet - wäre ja auch zu schön!
Mal 'ne Frege wie schnell ist eigentlich ein Cray X1 Supercomputer? 10TFlops?
Mir wurde ein alter C1 (160MFlops) zum Verkauf angeboten. Ist das ernst zu nehmen? Das Ding ist von 1977 und so lahm wie 'n PC mit 233Mhz P2 CPU! - Antwortet doch mal!
ich glaub bei rc5 kannste damit nix reißen... ist ja nichts optimiert. wenn's überhaupt nen client dafür gibt... ::)
Zitat von: Gudi am 18. Juli 2004, 14:54:49 Uhr
ich glaub bei rc5 kannste damit nix reißen... ist ja nichts optimiert. wenn's überhaupt nen client dafür gibt... ::)
Hmmm.... ja hast wohl recht. - Hätte ich auch bedenkem müssen! ::)
Abgesehen davon gilt das Angebot eh' nicht mehr. Wahr wohl aber auch eher ein Fake. :(
Trotzdem Danke!
Zitat von: Gudi am 14. Juli 2004, 16:58:42 Uhr
http://http.distributed.net/pub/dcti/source/pub-20040528.tar.gz runterladen und entpacken,
dann im verzeichnis client\rc5-72\x86 zB für AMD der derzeit beste core: r72-go2.asm
viel Spaß. ;)
Hab' mir übrigens den Assembler-Code mal angeschaut. Ist recht komplex. Wobei eher der Anfang der Datei. Das letzte Drittel geht. Wie ich das sehe 20+x mal Links u. Rechtsschieben oder so. Dann "verXORt" und Shifting. Ich denke da kann ich nichts machen. Ich habe es aber an einige Informatiker weitergegeben. - Die meinen auch dass sie da nicht wirklich viel optimieren können.
Einer von Ihnen meinte aber, dass er mal überprüfen will ob der ASM-Kern SSE kompatibel wäre. Dann könnte man ein und dieselbe Operation in der gleichen Zeit zweimal durchführen, d.h. unter Umständen 2 Units parallel bearbeiten. Mal sehen...
die "2" in dem core-namen GO-2 steht übrigens dafür, dass zwei pipes gleichzeitig laufen... ist übrigens int/mmx - code.
Aha.
Hab' das ASM File jetzt zur Analyse geschickt... ware auf Antwort.
PS: Ich gebe die Suche nach Möglichkeiten in diesem "Teuflischen Forum" (666) auch weiterhin nicht auf! ;D
Zitat von: .::TRON::. am 20. Juli 2004, 18:08:09 Uhr
Hab' das ASM File jetzt zur Analyse geschickt...
alles klar... ::)
Antwort kam promt: (Michael S. (Informatinstechniker))
"Nach Kurzanalyse: Also die GO-2 Pipe nutzt MMX und macht immer 2 Berechnungen gleichzeitig. Die MA-4 Pipe nutzt bereits SSE und macht immer 4(!) Berechnungen gleichzeitig. Hmmm... gut aber der steht für mich doch nicht zur Auswahl...!? :-\"
Wenn du das Projekt richtig beschleunigen willst, lernst du mit FPGAs um zugehen und bastelst eine Hardwarelösung. Wenn das gut designt ist, müsste die Lösung jeden Takt ein Ergebnis ausspucken und du kannst die Dinger bei 100 MHz takten. Ich wollte mich schon länger mal damit beschäftigen, habe aber momentan sehr viel um die Ohren. Wenn ich mal richtig viel Zeit habe, versuche ich mich vielleicht daran.
Alternativ wäre es noch eine Möglichkeit, massiv parallelgeschaltet viele Mikroprozessoren zu verwenden. Eine grobe Abschätzung von mir hat ergeben, dass die Anschaffungskosten für sowas wohl etwas höher sind, als für einen PC gleicher RC5-Rechenleistung, der Stromverbrauch aber um Größenordnungen kleiner wäre.
Von September bis Februar geht es bei mir wieder etwas geruhsamer zu, mal schauen, was sich dann so ergibt...
OK!
Dann werde ich mir das mal vormerken! ;) Ich leite Deinen Beitrag mal weiter... mal schauen was die Anderen dazu beisteuern können!
Greez!
Zitat von: .::TRON::. am 20. Juli 2004, 23:05:18 Uhr
Antwort kam promt:
Michael S. (Informatinstechniker)
"Nach kurzanalyse: Also der r72-go2 Core nutzt MMX und macht immer 2 Berechnungen gleichzeitig. Der r72-ma4 Core nutzt bereits SSE und macht immer 4 (!!!) Berechnungen gleichzeitig. Probier doch den mal, ob der nicht schneller ist..."
>>> Hmmm... gut aber der steht für mich doch nicht zur Auswahl...!? :-\ <<<
der ma4-core ist für die intel p4... ein athlon ist damit ca 30% langsamer als mit dem go-2. weiß auch gar nicht, ob der überhaupt richtig approved ist, oder ob der sgp-3 core trotzdem schneller ist...
Zitat von: Flocki am 21. Juli 2004, 00:27:15 Uhr
Wenn du das Projekt richtig beschleunigen willst, lernst du mit FPGAs um zugehen und bastelst eine Hardwarelösung. Wenn das gut designt ist, müsste die Lösung jeden Takt ein Ergebnis ausspucken und du kannst die Dinger bei 100 MHz takten. Ich wollte mich schon länger mal damit beschäftigen, habe aber momentan sehr viel um die Ohren. Wenn ich mal richtig viel Zeit habe, versuche ich mich vielleicht daran.
Alternativ wäre es noch eine Möglichkeit, massiv parallelgeschaltet viele Mikroprozessoren zu verwenden. Eine grobe Abschätzung von mir hat ergeben, dass die Anschaffungskosten für sowas wohl etwas höher sind, als für einen PC gleicher RC5-Rechenleistung, der Stromverbrauch aber um Größenordnungen kleiner wäre.
Von September bis Februar geht es bei mir wieder etwas geruhsamer zu, mal schauen, was sich dann so ergibt...
gibt dazu gerade in der RC5 mailing ist ein bisserl diskussion... denken aber alle eher an ASICs (in Hardware) und nicht FPGA, wenn ich das richtig ueberflogen habe.
Hallo!
Vielen Dank für den Hinweis auf die Hardware-Mailinglist, die kannte ich bis jetzt noch gar nicht.
Das Problem mit ASICs ist halt, dass die Fertigung erst ab ca. 50000 rentabel und auch dann noch sehr teuer ist. Außerdem dürfte die Entwicklungszeit wohl wesentlich höher sein.
Dafür gibt es natürlich viele nicht zu unterschätzende Vorteile.
Florian
Welche? - Redundanz? - Oder bin ich jetzt völlig falsch? :-\
Zitat von: .::TRON::. am 22. Juli 2004, 01:01:18 Uhr
Welche? - Redundanz? - Oder bin ich jetzt völlig falsch? :-\
Nein, ASIC kann man erheblich schneller takten. Ausserdem kann es sein, dass auch ein grosses FPGA nicht genug "gates" hat um den algorithmus als pipeline zu implementieren. Ausserdem wuerde ein ASIC hoechswahrscheinlich weniger strom verbrauchen und auch noch kleiner sein.
Aha!
Wie kann ich euch dabei supporten?
Hab' da was gefunden:
Versuche diesen Thread zu aktualisieren... ;)
BroadbandsPeport! (http://www.broadbandreports.com/forum/remark,12320592)
*kurz überflogen hab* - da steht bullshit. ::)
Hmmmmmmmmmmm....hab aber was anderes gefunden - in Bezug auf die Parallelität.
ZitierenIn my experience, the Distributed.net project is the only other one that fine-tuned assembley coded their work - and I don't think they've done that *yet* on the current RC5-72 project clients.
I do miss the days that the K5 was *the* most efficient RC5 cruncher per Mhz - first along came the Athlon, which barely edged it out, then the P-III got fine-tuned and ran almost as well as the Athlon, then the G4 Altivec core showed up and that AltiVec client blew EVERYTHING else out of the water - though my K5 PR166s were STILL faster (at 117.5 actual Mhz) than MMX Pentiums up to 166, and very close to the 200Mhz MMX Pentiums even after the "MMX" core showed up....
I'd be curious to see how a ClearSpeed client would do - RC5 uses a lot of 32-bit integer operations, and CAN be easily paralellised (have each "core" work on a seperate key at the same time, similar to how the EFF dedicated DES cracker machine worked)....
Klingt interessant, aber war das Parallele Verarbeiten nicht immer ein Verlustgeschäft!?
Ob ich mit einem Prozessor 8 WUs gleichzeitig rechne oder hintereinander, daß dürfte egal sein.
Das ist nur interessant, wenn du wirklich mehrere Prozessoren hast, und dann rechnet der Client
automatisch parallel mit jedem Prozessor an einer WU, es sei denn du sagst ihm er soll es nicht tun.
[Edit]
Habe nochmal ein bischen gerechnet.
RC5-72 heißt ja 72-Bit-Verschlüsselung, also 272 Schlüssel, bzw. da in jeder WU 232 Schlüssel sind
240 WUs.
272 = 4.722.366.482.869.645.213.696 Schlüssel
Aktuelle Keyrate ist ca. 200 GigaKeys/sec.
Daraus folgt, daß wir bei dieser Keyrate noch ca. 23611832414 Sekunden bzw. ca. 750 Jahre brauchen werden
um alle Möglichkeiten durchzuprobieren.
Da ist es reichlich egal ob dein Rechner 5% schneller ist.
damit ist eine parallele verarbeitung über die mmx / sse-register gemeint. dafür ist das schließlich da. und das wird auch schon länger gemacht, sowohl bei den intel-cores als auch beim amd-core. das bedeutet aber nicht, dass ganze WUs parallel verarbeitet werden (dafür reichts nicht aus), sondern nur, dass gewisse teile im algorithmus parallel gemacht werden können (zB bei matrix-multiplikationen, die im algorithmus öfters mal vorkommen - da kann man dann zB 4 int-werte auf einmal addieren/multiplizieren).
Zitat von: Spider-Mann am 24. Januar 2005, 21:39:15 Uhr
Ob ich mit einem Prozessor 8 WUs gleichzeitig rechne oder hintereinander, daß dürfte egal sein.
durch die vermehrten thread- oder gar prozesswechsel (und das damit verbundene sichern von registern/stack) geht schon zeit verloren, die auf dauer schon bemerkbar sind.