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 [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
