Slashdot Mirror

This is total FUD. It is really annoying when mac-o-holics say "oh look, my machine is the fastest because it can do this one calculation really fast". Don't get me wrong, I'm not trolling, I love mac's too but I don't pretend that they are some sort of super computer *cough*jobs*cough*. The real reason why mac's can beat some x86 boxes in the RC5 is right here. Straight from the horses mouth.

I think it's probbably safer to say that seti@home has a huge surplus of computational power, and uses it to verify each result (though it's not strictly necessary to do so). With only one data source (Aerecibo) you can only produce data so quickly, and once you have enough computational power to do the analysis in real time any extra is just surplus that can be used to verify. They did, however later add some extra analysis to the data to take better advantage of the huge surplus of computing power they have.

The important point though, is that for seti@home each individual workunit, while important isn't critical to the whole project. If a small percentage of workunits aren't computed perfectly it's not catastrophic. In other words there's a certain amount of tolerance for innacuracy. For a project like the OGR (Optimum Golomb Ruler) by distributed.net each workunit must be calculated perfectly, as the goal is to prove which ruler is the optimum one. If workunit isn't verified you haven't really proven anything, since it's possible (and probbably likely) that hardware failure produced an innaccurate result somewhere in the millions of workunits calculated. (Or perhaps a modified client produced innacurate results). Other distributed computing tasks have different amounts of tolerance for innacurate results.

Your underlying point is a good one though. For some projects the need for integrity of the results is very high, so larger computing power may be necessary to verify each result.

Distributed.net was around years before SETI@Home.

Nice trolling.

Athlon XP 2400+ beats P4-C 3.0Ghz at General Usage test

Athlon XP beats P4-C at same speed grade at Unreal Tournament 2003

Athlon XP 1700+ beats P4 3.0Ghz at RC5-72 Encryption

In the interest of fairness, Athlon XP gets beatdown by P4 at Lightwave 3D Rendering

As I said, Athlon XPs are generally better at gaming, general usage, and hard math. P4s are generally better at hard 3D rendering and media encoding.

lullabud says:

actually, the current dnetc client does *NOT* have a core that is optimized for altivec, otherwise you'd see numbers that were about 4x faster on the g4. a quick search here will show you how the g4 smoked x86 cpu's in the old rc5-64 client where there *WAS* an altivec optimized core.

for those who don't want to bother clicking: (higher is better)
g4 933 - 9,785,726.5
pIII 933 - 2,624,156.13
Xeon 1000 - 2,828,358
thunderbird 944 - 3,277,590
duron 933 - 3,357,069.5
celeron 946 - 2,688,093
itanium 800 - 339,825
p4 1200 - 1,699,487

i saw somewhere that this was due to a hardware rotate function that the p4 does not have, but anything before does have. the g4 does 4 32bit bit rotates per clock with altivec enhanced code, and rc5 is heavy on bit rotates. if i remember correctly, it takes a p4 4 clock cycles to accomplish what a g4 can do 4 of in one clock cycle, making the g4 16x as fast on that particular instruction.

If they did their stats similar to the stats over at distributed.net I think it would be alot more accurate. And it would also spur competition amongst the piraters. I think it would be cool to see who could pirate the most.

I would make EUR 10,995,116,278 if I cracked RC572. Thats USD 12,988,154,415!

Odd. All the Mac scores must be cheated then.

How about helping with some cool math prime search?

ars Team Prime Rib - cool prime searching stuff.

A mix of misc science stuff.

dc projects - some Opensource, some not.

And all projects at distributed.net come with source too.

Distributed.net

For thouse looking for an alternative, there is always distributed.net.

distributed.net in support of Team Slashdot. Let's crack that RC5-72 so that we can move on to RC5-128! Only 657,374 days (~1800 years) left to go!

distributed.net in support of Team Slashdot. Let's crack that RC5-72 so that we can move on to RC5-128! Only 657,374 days (~1800 years) left to go!

