Yesterday I just changed my Penny, at number 19 over from the Alex V8 4.1 code to the SSSE3x to see if there is any difference.

Under the 4.1 code the Penny reached an RAC of 8,742, but now it barely reaches 8,250 and seems to be falling.

There is a slight increase in my pending, but not to the extent of loosing over 450 units per day on 1 cruncher. The other, older, Quad seems to be holding it's own ATM.

The WU results are taking about the same time as before. But I, like others with me, seem to be running through a bad patch of WU.

Any observations as to why, please?

---

It's good to be back amongst friends and colleagues

This has been covered many times and there are several factors which can effect RAC both long term and short term, but almost always come back to the basic fact the Credit Rate vs AR curve does not have a slope of zero. IOW's when you plot it (with CR as the Y axis and AR as the X axis, it is not a straight horizontal line.

Alinator

Thanks

It jst seems the swings are larger than they have been in the past.

---

It's good to be back amongst friends and colleagues

Thanks

It jst seems the swings are larger than they have been in the past.

Looking through your history, I see a few compute errors returned in the past couple days... These are an effective way of decreasing RAC. Also you have been crunching a few VLAR WUs (63.98CR), which consume more CPU/CR than the mid AR WUs. Other than that, 10% swings are not uncommon as the WU distribution changes... at RAC 8700, 10% might bring you down to ~7900, though I think a range from 8000-9200 might be more typical for this host/client combo.

[edit] update estimated RAC [/edit]

Thanks John, I had noticed that I was creating a few compute errors and there was more under the SSSE3x than the 4.1 client. But I should give it a chance to have time to see whether the 4.1 or SSSE3x clients are faster on my rig.

This graphic illustrates the fall on the Penny

---

It's good to be back amongst friends and colleagues

have a look at the V8-Xeon Avg graphic
#22 _heinz 8,220.71 336,700 at the moment

heinz

Yes, in addition to the factors mentioned, ssse3x & sse4.1 builds vary by nature of how the they use cache and bus. This is a complex memory/bus/cache interaction that boils down simply to: if you have a quad with High O/C you will 'propably' get better results with ssse3x version, though there are so many implementation specific variables there that the best choice has proven to vary depending on the machine and the sse4.1 build is faster in some cases. the only way to know for sure would be to :
1 - First stabilise the machine such that it doen't get any computation errors at all, then
2 - try both builds, noting times across similar AR's

What tends to happen is one build tends to be better at some AR's than the other, and vice-versa , on given hardware, so the optimal choice would be dependant on work distribution, which means you'll likely need to bring along your crystal ball to make that choice. For me favouring midrange seems logical, though I don;t have the numbers to back that up.

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

And here is a graph of one of my hosts over the past month... Looks a bit like yours... though I think my deviations are a bit higher % yours... The deep dip on 26 June was due to network failure.

Thanks Jason and John

The O/Ced Penny was on the SSE4.1 build from the beginning, and I thought I would see how the SSSE3x build did for a change.

After swapping over you saw the result. But, before going back, I need to give the rig time to get over the digestion and back in to a sweet spot.

Running long term will give an indication, for me, of which of the 2 Alex code builds is better (or not).

---

It's good to be back amongst friends and colleagues

Thanks Jason and John

The O/Ced Penny was on the SSE4.1 build from the beginning, and I thought I would see how the SSSE3x build did for a change.

After swapping over you saw the result. But, before going back, I need to give the rig time to get over the digestion and back in to a sweet spot.

Running long term will give an indication, for me, of which of the 2 Alex code builds is better (or not).

Both the "Frozen Penny" and my Q9450 find the SSSE3x (very slightly) more productive. It will be interesting to see if your long-term test leads you to a different conclusion. But the comparison has to be made very carefully as the differences are very small.

F.

---

Thanks Jason and John

The O/Ced Penny was on the SSE4.1 build from the beginning, and I thought I would see how the SSSE3x build did for a change.

After swapping over you saw the result. But, before going back, I need to give the rig time to get over the digestion and back in to a sweet spot.

Running long term will give an indication, for me, of which of the 2 Alex code builds is better (or not).

Both the "Frozen Penny" and my Q9450 find the SSSE3x (very slightly) more productive. It will be interesting to see if your long-term test leads you to a different conclusion. But the comparison has to be made very carefully as the differences are very small.

F.

Have a lot off them short WU's from 1my08ab.24407.6207.etc 11 minutes.
A few more and i'll reach my quota for the day (100/CPU).
And the everchanging AR, makes it hard to choose, what optimized app. may be appropriate.
Fastest XP64 host(X9650) on SSE4.1, OC'ed Q6600 on SSSE3x and stock Q6600 (VISTA) on SSE3, also my LT (C2D T2400).
Hope this mix will average out those differences.
Also had UPLoad problems due to some errorous WU's
Had to request new work, but all is fine now :)

