App 9.18 seems to take way longer to get the same WUs done than 9.15, is there an explanation behind this? Upwards of 20-30% longer

My WUs are running for around 27h on my GTX 660 Ti cards. I cannot use my 650 Ti cards as the run time is much higher. I guess my days at GPUGrid may be drawing to a close as these cards can't keep up.
____________
John

If I compare the crunching times of 918-80 with what they were before with 847-65 / 848-65, I, too, notice a considerable increase.
This is true for my GTX750ti on Windows10 and the GTX970 on Windows 10 - they now need about 30% longer :-(

Since at the same time I had to update the drivers to 381.65, it's hard to say whether the raise in crunching time is mainly due to the new acemd version, or mainly due to the new driver, or both.
What could also be the case is that, for what reason ever, the WDDM overhead now has a much more negative effect.

Hence, the main question seems to be whether anything can be done in order to get the former speed back.

What concerns the change from 847-65 / 848-65 to 849-65 for Windows XP, no WDDM overhead, (one GTX750ti and two GTX980ti), the crunching times seem to be only slightly higher than before.

Would be interesting to hear how the situation is with Linux.

Would be interesting to hear how the situation is with Linux.

But I don't see the page listing the applications at the moment. Either I am not looking in the right place, or maybe they are updating it.

Didn't they have a separate page listing all the apps for Window, Linux, etc, along with the dates? I thought so, and I saw that the Linux 9.14 version came out last year. Or else I am just imagining it; maybe I got it right? Who knows.

With the lack of Pascal Windows XP support, and now with the dramatic slowdown of WDDM modern windows OS's. It looks like we must change our crunching rigs to linux as it is still running the 9.14 app, with no WDDM and no 9.18 slowdown.

... It looks like we must change our crunching rigs to linux as it is still running the 9.14 app, with no WDDM and no 9.18 slowdown.

but who can tell how long Linux will be running the 9.14 app - before changing to 9.18 or any newer (and also slower) app maybe in the near future?

But I don't see the page listing the applications at the moment. Either I am not looking in the right place, or maybe they are updating it.

You can find them here.

If I compare the crunching times of 918-80 with what they were before with 847-65 / 848-65, I, too, notice a considerable increase.
This is true for my GTX750ti on Windows10 and the GTX970 on Windows 10 - they now need about 30% longer :-(

Since at the same time I had to update the drivers to 381.65, it's hard to say whether the raise in crunching time is mainly due to the new acemd version, or mainly due to the new driver, or both.
What could also be the case is that, for what reason ever, the WDDM overhead now has a much more negative effect.

Hence, the main question seems to be whether anything can be done in order to get the former speed back.

What concerns the change from 847-65 / 848-65 to 849-65 for Windows XP, no WDDM overhead, (one GTX750ti and two GTX980ti), the crunching times seem to be only slightly higher than before.

Would be interesting to hear how the situation is with Linux.

I think you have it backwards. The "long" category is for the latest cards, which the GTX 750 Ti is not. It is wonderful for efficiency (I have several), but it is not a powerhouse. So use it on "shorts", where it can do its thing.

I know, there are not enough shorts to keep it busy. That is a consequence of the science they need to do. Rule #1 for me is that we are here to help them. They are not here to provide us something to do with our cards.

PS: An extra category for "extra longs" is a good idea, but it won't save the GTX 750 Ti.

PS: An extra category for "extra longs" is a good idea, but it won't save the GTX 750 Ti.

PS: An extra category for "extra longs" is a good idea, but it won't save the GTX 750 Ti.

But it would help to assign to the GTX750ti those "longruns" which are not that much of a problem for it :-) (and there are still many of such task around)

I guess you are saying that they could then exclude those extra long runs. So it could be a good idea with that in mind.

PS - I just pulled a GTX 750 Ti out and replaced it with a GTX 1060 on my Win7 64-bit machine. Too bad the app is not optimized for it now, but I will try it later.

I also was playing with the same idea. However, I am unsure now, particularly after you are saying "the app is not optimized for it now" - what exactly do you mean?

If I compare the crunching times of 918-80 with what they were before with 847-65 / 848-65, I, too, notice a considerable increase.
This is true for my GTX750ti on Windows10 and the GTX970 on Windows 10 - they now need about 30% longer :-(

Since at the same time I had to update the drivers to 381.65, it's hard to say whether the raise in crunching time is mainly due to the new acemd version, or mainly due to the new driver, or both.
What could also be the case is that, for what reason ever, the WDDM overhead now has a much more negative effect.

Hence, the main question seems to be whether anything can be done in order to get the former speed back.

What concerns the change from 847-65 / 848-65 to 849-65 for Windows XP, no WDDM overhead, (one GTX750ti and two GTX980ti), the crunching times seem to be only slightly higher than before.

Would be interesting to hear how the situation is with Linux.

In view of the above-said, plus my experience from the last three weeks, I strongly suggest that in the preferences for download of tasks, beside "short runs" and "long runs", a third category like "extra long runs" or similar, should be introduced.

A typical candidate for such an "extra long runs" would be "ADRIA_FOLDGREED90_crystal_ss_contacts_100_ubiquitin..."
which on my GTX750Ti in the Windows10 machine takes close to 60 hours (on Windows XP with software 849-65 and an older driver, crunching time is considerably shorter).

Beside the extremely, if not rediculously long crunching time, crunching these sort of tasks with the GTX750Ti on Windows10 is rather unstable. Even the slightest overclocking can lead to immediate halts - the only thing one then can do (as soon as one finds out, which might take a while - for example over night) is to suspend and restart the task. So it's been the case here that the total time for such a task was 3 days! Forget about it! A GTX750ti on Windows10 is definitely overtaxed with such a task.

Hence, crunchers with smaller/older cards would definitely wish to exclude tasks like the "_100_ubiquitin..." from download.
Be it coinsidence or not: what I have watched all time long was that my two GTX750Ti tend to receive such long tasks almost all the time, whereas my GTX980Ti's get smaller tasks (like the "Adria") as well. No idea why, it just seems worth to be mentioned (maybe someone knows more about this phenomen).

Anyway, at the bottom line: while it's clear that we crunchers should not be allowed to choose a specific type of task (this clearly remains in the priority determination of the GPUGRID people), a third category "extra long runs" would help quite a lot.
As everyone can imagine: total running time of nearly 3 days is rather frustrating, besides that it does not make a whole lot of sense :-(

...
any thoughts from GPUGRID side on my suggestion above ?
Good idea - bad idea ?
Feasible - not feasible ?

...
any thoughts from GPUGRID side on my suggestion above ?
Good idea - bad idea ?
Feasible - not feasible ?

still no reaction whatsoever from the GPUGRID team - why so?

the Pascals dont's work with the NVIDIA Inspector

Wrong, worked just fine with my GTX1060 and nwo with my GTX1070.

is my idea/suggestion that bad that it's not even worth being considered to be implemented?

Well.. the current project team is not the most active in the forums, so I suspect they didn't even notice your request.

Personally I agree that it's strange to alost not use the short runs queue at all and have long runs which differ by more than a factor of 2 in the runtime. That's clearly two different WU categories, so if they don't want to introduce a 3rd tier they could at least use the 2 which they already have.

BTW: on topic.. has there been any change notification from 9.15 to 9.18? Maybe they fixed some bug or added a feature, which resulted in more work being needed?

But there is an interesting discussion on the BOINC forum between him and boboviz (among others) that touches on some of these issues.
http://boinc.berkeley.edu/dev/forum_thread.php?id=11647&postid=79043#79043

No, I don't read it that way at all. They don't have the people (particularly with the BOINC expertise) to fix it. But on the other hand, why not go back to the old app for Windows? Maybe that would provide more output, or maybe just more confusion at this point.

They don't have the people (particularly with the BOINC expertise) to fix it.

they're mainly scientist interested in doing good science.

an almost complete lack of communication