Check out the exciting RC5 schedule and feel free to hammer away!

Hmm, I would have thought RC5 schedule might have linked somewhere else ;).

I'm using the new rc5-72 client and getting about 19 million keys per second on a dual 1.0GHz tower. A cluster of XServes would be awesome at this task.

"Moo" on slashdot is more likely a reference to distributed.net.

But why are you touting slow hard drives with provably weak encryption when the poor crew of the Columbia are not 8 hours dead? NASA has just suffered the worst accident in their history, and all you dorks can talk about is shitty harddrives and other consumer products??? GET SOME PRIORITIES, PEOPLE! You make me sick!

This really old Slashdot logo still in use over on Team Slashdot's page on distributed.net.

"You're anurism operation was a complete success and while that was going on your surgeon discovered the RC5-72 key!"

Distributed.net does not have a native IA-64 client yet. The performance of an x86 client is about that of a 486.

Distributed.net does not have a native IA-64 client yet. The performance of an x86 client is about that of a 486.

How many keys/sec?

How many keys/sec?

You might want to look at some of the RC5 benchmarks sometime if you believe that:

PC speeds

Mac speeds

For the time impaired, here's an example (reformatted by me, using results for your listed machines):

AMD K7 Athlon Thunderbird 1650 MHz Speed = 5,847,268
Power PC 7450/7455 G4 1000 MHz Speed = 10,525,403

You might want to look at some of the RC5 benchmarks sometime if you believe that:

PC speeds

Mac speeds

For the time impaired, here's an example (reformatted by me, using results for your listed machines):

AMD K7 Athlon Thunderbird 1650 MHz Speed = 5,847,268
Power PC 7450/7455 G4 1000 MHz Speed = 10,525,403

-------

Here's the executive summary: CPUs consume more electricity when actively computing than they do when idle. To solve the RC5-72 challenge may require an additional 2 million tons of coal be burned in order to produce the additional electricity required. That's over 200 full coal trains. 9.2 billion pounds of additional carbon dioxide will be produced and released. The details follow.

I sent a letter to my buddies during a discussion of relaunching our team to attack the RC5-72 challenge. It showed a simplistic estimation of the energy costs required for me to participate in the challenge. I know that my CPU uses more energy to perform math calculations than it does to sit idle. It has since occurred to me that not only would I be burning an extra megawatt or two of electricity during the contest to participate, but so would all the other participants.

I've researched things a bit more since then. The distributed.net speed page shows an Athlon 1GHz Thunderbird averaging 3,540,087 keys/sec, or 12,744,313,200 keys/hour during the RC5-64 contest. A hardware vendor's page shows an active Athlon 1GHz Thunderbird CPU consumes an extra 10 watt-hours above its standby level. This is only the difference between an active CPU and an idle CPU, and does not account for any other standby power savings that may or may not take place. That means a 1GHz Athlon Thunderbird participating in the contest can either sit idle or test 1,275 million keys at a cost of one additional watt-hour. Since the RC5-64 contest tested 15,769,938,165,961,326,592 keys, at this rate that is 12,368,578,953 additional watt-hours used. That means about 12 gigawatt-hours (gWH) of additional electrical power were produced and consumed over the last four years just to solve the contest.

This Los Alamos National Laboratory web page provided lots of data regarding coal and electrical generation. Referring to only the 1998 figures, I found that U.S. electric generators required 10,311 BTU to generate one kilowatt-hour. If the contest required 12 gWH of additional electricity, it must have taken about 123,732 million BTUs to generate it. Bituminous coal yields 24 million BTU per ton; sub-bituminous coal yields only 17 million BTU per ton. In 1998, the US was mining and burning about a 47%/53% mix, averaging out to about 20.5 million BTU/ton. Therefore 6,036 tons of coal had to be burned in order to generate that much eletricity. Over sixty railroad cars of coal. Looking at the CO2 problem, at the reported U.S. average of 208 lbs of CO2 produced per million BTU generated by burning coal, the contest was responsible for the production and emission of about 26 million pounds of carbon dioxide.

