On my dual core cpus running the 30xx SMP WUs I noticed them missing all of the Preferred Deadlines. As Trax recently pointed out, when the WU exceeds the Preferred Deadline it is re-released for processing. I would be willing to wager that the majority of the cpus running the SMP WUs are dual cores. So, unless densign's objective is to cycle these WUs through as many systems as possible the excessively tight deadlines are highly counter productive.

On a semi related topic - WU 2665 = WTF?!? .. They take nearly double the amount of time to process for 2/3 the amount of points of the other 26xx WUs. You want to do WHAT? with my hardware and electricity?

/end of rant

----

edit (09 Nov 2008): I've been meaning to mutate this formerly titled "Excessively tight deadlines" thread into an all purpose work unit info and rant thread for quite a while. And so it finally goes ..

Nah no way, Mr Puma's been folding too long to care just about the points. I'd wager the guy's just inquiring about why something that takes longer is worth less. I mean really the points don't mean anything. We all incur an additional fee for folding after all.

From what i've seen in their comments on work units and the different types of clients they award ppd based on how useful things are to them. It sucks that they'd do that from a point perspective but it could be they're going to correct it later.

Looking for Knowledge wrote:When drunk.....I want to have sex, but find I am more likely to be shot down than when I am sober.

What type of dualcores are you running? AMD X2 3800s are the slowest dualcores I have and I haven't notice much missing deadlines. I have one running win2k SMP and the other 2 are xubuntu 6.04.

farmpuma wrote:On my dual core cpus running the 30xx SMP WUs I noticed them missing all of the Preferred Deadlines. As Trax recently pointed out, when the WU exceeds the Preferred Deadline it is re-released for processing. I would be willing to wager that the majority of the cpus running the SMP WUs are dual cores. So, unless densign's objective is to cycle these WUs through as many systems as possible the excessively tight deadlines are highly counter productive.

On a semi related topic - WU 2665 = WTF?!? .. They take nearly double the amount of time to process for 2/3 the amount of points of the other 26xx WUs. You want to do WHAT? with my hardware and electricity?

First and foremost a major Thank You to kasson for tweaking the points value of the 2665 SMP WUs! Thank you for making them more like the others.

Secondly, to Hewhoiswashin6x9s, You are partially right. The points values assigned to the WUs are a reflection of their science value. So, since points ~= science, the points are a ballpark measurement of our contribution to the science.

Lastly, and my primary point of this thread was the overly tight deadlines of the 30xx SMP WUs which were most likely causing a massive duplication of effort whenever an average dual core cpu was involved. Thankfully this issue appears to be under review.

My dual cores, an X2 4000 @ 2.4GHz and a C2D e4400 currently @ stock and undervolted, have no problem making any of the Final Deadlines, BUT they both failed to make the Preferred Deadlines of the 30xx SMP WUs which caused said WUs to be reissued before I was able to upload the finished data packet. Multiply me times 100,000 and we had a major waste of resources on both ends of the project. BTW, my dual cores have no problem making the Preferred Deadlines of the 26xx SMP WUs.

I apologize for my overly enthusiastic reaction to the points increase for the 2665 work units. At 1920 points they are still considerably less productive than any other SMP work unit, including the dreaded 3065s at 2144 points. Over the years I've done my fair share of crapola work units and would probably slog through the 2665s except for an additional major problem. The finished data file does not compress for upload like all the other SMP work units and for those of us still stuck on dial-up the resulting two to three hour upload is completely unacceptable.

In the last twelve to fifteen hours I've tried four times (at an hour for each try) to upload this PoS WU! After an hour of sending data this server (which I'd like to smash with a ten pound sledge hammer) resets the connection and "tries another port!" And WTH is with this uncompressed upload file .. I mean really? .. a fourteen MB upload for a half MB download .. Really?

For several weeks I've been seeing 171.64.122.139 trying to send me WUs and tonight I'm seeing 171.67.108.20. Uh Stanford, what the hell are these mystery WUs? And what's with the generally spastic single core server behaviour? I'm starting to feel like a mushroom farmer .. kept in the dark and fed horse manure.

I apologize for my overly enthusiastic reaction to the points increase for the 2665 work units. At 1920 points they are still considerably less productive than any other SMP work unit, including the dreaded 3065s at 2144 points. Over the years I've done my fair share of crapola work units and would probably slog through the 2665s except for an additional major problem. The finished data file does not compress for upload like all the other SMP work units and for those of us still stuck on dial-up the resulting two to three hour upload is completely unacceptable.

I wonder if this is a failure similar to the erroneous 2653 SMP WU upload failure message, "Unknown packet returned from server, expected ACK for results." Do you have this line in the logfile section just prior to the section you displayed?

