Slashdot Mirror

X86/Win32 -- 73%
X86/Linux -- 11%
PowerPC/Mac OS X -- 11%

The remaining 5% is divided among dozens of other combinations.
http://stats.distributed.net/misc/platformlist.php ?project_id=8&view=tco

I have to note that the PowerPC client for distributed.net is very good, a single 1.2 GHz G4 performs on par with a dual 2.4 GHz P4. So, these statistics suggest that ~5.5% of the CPUs is running Mac OS X.

Distributed.net actually has project running attempting to do this. So far they have brute forced keys up to 64bits in length. However breaking 64bit key took 1757 days, and at there current pace it could take over 900 years to break the 72bit key. So the bottom line is that if this guy is using a key of any size it's not going to be possible.

Restore from backup and hope they catch the jerk.

Distributed.Net always shows me what happens to a PC permanently at 100% CPU load. Had to remove it from the student labs because it caused all the Dells to turn their fans up full. The noise! There are ports for pretty much everything.

How about Project Bovine?

But 64 bit was cracked by distributed.net a few years ago.

Wow... holy crap are you right!! Just check this out!! (RC5-72 Client speed comparison):
CPU Name Mhz Client Speed
AMD Athlon64 1600 5,771,251.00
AMD Athlon64 3200 8,159,513.29
AMD Athlon64 4100 10,818,609.00


PowerPC 744x/745x G4 550 5,708,033.00
PowerPC 744x/745x G4 933 9,813,326.00

Wow, those G4s get pawned!!
Oh wait.. there's more!
PowerPC 744x/745x G4 1333 13,918,160.25
PowerPC 744x/745x G4 1500 15,952,849.00


More still!!
PowerPC 970 G5 1600 8,360,235.00
PowerPC 970 G5 2500 18,833,424.00

they claim they've reduced the complexity from O(q^{1/2}) down to O(q^{1/4}) ... In practical terms most serious ECC implementations are using q in the order of 2^200 or more

Say you're using a 200-bit ECC key. Now your 2^100-step brute-force is down to a 2^50-step brute-force. Six years (four Moore doublings) ago, EFF and distributed.net brute-forced another cipher's 56-bit key in under 24 hours.

... QWest announced to have solved their IT problems. Delayed phone connection times had appeared already in 1998, when the company was called US West.

What ever happened to distributed.net?

Distributed.net has this to say on overclocking.

distributed.net is where all the smart CPU cycles have gone! :)

I think they should use the distributed.net client for benchamarking. maybe they can take a few decades off of the RC5-72 challenge, or finish up OGR. :)

Oh yes, and the G4 used (7447) has an Altivec unit which - when used properly - beat the crap out of any x86.

RC5-72 for example:

PowerPC 7447 @ 1,25GHz 13,336,584 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=rc572&multi=0

VIA "Nehemiah" @ 1,0GHz 1,195,287 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=rc572&multi= 0

Or OGR:

PowerPC 7447 @ 1,25GHz 30,108,694 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=ogr&multi=0

VIA "Nehemiah" @ 1,0GHz 3,440,749 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=ogr&multi=0

Now, which is more useful, an AES encryption instruction, or an generic vector engine that can be used for virtually unlimited variety of tasks?

Oh yes, and the G4 used (7447) has an Altivec unit which - when used properly - beat the crap out of any x86.

RC5-72 for example:

PowerPC 7447 @ 1,25GHz 13,336,584 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=rc572&multi=0

VIA "Nehemiah" @ 1,0GHz 1,195,287 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=rc572&multi= 0

Or OGR:

PowerPC 7447 @ 1,25GHz 30,108,694 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=ogr&multi=0

VIA "Nehemiah" @ 1,0GHz 3,440,749 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=ogr&multi=0

Now, which is more useful, an AES encryption instruction, or an generic vector engine that can be used for virtually unlimited variety of tasks?

Oh yes, and the G4 used (7447) has an Altivec unit which - when used properly - beat the crap out of any x86.

RC5-72 for example:

PowerPC 7447 @ 1,25GHz 13,336,584 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=rc572&multi=0

VIA "Nehemiah" @ 1,0GHz 1,195,287 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=rc572&multi= 0

Or OGR:

PowerPC 7447 @ 1,25GHz 30,108,694 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=ogr&multi=0

VIA "Nehemiah" @ 1,0GHz 3,440,749 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=ogr&multi=0

