Posts by MikeMarsUK

21) Message boards : Number crunching : My PC RAC > 3000 (Message 34534)
Posted 11 Jan 2007 by MikeMarsUK
Post:

What was the actual cost of the system? I'd guess prices will drop in the future.
22) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 34277)
Posted 7 Jan 2007 by MikeMarsUK
Post:
...My credit has begun so sneak up a little, 3 days ago, we'll see if it continues to climb, or if it just a bump. Before who? shut his machines down.
...


The biggest effect will be work machines + servers coming online again after the holiday which will be returning to the balance of machines that the project had before the holidays. A single machine, even a giant one, will not make a detectable difference.

1 reason to think so, my Top 2 machines dropped immediatly when i stopped it, while the Top 1 machine did not drop 1 unit yet (3,855.88 after 2 days)
my 2 other machines dropped too immediatly.


The RAC only seems to drop at intervals (weekly?), at least it looks like that on my PCs.
23) Message boards : Number crunching : My PC RAC > 3000 (Message 34160)
Posted 5 Jan 2007 by MikeMarsUK
Post:

That's extremely interesting, thank you :-)

I think Intel Fortran 9.0 can do SSE2 if available, but IIRC the CPDN project had to turn it off since the climate model became unrealistic after a long run time. (A climate model is an iterative process, even the slightest difference in result after one timestep will be gradually magnified by the time the model finishes. The so-called 'butterfly' effect. There are over 4 million iterations before the model finishes, and this takes 2 months of CPU time on a core2 box).

But I guess Mac's 9.1 compiler won't have the overhead of detecting which instruction sets are available, and swapping between the two alternative code fragments (the SSE2 compiled model could run OK on non-SSE2 boxes).

It'll be interesting to see if SSE4 can help :-)
24) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 34100)
Posted 4 Jan 2007 by MikeMarsUK
Post:
Significant, IIRC this is when the difference exceeds the margin of error. So 10% could certainly be significant given a sufficient precision and a decent cross-section of the results. But I think MikeMarsUK gives it a different definition, more something like; "I think a 10% difference is completely acceptable."


I used an entirely nonstatistical definition

- Would I care about a 10% drop in my credit? nope.

- Would I care about a 50% drop in my credit? maybe. But I have spent a lot of CPU hours on beta projects which don't publish credit and therefore been happy to accept a 100% drop in credit.

If there were some magic way to convert my 360,000 credit into another few completed models for the CPDN project, I wouldn't hesitate.

In different circumstances 10% would be something I care about - for example, in the other thread about model performance, where the difference would be 10% extra scientific work for the project, adding 10% would be a major advance, and even 5% would be very significant to me. (Note the 'me' - this is an entirely personal judgement and other people will have different opinions).
25) Message boards : Number crunching : My PC RAC > 3000 (Message 34075)
Posted 4 Jan 2007 by MikeMarsUK
Post:
I have a performance question for Who?, although it's not related to Rosetta :

The CPDN coupled model uses Intel Fortran 9.0 for the Windows version, and 9.1 for the Intel Mac version in beta testing, but AFAIK everything is the same in terms of compiler switches and so forth.

The model is very demanding on the system memory, much more so than Rosetta (latency and bandwidth affect model performance significantly). I understand the Macs tend to have better memory than the typical PC?

The Mac version performs significantly faster than the Windows version, around 20-25%. Overall it looks like a factory-standard Intel Mac performs better than a top-spec overclocked Core2 Windows PC with fancy memory. Do you think this is more likely to be due to changes in the the compiler, or due to a possibly-superior Mac memory architecture?

Quad thread including Intel Mac post:
http://www.climateprediction.net/board/viewtopic.php?p=55450#55450

Intel Mac post:
http://www.climateprediction.net/board/viewtopic.php?p=55399#55399
26) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 34069)
Posted 4 Jan 2007 by MikeMarsUK
Post:

Closer to the latter than the former I'd have thought.
27) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 34053)
Posted 4 Jan 2007 by MikeMarsUK
Post:

From 1325 to 1220 is a drop of 9.2%, it's hardly significant...
28) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 34040)
Posted 3 Jan 2007 by MikeMarsUK
Post:
The stdoutdae.txt log file will probably contain a hint. If Boinc lost contact with the server for more than 6 hours or so it could have gone to 'communications deferred' for a week in the worst case.
29) Message boards : Number crunching : Compute Error? (Message 34038)
Posted 3 Jan 2007 by MikeMarsUK
Post:
Yours was an exit code 1, which is something different (often it's Windows killing the task, possibly due to an automated reboot, or something similar).
30) Message boards : Number crunching : Compute Error? (Message 33995)
Posted 3 Jan 2007 by MikeMarsUK
Post:

Well the screensaver is a bit of a waste of CPU time on every project... there is the 'show graphics' option to see how things are going on.
31) Message boards : Number crunching : Compute Error? (Message 33970)
Posted 2 Jan 2007 by MikeMarsUK
Post:

Does it help if you set your screensaver to 'blank' (display properties)?

Seeing if there are any updates to your graphics card drivers may also help.
32) Message boards : Number crunching : RAC dropped - a question of adding? (Message 33831)
Posted 31 Dec 2006 by MikeMarsUK
Post:
BoincStats works on the exported XML not the time of the actual result.

So it has a different definition of 'day' to Rosetta. A BoincStats day may be 20, 24, 30, ... hours long depending on when the XML was last exported and imported, so you'd be best off asking this question in the BoincStats forum rather than here.

Over a week or two it'll all average out.
33) Message boards : Number crunching : Client error Compute error - sorry, but who's fault is this? (Message 33828)
Posted 31 Dec 2006 by MikeMarsUK
Post:
Actually it would well have been due to coincidence. If you look at the other computers results, it's failing about 30% of the time.

I'd say the other computer is very unreliable, and it's just bad luck that the one WU you had which failed happened to also have been processed by an unreliable box.

If you want to check your own PC for reliability, I'd recommend running Prime95's Torture Test for 24 hours, but one failure out of 30 isn't too bad.

Regarding credit for failed work units, unfortunately it makes it possible for people to give themselves unlimited credit if that is allowed.
34) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 33822)
Posted 31 Dec 2006 by MikeMarsUK
Post:
Who?:
...
I guess, the thousands of Core 2 Computers can be responsable for other lower performance RAC drops ... if i understood well.

who?


Interesting, actually - your other box (the overclocked quad) doesn't show such an extreme effect. The claimed credit (based on benchmark) is around 100, and the granted credit is around 160 (versus 70 and 130 on the octocore). Granted credit per hour per core is around 26-27 which is pretty impressive. As an aside your octocore should reach 4100 RAC after a month or so.

I do note that the Boinc benchmark is quite often erratic, so you might find your octocore box gives you a better benchmark the next time it runs (and hence higher claimed credit).

Other core2 systems also seem to show less of a divergance between claimed and granted, but still tend to show
http://boinc.bakerlab.org/rosetta/results.php?hostid=317079&offset=60 - 120 claimed, 150 granted
http://boinc.bakerlab.org/rosetta/results.php?hostid=359325 - 54 claimed, 65-70 granted
http://boinc.bakerlab.org/rosetta/results.php?hostid=282631 - 55-59 claimed, 65-72 granted
http://boinc.bakerlab.org/rosetta/results.php?hostid=346572&offset=20 - 57-59 claimed, 70-80 granted


You're quite right to say that if the % of these machines in the pool running Rosetta becomes significant, it'll affect the overall balance between granted and claimed. (The same is of course also true for Linux, Mac, ...).
35) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 33805)
Posted 30 Dec 2006 by MikeMarsUK
Post:

I'm not sure that a fluctuation of less than 10% is really something to be worried about... ?

36) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 33730)
Posted 29 Dec 2006 by MikeMarsUK
Post:

It's just a cumulative average, given the large number of PCs running each type of work unit, it won't make any difference in the long run.

Using a very simple example, the first is your PC, the subsequent ones are all claiming the average

PC1 - 70 Work claimed, 130 work done - 70/130 granted/done cumulative, you get granted 70 credit
PC2 - 30 work claimed, 30 work done - 100/160, gets granted 18.5
PC3 - 30 work claimed, 30 work done - 130/190, granted 20.5 credit
PC4 - 30 work claimed, 30 work done - 160/210, granted 22.8 credit
PC5 - 30 work claimed, 30 work done - 190/240, granted 23.8
PC6 - 30 work claimed, 30 work done - 220/270, granted 24.4
PC7 - 30 work claimed, 30 work done - 250/300
PC8 - 30 work claimed, 30 work done - 280/330
PC9 - 30 work claimed, 30 work done - 310/360
PC10 - 30 work claimed, 30 work done - 340/390, granted 26.2