Since most of you don't flush the work folder and queue.dat file after each upload, it stand to reason that the client will continue to upload the same WU until it cycles out of the queue. Which would normally take the completion of nine additional WUs. I bet this flaw is beating the crap out of the SMP WU servers. Odd how the 5.91 client didn't have any problem with the 2653 WU uploads.

farmpuma wrote:In the last twelve to fifteen hours I've tried four times (at an hour for each try) to upload this PoS WU! After an hour of sending data this server (which I'd like to smash with a ten pound sledge hammer) resets the connection and "tries another port!" And WTH is with this uncompressed upload file .. I mean really? .. a fourteen MB upload for a half MB download .. Really?

Stanford, you bastards! You killed my 3052 SMP WU!

A couple of hours before the Final Deadline I tried for the *fifth* time to upload this WU. At exactly one hour the upload failed and switched to a collection server which also failed at exactly one hour. You've wasted my time, my internet access time, and my electricity. You Bastards!

Forgive me for quoting myself again, BUT 171.64.122.139 is back and STILL not listed in the Project Summary or the Beta Project Summary. Is this work unit a good fit for my hardware and internet connection? And what's it worth?

I'll whine a bit: the Project 5900 GPU WU stinks. It gives 420 points, and it crunches slower on my 8800GT-256 than the slower-than-the-480-point 384 point WU's (though not as bad as the 511 point ones). But it really reeks out loud on my 9600GSO, giving less than 2/19 of the point production of the 384 pointers. Those extra 16 SP's really seem to make a difference.

171.64.122.70 that is. It seems the 5900 GPU work units have spawned two quad sized siblings, the 5902s and 5903s. Both produce the same PPD as the 5900 (about 2000+ on my 9600 GSO), but are worth 1680 points rather than the 420 points of the 5900s. Sadly, they are only third place in GPU points production on my Nvidia card and have been unavoidable for the last two days.

While checking the Windows Task Manager Performance tab I discovered these work units spike the supporting CPU about once every fifteen seconds rather than run it at a constant 100%. These spikes are about five seconds in duration and usually flat-top on the supporting CPU core while producing a small secondary spike on the other CPU core. This over shoot is most likely due to my outdated driver which I plan to update as soon as I can borrow a broadband internet connection.

Until now I had given up on running even a reduced percentage single core client on my mostly unused C2D core due to the off setting loss of GPU points for any gain in CPU points. But, Thanks to Flying Fox's suggestion of setting CPU affinity, I'm currently running a bonus points 2606 Gromacs at 71% for 200+ PPD plus I'm seeing a slight increase in the GPU client PPD. Warning! -- Select your single core client percentage carefully as my first attempt at 76% produced an "Unstable Machine" GPU crash, although I think I was given partial credit. YMMV and your setting will most certainly vary based on your hardware, GPU driver, and work unit types.

It took me a while to find the CPU affinity settings, but there it was in the menu when I right clicked on the folding client in the Windows Task Manager Processes tab. I left the GPU client using the default of both CPUs and set the single core client to CPU0 only, since the GPU client was using CPU1 for it's main support by default.

... and an internet connection that can handle 50MB uploads. No SMP help for those of us on dial-up.

In other bad news - My 5903 GPU work unit with a 2606 at 71% on the secondary CPU core crashed at 42% completion and set idle for more than four hours during my sleep cycle. I will probably restart the 2606 at 50% when I have time to keep an eye on it, but for now the current 5903 has all of both the CPU cores.

Update to the update - I've now (17 March) lost a 5902 and a 5903 to EUEs. I may have forgotten to delete the work folder, queue.dat, and unitinfo.txt on the 5902, but I definitely deleted them before downloading the 5903. Maybe my outdated 174.88 driver has finally met it's match after over 700 work units or maybe these 590Xs aren't ready for prime-time, but since XP is still windowz I've tried a system restart. Currently at 38% and crunching on another 5903.

Status update (18 March) - 5903 crashed at 96%. Yeah, I seem to have procrastinated my driver update a bit to long. Currently crunching a 5900, of the several downloaded, none have ever crashed.

Last edited by farmpuma on Wed Mar 18, 2009 6:44 pm, edited 3 times in total.
Reason:update to 590X issues and status update and update this

farmpuma wrote:... and an internet connection that can handle 50MB uploads. No SMP help for those of us on dial-up.

In other bad news - My 5903 GPU work unit with a 2606 at 71% on the secondary CPU core crashed at 42% completion and set idle for more than four hours during my sleep cycle. I will probably restart the 2606 at 50% when I have time to keep an eye on it, but for now the current 5903 has all of both the CPU cores.

Update to the update - I've now (17 March) lost a 5902 and a 5903 to EUEs. I may have forgotten to delete the work folder, queue.dat, and unitinfo.txt on the 5902, but I definitely deleted them before downloading the 5903. Maybe my outdated 174.88 driver has finally met it's match after over 700 work units or maybe these 590Xs aren't ready for prime-time, but since XP is still windowz I've tried a system restart. Currently at 38% and crunching on another 5903.