Now, which is more useful, an AES encryption instruction, or an generic vector engine that can be used for virtually unlimited variety of tasks?

Oh yes, and the G4 used (7447) has an Altivec unit which - when used properly - beat the crap out of any x86.

RC5-72 for example:

PowerPC 7447 @ 1,25GHz 13,336,584 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=rc572&multi=0

VIA "Nehemiah" @ 1,0GHz 1,195,287 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=rc572&multi= 0

Or OGR:

PowerPC 7447 @ 1,25GHz 30,108,694 http://n0cgi.distributed.net/speed/query.php?cputy pe=99&cpumhz=1250&recordid=1&contest=ogr&multi=0

VIA "Nehemiah" @ 1,0GHz 3,440,749 http://n0cgi.distributed.net/speed/query.php?cputy pe=126&cpumhz=1000&recordid=1&contest=ogr&multi=0

Now, which is more useful, an AES encryption instruction, or an generic vector engine that can be used for virtually unlimited variety of tasks?

First, Moore's law is not a law, but an observation.

So are the laws of thermodynamics. And, more generally, there are no laws (of physics) that would not be based on observation, either directly or indirectly. Please understand, a "law" in this sense simply means a mathematical correlation between variables.

Moore's law would be something like "cp = cp0 * 2^(t1/t)", where "cp" stands for computing power, "cp0" stands for computing power at the beginning of the observation period, "t" stands for the time it takes for computing power to double, and "t1" stands for the length of the observation period.

Since it can be mathematically formulated, Moore's law is indeed a law; whether it will hold or not is a different matter.

It's unlikely to hold for long, as CPUs run into limitations like the speed of light (currently a problem already).

This particular problem (trying all possible keys) is completely parallel; that is, each key can be tried in parallel, independent of any other key. This means that the problem is especially suitable for multi-core processors (which seems to be the trend currently). You could even distribute the problem accross several computers - see http://distributed.net/ for an example.

And in any case, we haven't really even begun to examine some possible solutions to the limited signal speed problem - such as multilayered chips (if you can make a fully 3-dimensional chip, as opposed to current 2-dimensional ones, you can increase the amount of transistors inside a given distance from a given transistor exponentially).

Depends on what you want to do. If you run RC5-72 (for fun or for profit, or because you are TLA), a cluster of Mac Minis probably can't be beat, not even by a dual G5.

http://www.distributed.net/ Been around forever, have done far more impressive work than Big Blue . . . and I think they've had Linux clients for a little while.

So the burden of creating and testing other platforms lies with the makers of the grid software, in IBM's case this is United Devices (incidentally, I work for United Devices). And since the ROI on a non-window client is just very low (there are only few non-windows machines possibly joining these types of grid vs. the enormous costs of testing the correct working of such a client), there will not be any non-windows client anytime soon. Do not forget it's not just the client that has to work, the actual task module that does the work (the Human Genome program) also needs to be available on other platforms

There's also a commercial product that United Devices sells (see its product page), which is based on the same codebase that runs the World Community Grid and also grid.org and cellcomputing.jp, and this product has a windows, linux, aix, solaris and macosx client.

Disclaimer: my views are my personal ones and not necessarily endorsed by my company!

Rest assured that unless some one finds a mathematical back door that the algorithms approaching 1024bits will not be the weakest link in the security of your data (at least with hardware today). Just have a look at the key space in Distributed's RC5-72 vs. RC5-64. The key space for RC5-72 is astronomically higher than RC5-64.

Usually, the weakest link will be the user using short keys or the user using the same password on a weaker system.

Rest assured that unless some one finds a mathematical back door that the algorithms approaching 1024bits will not be the weakest link in the security of your data (at least with hardware today). Just have a look at the key space in Distributed's RC5-72 vs. RC5-64. The key space for RC5-72 is astronomically higher than RC5-64.

Usually, the weakest link will be the user using short keys or the user using the same password on a weaker system.

Slashdot beat the Amiga team in OGR-24, but the Amiga team is leading the Slashdot team in OGR-25: OGR-25 Team Listing

But the Dutch Power Cows leads in both efforts.

OGR-24 blocks have been scarce for the last few months, so the statistics have been rather erratic.

At least the OGR effort is more useful than the RC5-72 effort. We showed how quick DES and RC5-56 could be broken quickly with a bruce force attack with spare CPU cycles. But why do RC5-72? It's not that interesting.

