with the i7 920 i'll probably try for an oc. supposed to be almost idiot-proof to 3.5, and with a little effort 4.0 can be hit.

do you mean you have a 940 or 965? haven't heard of an i7 950.

if you have the 965, its unlocked, and you can oc like a banshee! 5.0+ anyone ?!

EDIT ---> Nevermind, answered my own question, the i7 940 is clocked at 2.93

Shaktai:

Thanks for adding the i7 Core. I want to buy a new system and I think i7 is the way to go. I love all of the inexpensive RAM and systemboards for intel 775 but i7 looks really good.

Can you bring those other computers over soon? R@H can use every process you have!

Thanks again and keep crunching.

That's 1,000 credits since YESTERDAY!!!! Wow that is fast!! I have an intel P4 T2300 running at 1.66ghz and your i7 measures twice as fast in both floating and integer scores. You are also doing units in about an hour or so, mine is doing them in over twice as long!

Do we have enough stats on the i7 to know if it is good for R@H?

I looked at some of the BOINC Stats pages but I don't understand what it is telling me.

The Q6600 is a work horse and the Q9450 should be even faster with 45nm technology and an expanded cache.

What is the sweet spot for processors on R@H? Clearly faster processors are better but I am looking for the best RAC to $ ratio.

I've seen a flaw in my previous logic though - my original calc was per core, but of course there are 8 logical cores here, and each is getting slightly less credit than my Q6600 per cycle, but as there are two threads (it looks like that machine is running 8 threads from the sum of the time on all tasks), then that's quite impressive. I'd be interested to see one with and without HT for comparison as it might be even quicker with only four rosetta threads running.

First, terminology. A quorum only has one WU, and "n" results. That right there throws out your idea, unless the whole thing was redesigned on the server side. Each member of a quorum simply downloads a copy of the _same_ file from the server. That distribution would have to be changed. Also, how do you validate? Each result would be different, so no comparison would be possible. I realize there is effectively NO validation now, but you'd have to have some kind of validator running (more complex than current, though still simple) to do the credit averaging, even if it didn't actually look at the content of the results and only at the status and the claimed credit...

And, which is the canonical result? The lowest energy? I think they want to store _all_ the results.

Good basic idea, but I think given the structure of the BOINC architecture, it'd just be way too complicated to implement.

There are some problems with OS 10.3.x. I think that David Kim will be working on these when he gets back from vacation. For now, 10.4.x is required. This was answered in the other thread in this group as well.

I wish they would post this information before we waste days of CPU time trying to help out. Just a little something on the system requirements page maybe next to where they say it does work on Mac OSX 10.3.9.

We would give a specific random seed for each work unit and use homogeneous redundancy.

Is there a problem with the servers, or maybe the network?

Something's not right, and it would be nice to understand if I should retry tomorrow, next week, next month, or next year.

Thanks in advance.

David spent much of this past week working on this, and with some help from other members of the Rosetta community I think he has solved the problem. Tell your friends to check back mid next week.