When it comes to the RC5-72 contest the numbers get even worse, since according to the RC5-72 speed page the number of keys per second drops to about 72% of the RC5-64 cracking speed for the Athlon 1GHz Thunderbird. Assuming that this 72% ratio is similar across most architectures, extrapolating the contest to RC5-72 should require about 2^8 times as much of everything to solve at 72% efficiency, or about 356 times the RC5-64 figures. 12 gWH * 356 is 4.3 terawatt-hours. 6,036 tons * 356 is over 2 million tons of coal. More than 210 full trains. 26 * 356 is about 9.2 billion pounds of carbon dioxide that will be produced.

Now, these numbers are pretty much long-range projections made from some small, narrow observations. Not every CPU will consume 10 additional watts when busy. And not every CPU would otherwise drop to an idle or standby state. But some computers will be left on and cracking keys rather than hibernating or being powered off, which could save 116 watts/hour or more. And some may consume more than 10 extra watt-hours when active; such as a Pentium III-667 MHz which consumes 34 watt-hours operating but only 5 watt-hours when it can drop to standby.

Also, only about 56% of our electricity is generated by burning coal: the rest is produced by nuclear power, or burning natural gas, fuel oil or biomass; about 10% is produced by renewable resources. The key could be found tomorrow, or it could be found 15 years from now. So my estimates are still just that: estimates. I could be wrong by orders of magnitude, but even so, the fact is that the RC5-72 contest is going to increase electricity consumption. Over the course of its life, the RC5-72 contest might be responsible for burning only 100 tons of coal, or it might cause the burn of 4 billion tons of coal.

-------

And for those of you are still reading and haven't been bored by all the numbers, I think it would have cost me about $850.00 worth of electricity to personally participate. The prize is $10,000, $1,000 of which goes to distributed.net, $8,000 goes to a charitable organization of distributed.net's choosing (the EFF, I think) and $1,000 goes to the person whose machine found the winning key.

That's an $850 investment for a 1/165,000,000,000 chance of winning $1,000 in the next 10 years. That's discounting

• rising electric costs
• devaluation of the dollar due to inflation
• the chances that RSA will still be in business and able to pay the $10,000 reward in 10 years.

• I think my money would be MUCH safer invested in lottery tickets, where I've heard that investments pay out about $0.11 on the dollar (average.)

-------

Here's the executive summary: CPUs consume more electricity when actively computing than they do when idle. To solve the RC5-72 challenge may require an additional 2 million tons of coal be burned in order to produce the additional electricity required. That's over 200 full coal trains. 9.2 billion pounds of additional carbon dioxide will be produced and released. The details follow.

I sent a letter to my buddies during a discussion of relaunching our team to attack the RC5-72 challenge. It showed a simplistic estimation of the energy costs required for me to participate in the challenge. I know that my CPU uses more energy to perform math calculations than it does to sit idle. It has since occurred to me that not only would I be burning an extra megawatt or two of electricity during the contest to participate, but so would all the other participants.

I've researched things a bit more since then. The distributed.net speed page shows an Athlon 1GHz Thunderbird averaging 3,540,087 keys/sec, or 12,744,313,200 keys/hour during the RC5-64 contest. A hardware vendor's page shows an active Athlon 1GHz Thunderbird CPU consumes an extra 10 watt-hours above its standby level. This is only the difference between an active CPU and an idle CPU, and does not account for any other standby power savings that may or may not take place. That means a 1GHz Athlon Thunderbird participating in the contest can either sit idle or test 1,275 million keys at a cost of one additional watt-hour. Since the RC5-64 contest tested 15,769,938,165,961,326,592 keys, at this rate that is 12,368,578,953 additional watt-hours used. That means about 12 gigawatt-hours (gWH) of additional electrical power were produced and consumed over the last four years just to solve the contest.

