There have been not substantially changes in the size of WUs.
In particular the one I am running have the same length of many of the past.

Best way to check speed is to look for another computer which runs the same group of WUs. The tag of the workunit gives it up:

name-group-etc-etc

gdf

TI wish it were otherwise, but, sometimes the latest and greatest isn't ...

That is why, unless there is a compelling new feature you MUST have, it is usually best to wait at least 30 days before adopting a new version. The problems with a version don't always come out in the first few days, unless it is glaring and major.

The more subtle issues are harder and thus take longer to figure out what is going on.

The only reason I always suggest 6.5.0 over the 6.4.x versions is that there is no need for the configuration file hacks to get the GPU running.

This is why I am still running 6.3.21.

I can not find any indication that any newer release is any better, and most appear to be worse.

This is why I am still running 6.3.21.

I can not find any indication that any newer release is any better, and most appear to be worse.

Well, 6.5.0 is good enough that I have found no issue with it yet that other versions don't also have.

Or, to put it another way, there are no new and unique issues with that version. But, if yours works for you ... :)

this is old :

522140 369932 16 Apr 2009 1:49:24 UTC 17 Apr 2009 8:02:26 UTC Over Success Done 1,320.89 2,883.44 4,613.50

then the newer came :


592920 416850 27 Apr 2009 21:49:19 UTC 28 Apr 2009 17:24:51 UTC Over Success Done 1,664.50 3,843.30 4,804.12
587989 414037 26 Apr 2009 23:11:14 UTC 27 Apr 2009 21:45:17 UTC Over Success Done 1,683.81 3,843.30 4,804.12
587883 414011 26 Apr 2009 23:11:14 UTC 27 Apr 2009 16:13:23 UTC Over Redundant result Cancelled by server 0.00 --- ---
583337 410986 25 Apr 2009 23:43:01 UTC 27 Apr 2009 1:12:17 UTC Over Success Done 1,307.28 3,946.78 4,933.48
580325 407937 25 Apr 2009 9:41:06 UTC 26 Apr 2009 5:31:13 UTC Over Success Done 1,661.56 3,946.78 4,933.48
574507 407246 24 Apr 2009 7:18:54 UTC 25 Apr 2009 2:52:59 UTC Over Success Done 1,503.06 3,844.58 4,805.73
570199 405183 23 Apr 2009 11:18:40 UTC 24 Apr 2009 7:18:14 UTC Over Success Done 1,760.33 3,946.78 4,933.48
561277 400709 22 Apr 2009 11:43:26 UTC 23 Apr 2009 8:13:11 UTC Over Success Done 1,964.63 3,843.30 4,804.12

So in general it went from 1300-1500 seconds of cpu time to 1600-1960 seconds cpu time as you can see the newer units only get marginaly more. but less then the when it returns faster.
I assume i get less bonus because the return time is now over 24 hours, or something like that.
Since the largest units gets less then the one running for 1370 seconds (4933 points) 1600- 1900 seconds work get 4800.
As i am guessing is that 100 seconds more time here in GPU time about an hour of work more or less, and thats about what i see
The last unit ended after 26 hours of crunching and the new one i received is going to pass that.
Since it shows more hours to go after it allready run for the same time what i noted on the previous.
This is unit p1020000-IBUCH_pYIpYVk52804-1-10-RND3781_0 the previous was a GIANNI with also RND on the end.

Just to let you all know that there are some much longer WUs out there. I just finished this one:

88-KASHIF_HIVPR_dim_ba5-0-100-RND6765_0

It took a little under 14hrs on an overclocked GTX260 (1512 shader) and one of the finish files was 50MB+. It all took 20mins to upload.

Claimed credit 8076.97800925926
Granted credit 10096.2225115741


Mark

Wow me scared if i ever got one of those :D
But i probably won't receive such units :D, because i think it will pass my deadline for at least 200 hours ;)
You have a powercard i have the slowest possible one xD
Btw i have also the problem to get my cpu's to run MW and get units on my VC,
i need to set the get work cache to 10 days to get enough work for my 4 cpu's or it runs dry for about 12 hours.
But on the other hand have the problem that i can handle only 1 unit at about 22 to 27 hours, when i leave it gpugrid ofcourse loads new and cancels them some hours later.
So i have to babysit all the time to prevent this from happening i have no clue if the often cancelling of units has any negative effect for the project.
And if you look at your stats it looks kinda weird so many cancelled out units.

I have some of the longer KASHIF_HIVPR and TONI_HIVPR Wu's on my system now. They list at 10+ hours instead of 7-8 in boincs guestimate of runtime. I have also noticed in general my sytems slowing down with time. Wu's are creeping up. Im guessing its something to do with how long my system is on for between reboots. This is Vista im sure it has plenty of ways to spoil things. Really must get Linux dual booting on this thing and keep Vista for games.

I have a few KASHIF_HIVPR_xxx WUs... It seems that they need triple time - but I earn only the double points... Is this possible?

Kind regards

Joe

@uBronan

Looking at the cpu time does not tell you everything. Go to "your account/my computer/pc xxxx/results" where you can click each of them. Near the bottom is the line "# Approximate elapsed time for entire WU: xxxxx s", which is what you should be looking at. The cpu time could depend on many things.
For example your current last WU lists 70870s, which is 19:41h - a nice time for a 9600GT. Which, by the way, is not the slowest card ;)