I'm doing OGR-25 now, and when that's finished I might go on to something like folding @ home, if there's a client.

For OGR, then...
The Opteron 2420 for OGR (uniprocessor) scored 19,106,244.00. (one sample)
The G5 OGR (uniprocessor) page is a bit confusing at first.
It shows a 2GHz G5 scoring 19,204,321.00, but the 1.8 G5 is scoring significantly higher at 24,950,000.00. Another oddity is that the 1.8 G5 samples are showing a really large standard deviation (over 25%!). Time to dig deeper to see what's going on.
Looking at the details for those samples shows the following:

• G5 1.8GHz 2.9008OGRp2 client score of 19,800,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 29,900,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 33,000,000.00.

There are no 2-way 2 GHz Opteron benchmarks for OGR.
A 2-way 2.5GHz G5 turned in an impressive 83,517,872.00.

For OGR, then...
The Opteron 2420 for OGR (uniprocessor) scored 19,106,244.00. (one sample)
The G5 OGR (uniprocessor) page is a bit confusing at first.
It shows a 2GHz G5 scoring 19,204,321.00, but the 1.8 G5 is scoring significantly higher at 24,950,000.00. Another oddity is that the 1.8 G5 samples are showing a really large standard deviation (over 25%!). Time to dig deeper to see what's going on.
Looking at the details for those samples shows the following:

• G5 1.8GHz 2.9008OGRp2 client score of 19,800,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 29,900,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 33,000,000.00.

There are no 2-way 2 GHz Opteron benchmarks for OGR.
A 2-way 2.5GHz G5 turned in an impressive 83,517,872.00.

For OGR, then...
The Opteron 2420 for OGR (uniprocessor) scored 19,106,244.00. (one sample)
The G5 OGR (uniprocessor) page is a bit confusing at first.
It shows a 2GHz G5 scoring 19,204,321.00, but the 1.8 G5 is scoring significantly higher at 24,950,000.00. Another oddity is that the 1.8 G5 samples are showing a really large standard deviation (over 25%!). Time to dig deeper to see what's going on.
Looking at the details for those samples shows the following:

• G5 1.8GHz 2.9008OGRp2 client score of 19,800,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 29,900,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 33,000,000.00.

There are no 2-way 2 GHz Opteron benchmarks for OGR.
A 2-way 2.5GHz G5 turned in an impressive 83,517,872.00.

For OGR, then...
The Opteron 2420 for OGR (uniprocessor) scored 19,106,244.00. (one sample)
The G5 OGR (uniprocessor) page is a bit confusing at first.
It shows a 2GHz G5 scoring 19,204,321.00, but the 1.8 G5 is scoring significantly higher at 24,950,000.00. Another oddity is that the 1.8 G5 samples are showing a really large standard deviation (over 25%!). Time to dig deeper to see what's going on.
Looking at the details for those samples shows the following:

• G5 1.8GHz 2.9008OGRp2 client score of 19,800,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 29,900,000.00.
• G5 1.8GHz 2.9009OGRp2 client score of 33,000,000.00.

There are no 2-way 2 GHz Opteron benchmarks for OGR.
A 2-way 2.5GHz G5 turned in an impressive 83,517,872.00.

From distributed.net's pages, here's what it has to say on the Opterons for RC5-72 (uniprocessor)
The Opteron 2420 achieved a score of 9,547,969.00.

The 2GHz G5 for RC5-72 (uniprocessor) achieved a score of 15,057,412.00 (there are 2.5GHz chips available...) The best multi-cpu scores?
A 2-way 2 GHz Opteron achieved a score of 15,145,274.67, but
a 2-way 2.5GHz G5 smoked it with a score of 37,441,192.00.

Apples to apples, my friend, apples to apples.

From distributed.net's pages, here's what it has to say on the Opterons for RC5-72 (uniprocessor)
The Opteron 2420 achieved a score of 9,547,969.00.

The 2GHz G5 for RC5-72 (uniprocessor) achieved a score of 15,057,412.00 (there are 2.5GHz chips available...) The best multi-cpu scores?
A 2-way 2 GHz Opteron achieved a score of 15,145,274.67, but
a 2-way 2.5GHz G5 smoked it with a score of 37,441,192.00.

Apples to apples, my friend, apples to apples.

