As with my new Q9550, this situation with regard to your initial workload means your RAC competitiveness will be overstated, initially.
On a less discouraging note, since my Q9550 and your new i7 are both reporting exclusively near the valley, it is reasonable to compare them.
On a sample size of nearly 200 results, my Q9550 in Windows 6.05 is taking 22,000 seconds per valley results.
You are taking 34900, or dividing by two to account for hyperthreading, about 17450 core seconds. So your stock i7 920 is 26% more productive than my stock 2.83 GHz Q9550 on Windows 6.05 at your current settings, I think. I don't plan to overclock mine, but I would not be surprised if you have more OC headroom than I do. After all yours is the bottom spec Intel is selling, mine is not.
I think CPDN is among the more demanding projects, RAM wise (200 MB last time I checked which is some time ago, tho). With an i7 quad core (so 8 threads) plus Windows Vista, you would probably like to have more than 2GB RAM to have enough headroom. If you have to use the swap file to satisfy memory needs of the apps, the superior RAM bandwidth of Nehalem won't help that much really.
My RAM bandwidth comment was sloppy thinking--thanks for catching me on it.
On the other had, 3 Gigabytes of 1.65V or less DDR3 is about the smallest configuration folks are offering specifically aimed at Nehalem, and the cheapest NewEgg offering at this point is already down to $110.00, so not too worrisome a requirement.
I think there will be a lot of 3 Gbyte consumer Nehalem systems at first--going appreciably higher means a 64-bit OS, which still means some limitations on driver and application availabiity.
I noticed that the runtimes in the WUs done so far were extremely flat, and am wondering if I'm just in a valley or if the high memory bandwidth of the Nehalem architecture is smoothing out the runtimes.
Valley.
For your frequency, the predicted cycle length is 191, so the twin peaks surrounding your data should be at 382 and 573.
Your reported results so far are from between 473 and 490, so really, really far from the steep parts, and very near the predicted (broad, flat) valley bottom near 477. Sadly this means Ready Reckoner won't be able to get a useful fit to your data.
DOH!
Would 805.15 315-408 be any more useful? I found what I think is the most recent version of the RR, but I'm not sure how to use it.
Would 805.15 315-408 be any more useful? I found what I think is the most recent version of the RR, but I'm not sure how to use it.
Yes, that span includes 382, the predicted peak. If it is convenient for you to put a bunch of results in suspended states, and preferentially run some others, then intentionally running something like:
381
383
375
389
369
395
363
401
would probably be enough to get a pretty good first estimate of behavior, in conjunction with the valley stuff you have run already.
While BOINCView has some bugs and oddities, one thing that is really nice about the last version issued before the developer stopped putting out new releases (1.5 Beta 8) is that it allows multi-select Windows style of tasks in queue for operations such as suspend, resume, and abort. I'm not sure how much earlier he put in this feature, but it was not in the last non-beta release I ran.
While BOINCView has some bugs and oddities, one thing that is really nice about the last version issued before the developer stopped putting out new releases (1.5 Beta 8) is that it allows multi-select Windows style of tasks in queue for operations such as suspend, resume, and abort. I'm not sure how much earlier he put in this feature, but it was not in the last non-beta release I ran.
I'm not entirely sure what you are talking about but I think the latest (beta) boinc versions have this feature too
While BOINCView has some bugs and oddities, one thing that is really nice about the last version issued before the developer stopped putting out new releases (1.5 Beta 8) is that it allows multi-select Windows style of tasks in queue for operations such as suspend, resume, and abort. I'm not sure how much earlier he put in this feature, but it was not in the last non-beta release I ran.
I'm not entirely sure what you are talking about but I think the latest (beta) boinc versions have this feature too
Not beta, but the 6.2.x series have it, so I presume that all the 6.x release will carry this capability. However, they can't connect to multiple clients at the same time.
pasting that into the 7g RR input box and pressing the "use inputs" button promptly got me this:
As you can see cyclic behavior remains very much a part of the picture. The "Variance = .208" value is a representation of the degree of variation--working from memory I think that is well in the range of historic observations.
I chose not to include all the valley points you had collected, for fear that Mike's computation would be distracted into trying to fit the wiggles and noise among them, rather than fitting the major peak to valley feature. To my eye his fit appears quite good in this case. Your ability to provide points surrounding a peak and going down a decent distance form the peak really helps.
Mike, if you see this please comment if there is something beyond 7g we should be using. Also, the copy I downloaded today still has an internal headline and some other tagging describing it as for "S5R3" while I think the default constants and such are actually S5R4-specific.
To those not Mike: you can find a copy of the handy piece of HTML which generated this graph at: Mike Hewson's RR 7g page
RE: As with my new Q9550,
)
On a less discouraging note, since my Q9550 and your new i7 are both reporting exclusively near the valley, it is reasonable to compare them.
On a sample size of nearly 200 results, my Q9550 in Windows 6.05 is taking 22,000 seconds per valley results.
You are taking 34900, or dividing by two to account for hyperthreading, about 17450 core seconds. So your stock i7 920 is 26% more productive than my stock 2.83 GHz Q9550 on Windows 6.05 at your current settings, I think. I don't plan to overclock mine, but I would not be surprised if you have more OC headroom than I do. After all yours is the bottom spec Intel is selling, mine is not.
RE: I think CPDN is among
)
My RAM bandwidth comment was sloppy thinking--thanks for catching me on it.
On the other had, 3 Gigabytes of 1.65V or less DDR3 is about the smallest configuration folks are offering specifically aimed at Nehalem, and the cheapest NewEgg offering at this point is already down to $110.00, so not too worrisome a requirement.
I think there will be a lot of 3 Gbyte consumer Nehalem systems at first--going appreciably higher means a 64-bit OS, which still means some limitations on driver and application availabiity.
RE: RE: I noticed that
)
DOH!
Would 805.15 315-408 be any more useful? I found what I think is the most recent version of the RR, but I'm not sure how to use it.
http://downloads.mikehewson.id.au/readyreckonerv7g.html
edit: Yes, I've got a really long queue at the moment.
RE: Would 805.15 315-408
)
Yes, that span includes 382, the predicted peak. If it is convenient for you to put a bunch of results in suspended states, and preferentially run some others, then intentionally running something like:
381
383
375
389
369
395
363
401
would probably be enough to get a pretty good first estimate of behavior, in conjunction with the valley stuff you have run already.
While BOINCView has some bugs and oddities, one thing that is really nice about the last version issued before the developer stopped putting out new releases (1.5 Beta 8) is that it allows multi-select Windows style of tasks in queue for operations such as suspend, resume, and abort. I'm not sure how much earlier he put in this feature, but it was not in the last non-beta release I ran.
RE: While BOINCView has
)
I'm not entirely sure what you are talking about but I think the latest (beta) boinc versions have this feature too
RE: RE: While BOINCView
)
Not beta, but the 6.2.x series have it, so I presume that all the 6.x release will carry this capability. However, they can't connect to multiple clients at the same time.
RE: 381 383 375 389 369 39
)
Done. Unless I forget the results will be uploaded between 6:30 and 7:30am EST tommorrow.
RE: Done. Unless I
)
Or not. Looks like about 11.5hrs runtime they're not going to finish before I leave for work.
Here they are. 805.15 363:
)
Here they are. 805.15
363: 41269s
369: 41616s
375: 42942s
381: 43609s
383: 43693s
389: 42725s
395: 42114s
401: 40889s
RE: Here they are.
)
Fair enough.
I put the data above into the CSV format required for RR input, and added four points spaced throughout the previous valley data, ending with this:
pasting that into the 7g RR input box and pressing the "use inputs" button promptly got me this:
As you can see cyclic behavior remains very much a part of the picture. The "Variance = .208" value is a representation of the degree of variation--working from memory I think that is well in the range of historic observations.
I chose not to include all the valley points you had collected, for fear that Mike's computation would be distracted into trying to fit the wiggles and noise among them, rather than fitting the major peak to valley feature. To my eye his fit appears quite good in this case. Your ability to provide points surrounding a peak and going down a decent distance form the peak really helps.
Mike, if you see this please comment if there is something beyond 7g we should be using. Also, the copy I downloaded today still has an internal headline and some other tagging describing it as for "S5R3" while I think the default constants and such are actually S5R4-specific.
To those not Mike: you can find a copy of the handy piece of HTML which generated this graph at: Mike Hewson's RR 7g page