Slashdot Mirror
Distributed.net Suspends OGR project
st.n. writes "According to this
statement, distributed.net
is suspending its new OGR-24 project,
which was started just
a week ago, because of a missing ntohl() call in the buffering code.
They were 24% done already and have to start over again now.
"
By "So far, we have completed approximately 24% of the total stubs, mostly smaller ones." doesn't that mean that they're not 24% done in terms of time? I think the statement "They were 24% done already and have to start over again now." is a little misleading...
So where are the stats on how much fossil fuel was wasted *this* time? I had 5 machines running the client all last week...
With encryption cracking efforts, it is easy to know if the solution was correct. But for problems like OGR, who verifies the results of such computations? I mean, I think there must be at least two other separate efforts that arrive at the same solution for me to be convinced that 'yeah, this is the answer'. Does anyone know how this is currently being done? Can they prove it mathematically?
If Intel x86 chips, where the bytes are ordered the wrong way round, had not been so sucessful due to their most unholy alliance with software where much more is the wrong way round, we would never have had this problem.
;-)
If you can figure out this sentence, then you are probably too smart to think of a reason why one would write a number backwards (in memory).
One of my boxes is a sad old DX2/66 and had only just managed to do one plan. Moving to 5-stubs instead of 4-stubs will stop me thinking that one had frozen.
threadeds blog
How about a big distributed 3D rendering job instead? At least there'd be pretty pictures.
Is this childlike reasoning ever going to stop?
You left computers on last week. Were they going to be on anyway? If so, there was no waste.
Is it cold where those computers are? Would the heater be running anyway? If so, there was no waste.
If the only reason that the computers were left on was so that you could gain ground in the stats race, then guess what? YOU wasted resources. No one else did.
So, pay your electric bill and live with yourself as you are and shut up about it, or learn from your mistake and don't do it again. Either way, we really don't need to hear whining about the resources that YOU wasted.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
Umm, I think those "idiots" are doing this in there spare time and for free.
Anyone is welcome to spend all there free time working on a project. But please let us know though when you get started, so we can call you an idiot and slow when it doesn't live up to my expectations on how it should be running.
--
--
This may be a silly question, but I'm going to ask it anyway: Did (some) of the OGR blocks take a huge amount of time for others, or was it just me? I'm running the client on a Celeron 300A (not a power machine, but a lot faster than the 386 I started running RC5 on) and some of the OGR blocks took over 14 hours. I didn't know we'd done anything like 25% of the 'keyspace', but it looked to me like this project was going to go on for ever, given the speed of my computer.
Paranoia isn't an infectious condition, it's a way of life
It's a pity, but I agree with you. RC5-64 is incredibly boring and pointless; it proves nothing that wasn't shown by the previous RC5-56 contest. OGR interested me because it was new and was potentially, slightly useful to some people. I only run the d.net client on one box now (plus any others I've forgotten about at work), and the rest of them are in the "APM Contest", a global network of computers attempting to conserve whatever small bits of electricity they can in their spare time. A more worthwhile cause IMHO, and it's open-source too.
"1 little, 2 little, 3 little endians...." :)
Save the whales. Feed the hungry. Free the mallocs.
Given the past screwups of distributed.net, this latest snafu isn't suprising. In fact, I had a bad feeling about the whole thing when I switched my clients over to OGR from RC5 - just call it a gut feeling that somewhere during the contest, they would announce they had a bug and their results were bogus. I guess this is it. Can anyone tell me about other distributed projects they are aware of? I know of dcypher.net and thats about it. Maybe its time we start a "new" distributed.net - heck, throw in a "new" slashdot too while we're at it....
I was 24% done with my first batch of grits!
Save the whales. Feed the hungry. Free the mallocs.
Not!
My P2-266 has been taking just under 24 hours to complete a stub.
In case you can't figure it out, that's "Huh?" spelled backwards.
If you can comprehend this equation, then you are probably too smart to think of a reason why owt would write a word the wrong way around(at all).
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
I still participate in distributed.net efforts using many boxes. I have them up all the time anyways. I consider it increased productivity to let someone do something marginally useful with my idle clocks.
That said, if they would release the source for their clients they would find these problems sooner (I suspect) and there would be less wasted time and resources...
GPL the client!
AAAALLLLLLRIIIIGHT! My first down-moderation! I LOVE IT!
BRING IT ON! I've got 100+ Karma to burn and it STARTS TODAY!
Let the word go out to both moderators and trolls alike, TODAY DONKPUNCH IS OFFICIALLY ON THE DARK SIDE! I have become a moderator's worst freakin' nightmare -- an over-caffeinated offtopic troll with a default 2!
Why did this have to happen? Where did things go wrong? Was I forced into it? Did the down-moderation destroy my self-esteem? Am I just a burnout? Is my unique humor and insight unappreciated by my peers in my time? Will I be remembered as a misunderstood genius when I'm gone?
I predict a new article: "Ask Slashdot: DonkPunch -- when good posters go bad. How can we keep this from happening again?"
E! News and VH-1 will feature a special "Behind The Dot" episode: "The Rise And Fall of DonkPunch's Karma" They'll show scenes of me posting pro-Linux suckup posts to desperately get my Karma back up to 50 or so. All of my posts will be at least 200 lines long, requiring a "Read the Rest of This Comment" link.
Ye Gods, Moderators, don't you see what you've done? You've created a monster! You've banished me to the land of the trolls AND I LIKE IT HERE! Seems to me the trolls have a heck of a lot more fun on slashduh anyway.
Now you will pay the price for your lack of vision!
Save the whales. Feed the hungry. Free the mallocs.
www.mersenne.org List of distributed projects that make sense (at least some of them) in contrast to most distributed.net projects. Once the distributed RC5 cracking make sense, but now it is pretty useless as the computing time is just an extrapolation of the time needed to crack the other messages...
ftp = food transfer protocol?
Once again, much to the detriment of the project, we have proved that closed source, closed beta doesn't work.
Why not open it up before you loose everyone who's working on the project?
Hey Rob, Thanks for that tarball!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
Look at http://www.distributed.net/source/. If you had visited the distributed.net site, you probably would have noticed the "Source" option in the lefthand menu bar. But, hey, it's easier to whine, yes?
--Matt
*smack* THANK YOU SIR! MAY I HAVE ANOTHER?
C'mon wimps! Is that the best you can do? I'm laughing in your humorless, petrified, grits-covered, moderating faces.
What is that!? A FreeBSD pin!!?? ON YOUR UNIFORM!!!???
Just you wait.... I won't be the last. Even if you crush my karma with your dogma; even if you cancel my login, there will be others. Foogle has already started to turn. I am convinced that Signal 11 will someday turn. In fact, I believe that Signal 11 is already a troll who is just building up unstoppable karma for THE DAY OF RECKONING.
As Mariah Carey sang so eloquently in "The Matrix", "My Heart Will Go On."
Someday, perhaps even Bruce Perens will submit a down-moderated post? WHAT WILL YOU DO THEN? Will it be the end of everything you've believed in? Will it be the end of all you hold dear? Will you have to go back to actually WRITING CODE instead of sharing your feelings on what it means to be a geek?
I know some of you long-time slashduh readers will be frightened by my tone. Fear not. I'm still the same warm, fuzzy, lovable DonkPunch. You can still order plush DonkPunch toys from the Copyleft website.
But the humorless moderators have wronged me and today I must dwell in the land of the trolls. You know what? It's kind of nice here! These guys have cable and a VERY nice cappucino machine. Best of all, they actually WRITE CODE instead of whining for big companies to do the work for them. If Trollmastah, GritsBoy, and NakedAndPetrifiedMan don't mind, I might stay awhile.
Save the whales. Feed the hungry. Free the mallocs.
History: In the ancient past, before dinosaurs evolved and foot-long dragonflies sported above the cycads in the massive forests of the carboniferous, there was the 8-bit memory bus. Now, with an 8-bit memory bus, you have to fetch your operands 1 byte at a time. Suppose you are doing a 16-bit add-immediate with your carboniferous-era processor (which you may still be able to find fossilized somewhere, like at ham swaps). To do your add, you have to first add the least significant bytes, then add the most significant bytes with carry. If you store your operands big-endian, you have to complicate your processor in one of two ways:
- Use a temporary register to store the high byte until after the low byte is fetched and added. Then you can finally use the high byte.
- Increment the PC by two, fetch the low byte, decrement the PC, fetch the high byte, then increment the PC by two.
Primitive processors of the carboniferous could not handle such complexity. They evolved the little-endian system to allow them to pipeline. Storing the operands little-endian allows the operand fetch to occur during the instruction decode cycle, then the least-significant byte can be added (in the 8-bit ALU) dudring the same cycle as the most-significant-byte fetch. This requires less hardware and takes only three cycles (assuming no microcode). The 6502 stores its offsets little-endian also, if I recall correctly.Once you have a wider memory bus which can pull entire operands in one memory cycle there's still some pressure to remain little-endian and no reason for changing things; you've got all this design inventory and software tools and other things that are little-endian, and the only reason an HLL programmer would care is if she's type-punning or doing some other untoward thing. So that's why things haven't changed.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
Consider this. If he had been running the seti@home client, the resources would have been put to better use. Maby that is what he ment by wasted resources... and not some silly status thing. In this case the resources would have been wasted. Perhaps he really wishes to put his extra cpu cycles to a good use and this frustrated him.
john
-- john
That your perspective matches his. However, this kind of comment has been all over the d.net mailing lists - for years, and I have yet to see that perspective spelled out.
On the other hand, he still doesn't have to gripe to us about his frustrations. He can run both projects and thus risk less if either one fails. Remember, Linux is a multiuser, multitasking os and he can choose to risk only half of his resources if he bothers to think about it beforehand.
So far, in my experience with others that have made the same post, they have simply not bothered to think, or read any mailing list archives, or put any effort into the project other than just installing/running the client. When something goes wrong, rather than think about the situation and possibly come up with a solution to the problem, they whine as if by reflex.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
You've hit it square on the head. Big-Endian and Little-endian are essentially arbitrary. There may be technical reasons why one is more useful than the other for certain purposes, but considering little-endian "backwards" is just silly.
Elliptic Curve Discrete Logarithms: ECC2K-108 http://cristal.inria.fr/~harley/ecdl7/
Hey, how about they start a new distributed project that will allow me to boot Windows in under 30 minutes. I figure we could have it down to 15 minutes if we go like 30000 other computers involved. :-)
I joined the Distributed.net effort specifically because I wanted to help out working with the golomb rulers, a very interesting mathematical project. I really have no interest in cracking any form of encryption. Yes, it can be done brute force. We know that already. We don't know what the 24 mark optimal golomb ruler is. So finding it would be cool. Anyhow, nowhere on the distributed.net page does it say when the new clients will be available... does anyone have any insider information on whether the client upgrades they are considering are going to take awhile?
Adding the conversion call is easy, sure, but the 'improved progress reporting' and such... any idea how long it'll take?
Esperandi
So it appears that we'll all have to go and download new clients when they're released to get round this bug. AFAIK distributed.net will discard any blocks submitted by the old clients but the old clients will still attempt to fetch blocks off the keyserver. It'd be a good idea to change the project ID slightly (e.g. to OGR-a) so that the old clients will not try to fetch these blocks in the first place. Because if these old clients are just downloading OGR blocks that just get discarded it's a waste of the CPU time where they could be doing RC5 instead.
Basically there has to be some system to stop the buggy clients downloading blocks and wasting their time.
--
Make use of your spare CPU time!
The fear is not bogus data that we have to remove. Rather, the true damage to the integrity of a project comes from bogus data which is indistinguishable from legitimate data. Infinite man-hours of effort cannot correct the damage done by a false-negative in the case of a crypto contest.
It's also a bit optimistic to assume that we'd be able to isolate a committed vandal to the degree required to successfully filter their bogus submissions. An attacker could simply instruct their malicious client to submit work using participant emails randomly taken from stats, easily blending their work in with legitimate work. We can't assume that every attacker will send in their work with a consistent IP or email address.
I'm not making the argument that there's not room for improvement in the current scheme, but it's difficult for us to become too enamored with solutions that only offer a marginal improvement over the current model.
We welcome suggestions and creative remedies from out in the world. If someone has a solution to this quandary, we'd love to implement it. This client trust issue is the holy grail of distributed computing projects, and we hope that it's solvable. I don't think that a lack of access to our buffer file formats is a stumbling block which would prevent a creative and insightful person from devising a solution, however. We don't need to open that source in order to allow someone to solve the issue.
Thanks for your comments and support, and if you do have any proposal which would allow us to trust the work performed by an open source client, we'd love to put it to work.
Another thing that foretold distributed.net emminent failure is that it took them almost 2 years to roll out. Compare this to the time it took to roll out for the first DES-II contest, less than a single month. Admitily DES-II was easier to add to their clients then OGR but it also tells of their inability to understand the fundamental parts of an OGR search.
Another bad sign for distributed.net was when the original people who ran the OGR-20 and 21 searches started up again after distributed.net had contacted them and announced their plans of doing OGR. The original OGR people then went on to do OGR-22 and OGR-23.
The most recent failing came with the CSC contest. They released a new client with both CSC and OGR support, and later they stated that they would start CSC. But no word of OGR, they obviously thought they had a working OGR client, but quickly found out otherwise. When I used the client it was buggy as hell. I submited a bug report to distributed.net's bugzilla database that I could faithfully reproduce a bug with OGR reported by one of distributed.net's own. The bug was later marked as INVALID, even though I was still able to get the client to tell me that I had completed a full OGR stub in less than a second.
Finally, distributed.net was not able to provide even a rough estimate of how much work, or which stubs would take longer. The original OGR project had easily created a mapping of the expected number of nodes in each stub before the project even started.
In conclusion distributed.net doesn't seem to have a clue on what it is doing. It doesn't seem to really want to fulfil its mission statement, they only seem bent on relinquishing their control over so many users computers.
I am *NOT* saying that this is what distributed.net is trying to do. This is what I have come to think about distributed.net given all the input I can gather from distributed.net. I would really appreciate a reply from someone inside distributed.net to try and explain to me what is really going on behind the scenes that can rationally explain why a group of people with good intentions can come out of it with such bad results.
.... Why can't we find Silby's .plan pages anymore? Would Nugget or someone care to comment on that? I understand he was critical of what D.Net has become, but is that really reason to wipe his plan pages?
Hey Rob, Thanks for that tarball!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
What about SETI@home? Has it become too "Popular" to be the in thing to run anymore? It's a moot point for me anyway; Both of SETI@home's linux distributions for my box (i686-pc-linux-gnu-gnulibc2.1 and i686-pc-linux-gnulibc1-static) core dumped on me under RH 6.1. So, I guess I'll keep my piddly 133mhz pentium busy doing distributed.net stuff, even if they do occasionaly have bugs with their code; at least it runs.
IANAM (I Am Not A Mathematician), but: If you find a shorter ruler than the shortest known, the new ruler is then the shortest known ruler. Understanding that someday a shorter ruler could be found, the ruler is not designated the shortest absolutely, but instead the shortest known ruler.
You're not the only one-- I'm running this on a fairly beefy box and it still takes a LONG time (as in several days) to complete a single work unit. In order for the daily stats to be useful, it seems like one ought to be able to finish more than one work unit per day.
It's my hope that this is what they mean by: we will have the opportunity to improve some other aspects of client operation. In particular, we plan to add more configurable checkpointing and a better display of progress in their announcement.
As to the speed of the whole search-- that would depend as much on the size of the search space as on the speed of the client. Clearly we are looking at a real small search space if it were 25% searched in only a few days.
I know they never counted my seven days' work since it's all still sitting in my buff-out.ogr file. I'm using the dnetc v2.8007-458-CTR-00020606 for Linux (Linux 2.2.12-20) client-- perhaps it's client-specific?
http://cosm.mithral.com/
Deleted
Do this sum in your head......
:)
1,742,312
+ 4,417,091
---------
Did you do it Left to Right, or "Backwards?"
Nipok Nek
Or, call me by my new Indian Name... Little Bigendian
Why choose white shoes?
Could you tell us more about that? I know a bit about the data communications part, but where are the applications in cryptography and lithography?
Or do you have any links to sites describing that?
Thanks!
--Carpe diem!
This problem seems like it would be a prime candidate for a DNA computer to solve. It would have made a nice race to see which technology could have arrived at the answer first.
..........FULL STOP.