---

Total volume of work still drifting down, but the Penny seems to have flattened out.

The other Quad is now starting to drift down daily, bt very slowly.

The pending tray is rising slightly in compensation, but not as much as I might expect if things had returned to full bore.

---

It's good to be back amongst friends and colleagues

Just a side note: I noticed my p4 dropping about 10% in RAC also, and the CPU efficiency shown in BoincView was below 80%. Investigation revealed that my mum had been using firefox on that machine, left a page with flash open, been prompted with firefox updates (Which she promptly ignored/ selected leave 'til later), and subsequently funky firefox behaviour had been occurring since Wednesday... without informing me .... grrrrr.... (wouldn't close properly etc...). This cleared up with a hard restart, then firefox completed its update, and is now back to full processing speed.

The lesson is:... Well I don't know what the lesson is, but it'll probably involve keeping a stricter eye on mum's surfing habits! There be spam in them there hills!

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Total volume of work still drifting down, but the Penny seems to have flattened out.

With the current stream of WUs being dominated by 0.4 - 0.45 AR... I'm afraid Penny is right on target according to my estimates. Another 4 or 5 WUs returned compute errors over past 24 hours on that same rig. If that continues, or more 0.6 - 0.9 AR WUs are handed out, you can expect further RAC deterioration.

I can also relate with Jason' comment...I sometimes forget to shutdown IE on my laptop only to discover a day or two later that IE has been a resource hog and not sharing any CPU time with S@H.

Another behavior I recently noticed... I was having ISP/networking issues a while back (intermittent cable modem connection plays havoc with my switch) that for some reason was causing WU exit/restarts with messages in stdoutae.txt :

25-Jun-2008 03:51:25 [SETI@home] Task 16ap08ac.12776.15205.7.8.214_0 exited with a DLL initialization error.
25-Jun-2008 03:51:25 [SETI@home] If this happens repeatedly you may need to reboot your computer.
25-Jun-2008 03:51:25 [SETI@home] Restarting task 16ap08ac.12776.15205.7.8.214_0 using setiathome_enhanced version 528
25-Jun-2008 03:52:31 [SETI@home] Task 16ap08ac.12776.15205.7.8.214_0 exited with a DLL initialization error.
25-Jun-2008 03:52:31 [SETI@home] If this happens repeatedly you may need to reboot your computer.

Well restarting BOINC and rebooting computer had no effect... but disabling network activity restored normal behavior. This same problem was occuring on multiple hosts.

Good luck,
JDWhale

Total volume of work still drifting down, but the Penny seems to have flattened out.

With the current stream of WUs being dominated by 0.4 - 0.45 AR... I'm afraid Penny is right on target according to my estimates. Another 4 or 5 WUs returned compute errors over past 24 hours on that same rig. If that continues, or more 0.6 - 0.9 AR WUs are handed out, you can expect further RAC deterioration.

I can also relate with Jason' comment...I sometimes forget to shutdown IE on my laptop only to discover a day or two later that IE has been a resource hog and not sharing any CPU time with S@H.

Another behavior I recently noticed... I was having ISP/networking issues a while back (intermittent cable modem connection plays havoc with my switch) that for some reason was causing WU exit/restarts with messages in stdoutae.txt :

25-Jun-2008 03:51:25 [SETI@home] Task 16ap08ac.12776.15205.7.8.214_0 exited with a DLL initialization error.
25-Jun-2008 03:51:25 [SETI@home] If this happens repeatedly you may need to reboot your computer.
25-Jun-2008 03:51:25 [SETI@home] Restarting task 16ap08ac.12776.15205.7.8.214_0 using setiathome_enhanced version 528
25-Jun-2008 03:52:31 [SETI@home] Task 16ap08ac.12776.15205.7.8.214_0 exited with a DLL initialization error.
25-Jun-2008 03:52:31 [SETI@home] If this happens repeatedly you may need to reboot your computer.

Well restarting BOINC and rebooting computer had no effect... but disabling network activity restored normal behavior. This same problem was occuring on multiple hosts.

Good luck,
JDWhale

Ahhhh!! I wondered why my ethernet switch had started locking up. It must be because of the DSL wireless router/modem going off-line intermittently to re-synch as the number of users on the share changes.

I have given up with the ethernet connexion and depend on wireless connexion - no problems at all since then (other than losing the internet connectivity when the modem re-synchs but that was happening anyway. At least there is nothing now locking up and stopping the re-connexion when synch is established again.

F.

---