This Los Alamos National Laboratory web page provided lots of data regarding coal and electrical generation. Referring to only the 1998 figures, I found that U.S. electric generators required 10,311 BTU to generate one kilowatt-hour. If the contest required 12 gWH of additional electricity, it must have taken about 123,732 million BTUs to generate it. Bituminous coal yields 24 million BTU per ton; sub-bituminous coal yields only 17 million BTU per ton. In 1998, the US was mining and burning about a 47%/53% mix, averaging out to about 20.5 million BTU/ton. Therefore 6,036 tons of coal had to be burned in order to generate that much eletricity. Over sixty railroad cars of coal. Looking at the CO2 problem, at the reported U.S. average of 208 lbs of CO2 produced per million BTU generated by burning coal, the contest was responsible for the production and emission of about 26 million pounds of carbon dioxide.

When it comes to the RC5-72 contest the numbers get even worse, since according to the RC5-72 speed page the number of keys per second drops to about 72% of the RC5-64 cracking speed for the Athlon 1GHz Thunderbird. Assuming that this 72% ratio is similar across most architectures, extrapolating the contest to RC5-72 should require about 2^8 times as much of everything to solve at 72% efficiency, or about 356 times the RC5-64 figures. 12 gWH * 356 is 4.3 terawatt-hours. 6,036 tons * 356 is over 2 million tons of coal. More than 210 full trains. 26 * 356 is about 9.2 billion pounds of carbon dioxide that will be produced.

Now, these numbers are pretty much long-range projections made from some small, narrow observations. Not every CPU will consume 10 additional watts when busy. And not every CPU would otherwise drop to an idle or standby state. But some computers will be left on and cracking keys rather than hibernating or being powered off, which could save 116 watts/hour or more. And some may consume more than 10 extra watt-hours when active; such as a Pentium III-667 MHz which consumes 34 watt-hours operating but only 5 watt-hours when it can drop to standby.

Also, only about 56% of our electricity is generated by burning coal: the rest is produced by nuclear power, or burning natural gas, fuel oil or biomass; about 10% is produced by renewable resources. The key could be found tomorrow, or it could be found 15 years from now. So my estimates are still just that: estimates. I could be wrong by orders of magnitude, but even so, the fact is that the RC5-72 contest is going to increase electricity consumption. Over the course of its life, the RC5-72 contest might be responsible for burning only 100 tons of coal, or it might cause the burn of 4 billion tons of coal.

-------

And for those of you are still reading and haven't been bored by all the numbers, I think it would have cost me about $850.00 worth of electricity to personally participate. The prize is $10,000, $1,000 of which goes to distributed.net, $8,000 goes to a charitable organization of distributed.net's choosing (the EFF, I think) and $1,000 goes to the person whose machine found the winning key.

That's an $850 investment for a 1/165,000,000,000 chance of winning $1,000 in the next 10 years. That's discounting

• rising electric costs
• devaluation of the dollar due to inflation
• the chances that RSA will still be in business and able to pay the $10,000 reward in 10 years.

• I think my money would be MUCH safer invested in lottery tickets, where I've heard that investments pay out about $0.11 on the dollar (average.)

Its pretty much some useless thing that you run, and see if you can get more time put into it than others. Most people do it just to look at the Statistics and compare with everyone else out there.

ProgressQuest is worse and better at the same time. It does not eat up all your CPU cycles like d.net does, but it has no purpose what so ever.

Why are you doing this? Try that.

I find dnet's _=OGR info disclosure FAQ answer=_ to be far too ambiguous to even think of doing OGR processing for them. I get the feeling they're using the public for free research, so they can have a piece of information to sell to some government defense contractor...

If I'm reading their charts right, the rate at the end of RC5-64 was around 250 Gkeys/sec. That's roughly 2^38, so to search half the keyspace of RC5-72 at the same rate would take 2^33 seconds, or around 270 years. Until computers get a lot faster, any work done on RC5-72 will just be a drop in the very large bucket.