From distributed.net's pages, here's what it has to say on the Opterons for RC5-72 (uniprocessor)
The Opteron 2420 achieved a score of 9,547,969.00.

The 2GHz G5 for RC5-72 (uniprocessor) achieved a score of 15,057,412.00 (there are 2.5GHz chips available...) The best multi-cpu scores?
A 2-way 2 GHz Opteron achieved a score of 15,145,274.67, but
a 2-way 2.5GHz G5 smoked it with a score of 37,441,192.00.

Apples to apples, my friend, apples to apples.

From distributed.net's pages, here's what it has to say on the Opterons for RC5-72 (uniprocessor)
The Opteron 2420 achieved a score of 9,547,969.00.

The 2GHz G5 for RC5-72 (uniprocessor) achieved a score of 15,057,412.00 (there are 2.5GHz chips available...) The best multi-cpu scores?
A 2-way 2 GHz Opteron achieved a score of 15,145,274.67, but
a 2-way 2.5GHz G5 smoked it with a score of 37,441,192.00.

Apples to apples, my friend, apples to apples.

Will it make your iPod quit working?

No, iPods do that on their own.

As for your sig...

Why are there only 19 people folding@home for slashdot?

In my case it's because their client is buggy. It would launch and quickly proceed to kill off the actual crunching engine. No worries, now that distributed.net is back to running useful projects (like OGR) I can use them.

Not for text matching, but for numbercrunching.
Numbercrunching as in RC5-72. I think you get the idea...

I'd say that the fastest computers will always be fucking huge. If engineers could somehow magically fit the total power of the Earth Simulator into a single 1u chassis, people would still cluster a few hundred of them together. There's no such thing as enough processing power, as people always find a way to utilize it.

