|
|
Posts by Ingleside
1)
Message boards :
Number crunching :
Hyperthreading
(Message 46244)
Posted 5 days ago by Ingleside
Haven't benchmarked resently, but did benchmark my i7-920 when it was new. It's running stock speed, 6 GB memory in triple-channel-mode and probably at 1066 MHz-memory-speed. Benchmarked on, if not mis-remembers, a Hadam3P-model, since AFAIK it was before the various regional models was released. In any case, the results are:
1 instance to 1st. trickle: 6237 seconds/trickle.
4 instances to 3rd. trickle and averaging: 8456 seconds/trickle.
8 instances to 3rd. trickle and averaging: 14002 seconds/trickle.
Meaning, running 4 instances it's performing as a 3-core-computer, while running 8 instances it's performing as a 3.5-core-computer. The advantage of running 8 over 4 instances was 21%.
The benchmarking was done without any turbo-boost (don't even remember if it has turbo at all...), and the same model was re-run from beginning to remove any effects from variable speed during a model and between models.
As for the i3770K not having the same HT-effect, my 1st. suggestion would be turbo-boost, but if you've disabled this... Another possibility is, the i7-920 is triple-channel, even at 1066 MHz it's got the same total bandwidth as the i3770K running at default dual-channel 1600 MHz-memory-speed. Since the cpu is also faster, it's possible the memory-bandwidth is saturated earlier than on the slower i7-920.
|
2)
Message boards :
Number crunching :
Several jobs uploads in project backoff
(Message 46153)
Posted 18 days ago by Ingleside
You have exploded an urban myth!
Well, some myths are easy to bust...
|
3)
Message boards :
Number crunching :
Several jobs uploads in project backoff
(Message 46151)
Posted 18 days ago by Ingleside
The time limit for uploading files from any project was extended. I can't remember whether the limit is now two or three months, but in any case it's far longer than we need.
It's 90 days.
But, but, but... each file is still only allowed 100 upload attempts, after which it expires. That's the BOINC rule. 100 is plenty but please don't use up the files' lives by repeatedly pressing the Retry now button in the Transfers tab. The files come to no harm while they wait.
I've never seen anything to a "100 upload attempts"-rule, and seeing how a file can easily reach this limit in 4 days (assuming re-tries once per hour), it wouldn't make any sence to increase the limit from 14-day to 90 days in this case.
To do a little test, blocked internet-connection and hit "retry" on a SIMAP-upload 110 times... no problem. Did a little editing, and, as BoincTask happily shows, it's now retried... 1234567 times, hits retry, 1234568 times, 1234569 times, 1234570 times, 1234571 times...
Since 1234567 >> 100 I didn't see anything to any 100-retry-limit on uploads...
|
4)
Questions and Answers :
Windows :
Intel Visual Fortan run-time error
(Message 45916)
Posted 39 days ago by Ingleside
For the "killer trickle" to be sent to the correct target, that target, i.e. climate model, needs to return a trickle_up file for the server to find it.
As has been said, this is unlikely to happen, so they CAN'T be killed from the server.
Aborting tasks without relying on trickle-messages has been part of BOINC since around BOINC-Client v5.10.x.
|
5)
Message boards :
Number crunching :
Download Checksum Error
(Message 45823)
Posted 46 days ago by Ingleside
Got atleast one old wu including white-space as part of the MD5 and v7.0.60 didn't give any MD5-errors, so looks like the fix works as it should.
While there wasn't any MD5-errors, the wu did still error-out, but this was due to one of the files missing from server. Copying the link to the web-browser also gave 404 Not Found, so this isn't a client-problem.
|
6)
Message boards :
Number crunching :
Download Checksum Error
(Message 45812)
Posted 47 days ago by Ingleside
Have only managed getting assigned one model since upgraded to v7.0.60, but atleast no download-errors this time. Wu is from December and is wherefore old.
Since have done another scheduler-request after getting the new model, can't check if the scheduler-reply included white space as part of the md5.
|
7)
Message boards :
Number crunching :
Upload stops at 10MB with HTTP error
(Message 43803)
Posted 462 days ago by Ingleside
Uploads can stack up indefinitely and not be lost, true?
Not completely indefinitely, if you're running an old BOINC-client the cut-off is 14 days from 1st. upload-try of each individual upload, while with v6.10.0 and later BOINC-clients the cut-off has been extended to 90 days.
|
8)
Message boards :
Number crunching :
Project file upload handler is missing.
(Message 43752)
Posted 472 days ago by Ingleside
Or so I thought,
I have just been through a copy of clientstate.xml without finding a misspelling of handler. I am still getting the message Project file upload handler is missing.
I have tracked down the zip file in question in the .xml file but am afraid it makes little sense to me, other than that the file is not transferring which I could tell by looking @ the transfers tab.
I am quite happy for someone to point out something in the portion of the file which is bleeding obvious, even if not to me.
Hmm, is it the computer running v6.13.10?
If so, the 1st. step is to upgrade to v7, since v6.13.10 has some major bugs, among others with handling of trickle-uploads.
If after the upgrade to v7 this file is still stuck without uploading, try changing the status-part from zero to 1, as shown below:
<upload_url>http://uploader1.atm.ox.ac.uk/cpdn_cgi/file_upload_handler</upload_url>
</file>
<file>
<name>hadam3p_eu_8h04_2000_1_007687181_0_4.zip</name>
<nbytes>13743083.000000</nbytes>
<max_nbytes>150000000.000000</max_nbytes>
<md5_cksum>41130e8681805ab6432ca43cea075478</md5_cksum>
<status>1</status>
<upload_url>http://uploader1.atm.ox.ac.uk/cpdn_cgi/file_upload_handler</upload_url>
<persistent_file_xfer>
<num_retries>14</num_retries>
<first_request_time>1327526537.473585</first_request_time>
<next_request_time>1328311850.488157</next_request_time>
<time_so_far>295.883478</time_so_far>
<last_bytes_xferred>0.000000</last_bytes_xferred>
<is_upload>1</is_upload>
</persistent_file_xfer>
Dave
|
9)
Message boards :
Number crunching :
More FPU or Integer Power needed?
(Message 43444)
Posted 548 days ago by Ingleside
My recommendation was based on what we have seen on cpdn. A Core i7 920 (hardly a high end processor) can beat a higher priced Phenom II X6 1100T in total throughput of models.
Hmm, in my experience the i7-920 and X6-1090T performs similarly, but the X6-1090T has decidedly a big advantage then it comes to cost of buying. Just for the cpu the i7-920 was 33 % more expensive than the X6-1090T, and also other things like mainboard and memory was more expensive for i7-920 than for Amd.
Now, atleast around here no-one has sold any i7-920 for the last year atleast, but let's look on the current entry-level offering from intel among the i7-cpu's, the i7-2600K. The i7-2600K is 44 % more expensive than an AMD's X6 1100T. No idea how fast the i7-2600K is, but would still guess it's less than 40 % faster...
A hex-core intel-cpu should be faster, but is also much more expensive. Also, running multiple memory-hungry CPDN-models will have an impact on performance, so it's not certain a hex-core gives much higher performance than a quad-core does.
|
10)
Message boards :
Number crunching :
Set no gpu option
(Message 43177)
Posted 591 days ago by Ingleside
I don't think that the server version is sufficiently up to date for the "no gpu" code.
CC_config can apparently be set on user's computers to do the same thing.
Unfortunately in v6.12.xx and earlier clients, users can't disable individual projects from using GPU's, the available cc_config-options will disable GPU's for all projects. Seeing that MarkJ runs GPUGRID and Byron runs SETI@home, neither of them would want to disable GPU-crunching on their computers.
Disabling GPU-crunching for individual projects is an option in v6.13.x, but these clients is alpha-clients with many rough edges, so for anyone not being alpha-testers it's recommended to stay away from these clients for now. Atleast from the look of things, GPUGRID doesn't currently work with v6.13.x-clients, since it's one of the many projects that haven't disabled upload-certificates yet.
|
Next 10 posts
|
|