Now the opposite example, your PC is the 10th to receive the work unit.

PC1 - 30 Work claimed, 30 work done - 30/30 granted/claimed cumulative, granted 30
PC2 - 30 work claimed, 30 work done - 60/60, granted 30
PC3 - 30 work claimed, 30 work done - 90/90, granted 30
PC4 - 30 work claimed, 30 work done - 220/220, granted 30
PC5 - 30 work claimed, 30 work done - 250/250, granted 30
PC6 - 30 work claimed, 30 work done - 270/270, granted 30
PC7 - 30 work claimed, 30 work done - 300/300, granted 30
PC8 - 30 work claimed, 30 work done - 330/330, granted 30
PC9 - 30 work claimed, 30 work done - 360/360, granted 30
PC10 - 70 work claimed, 130 work done- 430/490, granted 114

You see the effect of the first PC is fairly quickly drowned out. Now keep in mind that there would be hundreds or thousands of PCs running each work unit type.

Something like that anyway. With a 6 hour work unit, you'll never be the first, or even the 10th, to return a work unit, most likely the 100th.

37) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 33724)
Posted 29 Dec 2006 by MikeMarsUK
Post:
...Which would only happen if everyone else's RAC is also dropping. So you would think that if it's only me then other people should be passing me in the overall world rankings.
...


Not a great drop, less than 10%?

If the mix of computers (Linux vs. Windows vs. Apple, and Intel vs. AMD) were changing, then there could be a drop or rise in granted credit as a result. Now, a lot of people are home at christmas from University, and simultaneously people are taking time off from work at Christmas and so forth. Not suprising the mix of PCs has changed.

Secondly, if the mix of Rosetta jobs were changing (i.e., bigger or smaller memory requirements due to the number of amino acids being modelled, different working set size due to algorithm changes), then it'd have a similar effect.
38) Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06 (Message 33722)
Posted 29 Dec 2006 by MikeMarsUK
Post:
...

To test my theory, i ll be shutting down my 2 computers for a week in January, and we will see if the RAC goes up for the rest of the people. I ll go and process some seti for a week , with my new SSSE3 code :) hehehhe


No need to shut down your PCs, the credit/RAC doesn't work like that.

If your claimed credit is roughly in line with your received credit, then you won't be affecting the overall credit calculations at all (since the benchmark would be in line with the actual work done - granted credit is the cumulative average of claimed credit versus actual work done).

If your claimed credit were way below the granted credit (i.e., very poor benchmarks but good progress on the Rosetta code), then you could theoretically be affecting the overall average of granted credit, but it'd be a very small effect unless you happened to grab one of the first few of a particular strain of work unit.

-- Edit:

For a 6 hour work unit your claimed credit is typically in the 70s, your granted credit is typically in the 130s (=21c/h per core, which is reasonable for a core2. My X2 gets 13-14c/h per core which is OK given it's now a generation behind). If you happened to pick up the very first one of a new batch of work units, and returned it before anyone else, then the next few people may be slightly affected, but after a few more PCs have crunched it, there'd be no detectable alteration in granted credit.
39) Message boards : Number crunching : Claimed -vs- Granted Credit (Message 33536)
Posted 27 Dec 2006 by MikeMarsUK
Post:
@The Bad Penguin: What sort of memory do you have in your PC, what are the timings, 1T or 2T, and does it have two sticks or 4 sticks? (Note that if you have AMDs, it often drops down to the next setting with 4 sticks. So DDR400 may be downgraded to DDR333).

I don't know about Rosetta, but on the CPDN project the memory has a bigger impact on modelling speed (and hence credit) than the processor clock. Looking at the figures you're giving, I suspect memory speed is just as important here. My credit/hour is consistent with Conan's.

When I was overclocking my PC, I optimised it for memory first, and processor second.
40) Message boards : Number crunching : Overtake ? (Message 33429)
Posted 25 Dec 2006 by MikeMarsUK
Post:

It doesn't seem to be displayed on the image you linked to. But 'overtake' typically refers to when you will pass the person next higher than you in the 'total credit' list (either within your team or within the project).


Previous 20 · Next 20



©2023 University of Washington
https://www.bakerlab.org