In theory the math works thusly: 40 tables. 8 round functions per table -> 320 candidate chains per keystream segment 64 keystream segments per burst 1 disk access per candidate chain -> 20480 disk accesses per burst 4kbyte per disk access, 80mbyte per burst, 200 seconds with a 10ms HD, 10 seconds with a 500usec SSD.
20480 chains have to be processed in parallel on the GPU, the chain length is 2^15. Half of the chains do not produce a hit in the tables, so their length is 2^14 (which means after the initial chain regeneration there is no need to check the start value from the table, cause you do not find one). A single SIMD engine can produce around 32M A5/1 chain links per second or 1000 chains of size 2^15. The 5830M can thus produce 10k chains per second and needs 1.5 seconds per burst to compute the candidate chains. Lets assume 3 seconds there cause the lookup code is not as efficient as the generation code. So unless you plan to use 5 SSD disks, the 5830M will not be to small. Also, the 5830M is saturated with 81920 chains, which is 4 bursts in parallel, below that it will be just as fast as a 5870 (minus the clock difference) Note this is theoretical, you would implicitly signup as beta tester if you bought some hardware now, but the order of magnitude is accurate. >On Sun, 2010-07-25 at 21:21 +0200, Fabio Pietrosanti (naif) wrote: >> Regarding the computer hardware setup, do you think that may be >> feasible, following your testing environment to use a notebook? >> >> Maybe some notebook, dedicated for gaming, have very strong ATI >> Mobility Radeon HD 5800 series card: >> http://www.amd.com/us/products/notebook/graphics/ati-mobility-hd-5800/Pages/ati-mobility-hd-5800.aspx >> http://www.notebookcheck.net/ATI-Mobility-Radeon-HD-5830.24733.0.html >> > >Cracking is relative light on the GPU - but a decent card will be nice >to keep the latency down, but one needn't go all out on the graphics >card either. > >> Also the disk i/o bottleneck is important, so i just made some >> scouting of some notebook that had other than powerful ATI card and >> multicore CPU also eSATA and USB3 interface. Found this HP Envy 15: >> http://hpfansite.com/hp-envy/hp-2010-envy-15-review-ati-mobility-radeon-5830-core-i7-quad/ >> * 1.73 GHz Intel Core i7 820M quad core processor >> * 8 GB of DDR3 RAM (2 X 4 slots) >> * 1 GB ATI Mobility Radeon 5830 graphics >> * 2 USB ports, USB + eSata, HDMI >> SATA3 have a bandwidth up to 600MB/s, eSATA can do up to 300MB/s with >> USB3 that can reach up 625MB/s: >> http://en.wikipedia.org/wiki/List_of_device_bit_rates >> >> In such condition, which could be the most performance hard drive >> setup for lookup speed? >> >> I am thinking about a possible layout like this: >> - 400GB on internal disk drive >> - 1TB on USB3 external drive (625MB/s maximum) >> - 600GB on eSata external drive (300MB/s maximum) >> >> Does it sounds reasonable for a mobile setup of the airprobe/kraken >> environment. >> I mean which is the disk i/o bandwidth are you currently experiencing >> with the 1.5 minutes timing? >> > >This sounds reasonable, but once you bring a GPU to the party, disk >access time immediately becomes your new bottle neck, up to the point >where decompressing the table and the final bit of search swamps the >CPU. I suspect you need SSD storage, or an insanely fast disk array to >see this happen. > >I have done some tuning on the code, and the time it takes to analyze >one single burst is down to 60~70 seconds, and this is bound by the >slowest disks that only deliver around 60 random reads pr second, while >the faster disk are considerably faster. > >For instance on a laptop, the internal drive is probably slower than >many external drives. This difference in performance can be addressed by >storing fewer tables on the slower disks. > >Another way to get around the speed difference could be to have kraken >accept 4-8 bursts, and process them all in parallel, and when a key is >found the work queue is flushed. In this scenario it is more likely that >the faster disk will manage to find a key before they run out of work. > >In short, one needs to optimize for random reads across 1.7TB* of >storage. IO bandwidth is not that much of an issue, more disks and >faster disks are always better. > >regards, >Frank > > >* Tables were originally computed at 2TB, but through better compression >they only need 1.7TB of storage. > > >_______________________________________________ >A51 mailing list >A51@lists.reflextor.com >http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 ___________________________________________________________ WEB.DE DSL ab 19,99 Euro/Monat. Bis zu 150,- Euro Startguthaben und 50,- Euro Geldprämie inklusive! https://freundschaftswerbung.web.de _______________________________________________ A51 mailing list A51@lists.reflextor.com http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