And you have problems to get cpu WUs for Milkyway because the ATI GPUs rip every single WU out of their hands, as soon as it's generated. It actually doesn't make much sense to run such WUs on cpus any more. What do you mean by VC?

To reduce your scheduling problems you should probably reduce your GPU-Grid ressource share to not more than 25% of what the cpus get over all projects or 20% of the entire share.

@GDF & all

I also had a "KASHIF_HIVPR" unit. It did run for 25h instead of the usual ~12h (108% longer). The credits do reflect this increase in time: 110% more. So things seem to be fine, except that I'm not sure if this was an intended change (maybe to reduce up- and download traffic and server load). I thought the previous balance of aiming for a runtime of 12h on an 9800GT was quite nice.

MrS

---

Scanning for our furry friends since Jan 2002

@E.T. Ape VC me abit lazy means VideoCard and is almost the slowest then ;)
Hmmm i tend to forget to check inside the results indeed and seem allways to forget that the given times in boinc seems inaccurate.
Sadly the boincview program can't handle the gpu projects also and i can't find any other program which is able to make a nice overview like boincview did.
Browsing every result through these pages is not very handy either.

About this last unit boinc reports it took 24 hours to complete.
So i guess between boinc and the project seem to be a huge difference in reported time needed to complete the unit but i saw some restarts so i guess my system had made some not planned restarts.

I did this KASHIF work unit. Took approx 7.5 hours on a GTX260+. The output file was 29Mb though, so they take a while to upload.

---

BOINC blog

Some of the KASHIF_HIVPR came out a bit too large. There are two types of them. One is of normal length. Resubmitting would mean lose quite a bit of results, so we try to keep going for that batch.

gdf

Yes, I just completed one of them long ones, almost 54 hours of continuous processing on a 9600 GSO video card. No hope of any bonus because of the length of time to complete (still I got 8000+ for it). Looks like I'm going to have to update my video cards.

Looks like I'm going to have to update my video cards.

You don't have to.. the beautiful thing about mistakes is that there's always a finite chance they'll not be repeated regularly ;)

MrS

---

Scanning for our furry friends since Jan 2002

Forgive the dumb question, but just checking the obvious, easy stuff first:

You didn't accidently leave SLI turned on, right? That would reduce the number of GPUs available to CUDA down to 1.

Mike

How do you check the SLI setting and change it if needed? I've never seen it mentioned before, and thought I bought this computer with 2 GPUs included.

Some of the KASHIF_HIVPR came out a bit too large. There are two types of them. One is of normal length. Resubmitting would mean lose quite a bit of results, so we try to keep going for that batch.

gdf

Have you thought of extending the deadline for the longer type in order to let participants return them after the previous deadline and still get credit? From what I've seen on other projects, telling the machine running the workunit about this change after the workunit was sent is not necessary - just changing it at your end.

Another idea is to allow participants to return workunits and get credit if EITHER of the following is true:

1. The results are valid and returned before the deadline.

2. The results are valid and returned before anyone the workunit was reassigned to manages to return valid results.

This will sometimes mean getting more sets of valid results from a workunit than you need; you can then discard any unwanted sets.

Another idea is to allow participants to return workunits and get credit if EITHER of the following is true:

1. The results are valid and returned before the deadline.

2. The results are valid and returned before anyone the workunit was reassigned to manages to return valid results.[/quote]

Thanks for the suggestion, it's already done this way :)

MrS

---

Scanning for our furry friends since Jan 2002

Wow me scared if i ever got one of those :D
But i probably won't receive such units :D, because i think it will pass my deadline for at least 200 hours ;)
You have a powercard i have the slowest possible one xD
Btw i have also the problem to get my cpu's to run MW and get units on my VC,
i need to set the get work cache to 10 days to get enough work for my 4 cpu's or it runs dry for about 12 hours.
But on the other hand have the problem that i can handle only 1 unit at about 22 to 27 hours, when i leave it gpugrid ofcourse loads new and cancels them some hours later.
So i have to babysit all the time to prevent this from happening i have no clue if the often cancelling of units has any negative effect for the project.
And if you look at your stats it looks kinda weird so many cancelled out units.

Just noticed your message from months ago. If you haven't tried it yet, you might want to try my method of setting your computer location differently on some BOINC projects that work better with a short queue, and setting the preferences for that location to maintain a shorter queue. I'm currently using all four locations on the normal list of locations, even though all my computers are in one room.

hiho,

when I request new WU's, i get 4 of a runtime about 10 hrs and 1 with an runtime of 5 hrs, whats about the long runtime WU's, from what i seen/think their credits aint that good as the short ones!

When I request new WU's, i get 4 of a runtime about 10 hrs and 1 with an runtime of 5 hrs, whats about the long runtime WU's, from what i seen/think their credits aint that good as the short ones!

Likewise, my host 43404 got two tasks in the same request for work: the GIANNI-BIND (task 1410010) was estimated to take twice as long as the KASHIF-HIVPR (task 1409994). Yet, as you can see, they finished within 5% of the same time, and the credits were pretty closely in the same proportion - to answer the question in the other new thread.

The key word here, for newly-downloaded tasks, is "estimated". When I first joined this project, those initial estimates were far too low. Gradually, the estimates are being corrected: I think there must have been another correction between 8 October (when my KASHIF wu was created), and 16 October (when my GIANNI wu was created).

Don't fuss too much about the estimates. It's the final run time which matters.