I like the new Nvidia drivers, the 182.something series. They crunch real well and steady too!

I think I finally got a PPD improvement from a driver update... though it will take some time to be certain.

I was running v. 177.92 on my 9600GSO, and was getting ~900-1100 PPD on Project 5903 WU's. I updated to v. 182.08, and suddenly it's reading ~3500 PPD on the last 14% of the current WU. Had I updated earlier, I'd have improved my output significantly. Gonna update the other machine too, though it's already somewhere above 180.xx.

I was looking to see what happened to Grzzer2, who had been on the path to eventually overtaking me on this team, yesterday. He was producing very well as recently as last month, but then dropped off. I looked him up here and found some posts in this forum, in the thread entitled "The Hunt Is ON!", where at least one UGN member tried to recruit him.

But that was last summer and it didn't appear that anything came of it. His output plus Jedidiah's alone would, I think, make something in excess of 2/3 of UGN's total, so it doesn't appear that he joined.

Anybody want to try to get him back in the fold, so to speak?

We did over 1,000,000 PPD on April 2. Too bad we couldn't do that a long time ago to keep our rank.

I keep slowing down my 9600GSO's shader clock, and it still get EUE's and UNSTABLE_MACHINE errors. I'm down to about a 6.5% overclock, and it still crashed on 5904 WU's. Very annoying. It has never performed this poorly before (right now showing < 1200 PPD). Quite a shame.

Ragnar Dan wrote:I keep slowing down my 9600GSO's shader clock, and it still get EUE's and UNSTABLE_MACHINE errors. I'm down to about a 6.5% overclock, and it still crashed on 5904 WU's. Very annoying. It has never performed this poorly before (right now showing < 1200 PPD). Quite a shame.

Try benching it with some videogames. Your card may be failing. My GTX 280 died and I had to RMA it. I have a sneaky suspicion it was due to the folding 24/7. Maybe it's that ROHS compliant solder they use... When I first got the card it ran great, but then after a month or two for some reason rivatuner didn't work on it anymore. I tried all kinds of things to get it to work. It would act up more and more, then it started crashing in games. I'd get this beautiful screen:

Luckily Zotac replaced it under warranty. It was an open box item so I was very pleasantly surprised they honored the warranty. Also, they corresponded with me by email several times during the process, which I thought was pretty cool. Don't get that nowadays it seems.

If you're not folding with your idle computer time you're not part of the solution.

Ragnar Dan wrote:I keep slowing down my 9600GSO's shader clock, and it still get EUE's and UNSTABLE_MACHINE errors. I'm down to about a 6.5% overclock, and it still crashed on 5904 WU's. Very annoying. It has never performed this poorly before (right now showing < 1200 PPD). Quite a shame.

Yeah, that's a bit odd. My 9600 GSO with stock clocks makes just over 2000 PPD as long as remember to limit the affinity on my 40% single core client. Are you running the latest version of FahCore_14 core? It came out around 26 March and seems to have eliminated my 59XX crashes.

Well, I don't think I have any modern games that would push it. And I've yet to see any sort of artifacts or other evidence of failure on the screen. It's warm inside the case, certainly, and I may be able to cool it down some if I work on it long enough, but it's a big PITA and always causes annoyance getting inside there because of the sharp edges and the tenuously connected drive cables which almost invariably give me trouble when I put everything back together again.

Anyway, it seems to speed back up with some WU's, like most of the 768 point ones, so I think it's just the fact that most of these new WU's run more slowly on this 96-shader unit, and the new core FahCore_14.exe (got mine March 25) behaves in a rather Lewinsky-like manner, making more heat and producing little as a result.

Edit: farmpuma: I am running the Linux SMP client, so perhaps it's taking some of my output now, but it's a shame if they can't make it work like it used to.

Ragnar Dan wrote:Well, I don't think I have any modern games that would push it. And I've yet to see any sort of artifacts or other evidence of failure on the screen. It's warm inside the case, certainly, and I may be able to cool it down some if I work on it long enough, but it's a big PITA and always causes annoyance getting inside there because of the sharp edges and the tenuously connected drive cables which almost invariably give me trouble when I put everything back together again.

Anyway, it seems to speed back up with some WU's, like most of the 768 point ones, so I think it's just the fact that most of these new WU's run more slowly on this 96-shader unit, and the new core FahCore_14.exe (got mine March 25) behaves in a rather Lewinsky-like manner, making more heat and producing little as a result.

Edit: farmpuma: I am running the Linux SMP client, so perhaps it's taking some of my output now, but it's a shame if they can't make it work like it used to.