Especially since one of the goals of the project (from this page) was to show that the US policy dictating the maximum keysize was out of date. That policy has since been changed and there is AFAIK, no restriction on keylength anymore (but you still can't export to "bad" countries).

The "Because it's fun" one is bizarre too. I'm sure it was fun writing the client and developing all the server side stuff. But if you just run the client in the background and get any excitement of that then you need to get out more ;)

But, as always, it's their computers and if they want to run this contest more power to them.

the current stats page doesn't seem to be linked from the main page anywhere... anyway, here's the link.

• Support for multiprocessor machines, heterogeneous networks, LAN, and WAN
• Support for scheduling of virtual processes or explicit distribution to available processors
• Support for virtual shared memory
• Support for synchronization, locking, and latency hiding

woof.

As for network - do you need throughput or low latency? Depeding on your problem small changes in algorithm can do wonders. E.g. for film rendering you might choose a few NAS and a hoard of dumb/diskless rendering slaves. If you copy the model libraries (for the included figures, textures, etc.) onto a local disk at the beginning of a scene render run, you will decrease net load a big deal (I've done that with Provray rendering myself).

If you don't have the rerssources to buy e.g. Myrinet, try alternative architectures if they might fit your problem, e.g. hypercubes (see other posts) or models like Flat Neighbourhood.

my superiors were concerned that if many connections were made to the central server simultaneously, there would be a noticable drop in performance.

It's interesting to see graphs of cracking power.

RC5 took almost 5 years to crack, but take look at the graph. At the beginning of 1998 there were about 15 GigaKeys/sec. Then look at the increase.

Sure, a fair portion of the increase was also the addition of new computers, but 261 days to double is comfortably below Moore's Law. If the whole project had run continuously at 200 GigaKeys/sec, it would have taken under 2.5 years, and under two years at their reported peak rate of 270 GigaKeys/sec.

So, if we follow the 261 day doubling statistic they had, all these encryption methods seem weaker than reported. The big issue is if it's 4 years now, it's 1 year soon, and 3 months, soon after.

If the cracking power scales nearly linearly, shouldn't we make some projections on how fast we can crack this encryption in a year? In two years?

If your data is very time sensitive, then most "strong" encryptions currently available will do. If your data is, however, of a continuously sensitive nature (some corporate or government info), maybe you should be looking at the 1000+ bit keys now.

This argument is very, very old and very, very dumb. It just depends on what you're doing. These stats were approximately true last time I looked, pipeline changes may have changed this.

If you're doing 3d gaming, who cares, it's your GPU doing the work anyway.

For 2d graphics, the Mac is about twice as fast per clock cycle. So, equivalent to a 2GHz Pentium for, say, Photoshop.

For cracking codes, the vector processing unit in the Mac really shines, it's over 6 times as fast per clock (see distributed.net) as a P4 for brute-forcing RC4. So, equivalent to about a 6.4 GHz, more than he claimed. The G4 almost 3 times faster than an Athlon (the second best) per clock cycle.

For most stuff, the G4 is slightly faster than Pentium, per clock cycle. Some 20% faster for POV-Ray, about 30% faster for SETI (based on stats between me and my roommate) etc. So for most stuff, it's not worth the 4GHz Pentium.

Yes, and imagine the case of the distributed crypto-crack efforts such as those run by distributed.net and by us too for the rc5-56 challenge (the cyberian.org effort). Imagine, that someone fakes the results for just the keyspace, which contained the correct key - and that this forged result passes the controls. Now, as result the progress counter might reach 100% and you still did not find the correct key. The only solution would be to calculate the whole keyspace again. I mean, even if you check the integrity - calculate same task for 10 times for example - still, it is possible that the forge gets through. Ofcourse, there is a number of counter actions to make the forging harder but still, I think the key problem is still unanswered. Or, if someone has some good fresh pointers about this subject, please post them here :)

Theres an interesting paper on this subject available here. well worth a read.

M$ products & others' are closed and look at all the "cheats" (exploits) you can use on them. You cant stop the cheating through obscurity, as the linked page in the First Post states.

Theres an interesting paper on this subject available here. well worth a read.

Alrighty, so I downloaded the software for freenet 0.5, and I got everything installed and running in about 5 - 10 minutes; no big deal. So then, like any true geek, I had to start tinkering with the settings. Now, it still seems to work ok, but it's using a ton of CPU (about 30 - 40% on average of an AXP 1700), and I'm having a bit of trouble getting into some basic sites like The Freedom Engine, which I was able to pop right into last night. Of course, I didn't look to see what the defaults were, and I guess my main concern is that I might be making life difficult for others with a possible misconfiguration. So if someone who's a bit more knowledgable about this software could give me an idea of what the Performance settings under the Advanced Settings should look like, I'd greatly appreciate it. I turned up zip on google and saw nothing in the helps/docs/online helps about a default configuration. Personally, I'd rather have well-tweaked settings (for optimal performance for both me and people using my node) than the defaults. Anyway, here's some info to maybe narrow things down a bit.

System Config:
AthlonXP 1700+
1GB DDR
more drive space than you can shake a tree at
business cable (3.5mbps/384k)
Win2k

Freenet is configured as follows:
non-transient (duh)
10GB disk space allocated (willing to add more if needed)
announce to other nodes is on
Init Req HTL: 15
Max HTL: 50
Max connections: 40
Max Threads: 160
CPU priority: (lessthan)NORMAL (interferes with games and such is it's on normal, I suppose it's something to do with the thread scheduler, perhaps talking to the folks at distributed.net might help with that.)

If anyone can help shed some light on this for me, I'd greatly appreciate it. It's entirely possible that this is all normal; it's just that being new to freenet, I don't know what "normal" is in terms of software/network behavior. From what I've seen, freenet is a more secure/private version of the pre-WWW internet. I like the concept and I'd like to help out if I can get the software nailed down.

Also, I fail to see how you can make your claim that running distributed computing clients is a task "the G4 does better and faster than any other processor"??

What are you benchmarking against? It's pretty much cold, hard fact that the latest P4 processors outperform anything in the G4 series. That's why Apple was considering the idea of possibly moving towards an Intel-based Mac someday. They have a CPU that won't scale as far, and doesn't perform as well as what Intel has.

that's a very valid point actually! If you have a look at the statistics here for example, you'll see that Linux is very likely to be operating system No 2 in the world today!!

check distributed.net for example!

Well here is a benchmark of the RC5 speeds for various processors. Yes the PowerPC does kick some major arse. Why is the question, and here is the answer. Anyway, long story short I heard there is a nice barrel shifter in the PowerPC that makes them excellent candidates for the RC5 client. So as they said in the second link the RC5 contest is not a good benchmark for performance. Although, it is sweet how fast the PowerPCs cores are!

JOhn

Well here is a benchmark of the RC5 speeds for various processors. Yes the PowerPC does kick some major arse. Why is the question, and here is the answer. Anyway, long story short I heard there is a nice barrel shifter in the PowerPC that makes them excellent candidates for the RC5 client. So as they said in the second link the RC5 contest is not a good benchmark for performance. Although, it is sweet how fast the PowerPCs cores are!

JOhn

RC5-64 was supposed to take something like a hundred years when we started that, and it managed to be completed in about 5

The amount of processing power used for Distributed.net's RC5-64 effort hadn't grown exponentially but rather pretty much linearly. There's a limit to the power of even word of mouth.

what can I use my spare cycles for, besides SETI?

Distributed.net Break encryption and teach the government a lesson on the value of strong encryption at the same time.

That's where my spare cycles go...

*scoove*