SETI@home News Vol. 112 (08/08/2010)

Grimgoth said:
Its very difficult to standardise with no canonical work unit for lets say turn around time. Or claimed credit. Maybe what we could do is take the granted credit that we know which card/cpu crunched on what configuration, and take an average of 100 work units?
although i am not sure for my system of mixed gtx260/285/295 I will be able to tell which goes with which.
Click to expand...

Granted credit/second (or minute, or whatever works best). Since credit is given based on some numerical analysis of the work done, this should (in theory) be constant across all workunits (provided you ignore VLAR work, which happens by default now anyway).

This will take some calculating though (you'd be best to do it over, say, an hour).

ReaVerUK said:
or the team being abolished :mad:
Click to expand...

Not happening - at least not on my (temporary) watch. It looks like someone may have been inclined to try it, but they proved to be the Weakest Link. Goodbye!
 
Happy Birthday Tross, now make a wish..........

wishi.png
 
best wishes for the day TT. hope its a good one.

I would dearly like some sort of comparisons, because it feels to me like all my machines seem to be underperforming compared to everyone elses :p
 
Grimgoth said:
..... it feels to me like all my machines seem to be underperforming compared to everyone elses :p
Click to expand...

I have problems of my own, just had a letter from my electricity supplier to say there will be an outage on friday to repair a fault so I will probably be off for most of the day :mad: :(

Thats on top of the outage we had in the early hours of Tuesday morning, this was supposed to be my chance to close the gap on Toxic :(
 
Well, I've done my test and it looks like it works. Basically, I took the report_deadline entry for a task that I had already processed (whose deadline date was 18/9), and inserted it into a task that had a deadline of 3/10 and was unprocessed. I then re-started processing, and pushed the client into high priority mode (by telling it to connect every 40 days). The amended task was picked up and is processing as I type this (I will set it back to its original date after it finishes just to make sure everything is square with Berkeley).

What this means is that if we wanted to use a standard task to benchmark GPUs, we can use any task, and just insert a deadline that is convenient to us, so that we can process the task immediately (by using high priority mode). Obviously, the range of deadline dates available is limited to what people have in their caches(?) since I do not have the time or inclination to go through the source code to find out how they encapsulate the deadline into a single number, but at least there is the option should we choose to take this approach.....
 
Area_51 good work.. :)

Anyone who wants access to that spreadsheet to stuff things into it let me know and I'll add you as an editor if you have a google account.
 
Area 51 said:
Well, I've done my test and it looks like it works. Basically, I took the report_deadline entry for a task that I had already processed (whose deadline date was 18/9), and inserted it into a task that had a deadline of 3/10 and was unprocessed. I then re-started processing, and pushed the client into high priority mode (by telling it to connect every 40 days). The amended task was picked up and is processing as I type this (I will set it back to its original date after it finishes just to make sure everything is square with Berkeley).

What this means is that if we wanted to use a standard task to benchmark GPUs, we can use any task, and just insert a deadline that is convenient to us, so that we can process the task immediately (by using high priority mode). Obviously, the range of deadline dates available is limited to what people have in their caches(?) since I do not have the time or inclination to go through the source code to find out how they encapsulate the deadline into a single number, but at least there is the option should we choose to take this approach.....
Click to expand...

Nice work s'ah
How does it work - can you assign it to the cpu or gpu? This could be an excellent way of benching hardware - nice one..
 
Well, my output over the outage will be a little lower than normal.

Have transferred my rig into a new Fractal Design Black Pearl - along with a new PSU (Silverstone Strider 850w).

Wiring is a mess - but as it's hidden behind the motherboard tray - I don't care.

Had a bit of trouble with an old ide hdd - until I realised I had the jumper on the wrong pins.

What should I do now?
 
Thanks for all the birthday wishes :)

Tried to get up to Kendal for the day but couldn't thanks to the M6 being shut and the whole of Preston and the surrounding area subsequently being at a complete standstill... so ended up going the other way to Southport for a stroll along the sea front :D
 
TheTross said:
Thanks for all the birthday wishes :)

Tried to get up to Kendal for the day but couldn't thanks to the M6 being shut and the whole of Preston and the surrounding area subsequently being at a complete standstill... so ended up going the other way to Southport for a stroll along the sea front :D
Click to expand...

Why, oh why would anyone want to go to Kendal?

Unless you want to go on the one way merry-go-round they call a town centre......

Happy B'Day btw :D
 
edgedemon said:
Nice work s'ah
How does it work - can you assign it to the cpu or gpu? This could be an excellent way of benching hardware - nice one..
Click to expand...

I'm not sure I understand your question - but I'll take a punt. Basically, a task has a deadline (wow really?), but the deadline isn't 'tied' to the task. The deadline is only represented in the client_state.xml file once - and nowhere else. So, a task can be re-processed as many times as required, on as many platforms as required simply by assigning a new deadline to it (and yes, tasks can very easily be shuffled between CPU and GPU - that's very easy to do) and squirting it into the relevant client_state.xml. My thoughts were to find one of more tasks that fit the bill for benchmarking (not sure how they would be selected), and then write a simple little perl script to inject the task into client_state.xml along with a new deadline that isn't too far into the future. Then, the client is pushed into high priority mode (by abusing the network connection setting), and the task is processed. Voila. Another perl script would then be done to remove the task and its result file, and you're done! :D

The perl scripts would be a very easy job. The only thing that is a bit tricky is getting a pile of valid deadlines, since these are represented in client_state.xml using some bizarre numeric format that I can't fathom....
 
but area, it doesn't really matter if the dateline has been passed- I go overdue sometimes on some tasks, and all you get is a message that you should consider aborting task as you might not get credit for it.
as long as we are not connected to the net while we benchmark, (which we won't be anyway) this is all that happens?
edit: and while we are here, why not plan to customise the benchmarking, so that we can get a real taste of the pc; have the same tasks multipled for 2, 4, 6, 8, 12 threads (or evenmore) for the cpu, and 1,2,3,4,5,6,7,8,etc numbers for gpus- and then we just time the whole shebang.
 
You must log in or register to reply here.
Back
Top Bottom