Hmmm ... good point. Sometimes I slip into "Apple Mind" and forget that technology has progressed and think that my workstation is a super computer (referance to the G4 'your own personal supercomputer' ad campaign). No matter how much processing power we can cram into a small space, someone will still stick a bunch of them together and run dnetc on it (:

There are actually quite a few applications like that. This kind of CPU is perfect for distributed computing applications, which use every CPU cycle and thread they can get. Clients based on the new BOINC computing platform, and the distributed.net client, are already set up to take full advantage of this kind of CPU.

Actually, recent studies have shown some minor good news. If you live past your mid-70s or so with no sign of Alzeimers, you probably won't get it. Talk of these diseases want me to run folding@home again. But I'm a dnet man myself...

One final point to note is that Newham will be using Internet Explorer. Steel explained that this is because Microsoft is very serious about addressing security concerns

As if I weren't chuckling a little throughout the article, I almost wet my pants on that line. Sure Microsoft is serious about addressing the security concerns, but there's JUST SO DAMN MANY!!! Finding all those security holes would be a computing task akin to solving RC-72 only difference is, in 300,000 days RC-72 will be solved and MS will probably STILL have security holes in whatever OS is running then.

I like distributed.net but your 100% correct about RC5-72 - its going to be a long long project. I spend my CPU cycles on Seti, OGR, or even the prime number search but not RC5-72.
Aggregate Statistics
Total Blocks to Search: 1,099,511,627,776
Total Blocks Tested: 1,383,407,276
Overall Rate: 27 Blocks/sec
Total Keys to Search: 4,722,366,482,869,646,000,000
Total Keys Tested: 5,941,689,007,468,446,000
Overall Rate: 113,856,868,705 Keys/sec
Percent Complete: 0.126%
Time Working: 604 days

I like distributed.net but your 100% correct about RC5-72 - its going to be a long long project. I spend my CPU cycles on Seti, OGR, or even the prime number search but not RC5-72.
Aggregate Statistics
Total Blocks to Search: 1,099,511,627,776
Total Blocks Tested: 1,383,407,276
Overall Rate: 27 Blocks/sec
Total Keys to Search: 4,722,366,482,869,646,000,000
Total Keys Tested: 5,941,689,007,468,446,000
Overall Rate: 113,856,868,705 Keys/sec
Percent Complete: 0.126%
Time Working: 604 days

... that are used by spammers as well. I thought it might be interesting to do this. I do NOT want somebody putting code on my machine, no matter how 'good'it is for whatever reason.

Next you will have a seta@home worm. A worm that starts running seti@home (or distributed.net or whatever.) The maker can claim that is is for a good cause, just like the makers do for this one.

You could also get pop-ups that tell you that you owe them money, because they protected your PC. So pay, or else ...

That last one could be calld "The Nigerian Virus Protection Plan"

Good question.

I contribute my spare computing cycles to distributed computing efforts.
The distributed.net client, at least, does not require the computer to be switched on 24/7 either.
Even playing DVDs only take up about 25% of the CPU time, and I've had no problems with overheating. I sometimes think about all that A/C power and computer cycles being wasted at the university computer rooms.

Maybe O.S. vendors could include a voluntary option doing install to contribute your computing power. They could then re-sell that computing to users who need to do heavy calculations that are not time-critical or secret.

P.S. IBM is hot on grid computing, but they don't all seem to believe the processing power also can be contributed by individuals.

I'm not a film tech -- but besides abuse and security issues, what's proposed here is just does not seem possible under low bandwidth conditions. it's not like you can just run off to computer #2,398 and say "go render frame 1,503" -- there are textures and models and state information that probably total somewhere on the order of gigabytes (give or take a factor of ten) in order to render that frame. Joe Dialup isn't going to be able to handle that; the film studios I'm sure have crazy fiber/multi-gigabit interconnects within their rendering farms.

If they could find a way to offload some intermediate calculations (like deformations of hair or fabric or something that can be used as an intermediate result in a scene) then that might be a clever use for a distributed.net style technique.

-fren

You'll probably be interested in this page from distributed.net - it has all kinds of statistics that basically say it takes a long time (years) and a lot of computers to break quite feasible encryption right now.

According to the distributed.net speeds page, the rc5-72 rate of an I2 1.4 is about 1Gkey/sec


Itanium 2 speeds

Since a P4M running at the same clock does 3 times as much, it wouldn't be so efficient... though we are talking about the US Gov't.

-Nev

According to the distributed.net speeds page, the rc5-72 rate of an I2 1.4 is about 1Gkey/sec


Itanium 2 speeds

Since a P4M running at the same clock does 3 times as much, it wouldn't be so efficient... though we are talking about the US Gov't.

-Nev

> ...capable of sustaining 50 trillion calculations per second.

Hmm...I wonder if I could borrow it for a few days to give my dnet stats a boost :D

I participate in Distributed.net and if you look at the CPU speeds you'll see that AMD currently has the fastest CPUs for that project. My next processor may be an AMD.

I participate in Distributed.net and if you look at the CPU speeds you'll see that AMD currently has the fastest CPUs for that project. My next processor may be an AMD.

First: considering that this site is supposed to be "News for Nerds" what news did the article provide? At a minimum it generated a forum to request further, more detailed information.

Second: Not unlike countless others, you misread one of my posts. I honestly can't see where I asked for theory. I am looking for how hard it was to solve this problem.

Wasn't that the point of the challenge? To quote the website: "to encourage research into computational number theory and the practical difficulty of factoring large integers."

So, with one of the problems solved, how difficult was it? 100 workstations and 3 months doesn't tell us much. Were all 100 working 100% on their given tasks for the full 3 months? Is it really 3 months, or was that number generously rounded up? How fast are the 100 machines? How do those 100 compare to the same number used to solve a previous value a few years ago? That last one is probably the most important question, because you can't compare between challenges without some honest reference.
And 100 is just an approximation - this announcement is just too vague!

As an example, something similar to this would have satisfied me. Please note that for that project, the delay between the date of submission and their detailed announcement is 1.5 months.

Please put a leash on your hubris.
I do. Perhaps you read frustration, and the expression of it, as arrogance. I've had difficulty finding such details, which is why I asked for assistance on the matter.

Although not quite what I was requesting, thanks for the links. It appears that Google has already provided a couple of them to me in the past. I've found this article to be an excellent primer - provides some history on (and some basics in) the effort of integer factorization. Most importantly it's not nearly as intimidating as the vast majority of publications I've encountered on the subject.

Go to distributed.net and download their client. You can work on factoring RC5-74 (a 74 bit number from RSA). They've just finished up RC5-64 (A 64 bit number from RSA). If your computer finds the key, you get $1,000 and $8,000 goes to charity. They also have other distributed projects, like seti@home, including one to search for mathematical constructs known as Optimal Golumb Rulers. The best part is the client runs at the minimum priority, so you only give up cpu cycles if you don't need them. I've yet to notice any kind of lag because it was running on my machine.