I removed the Windows updates and it had no effect on the long work units I am getting. I checked other peoples results and the same work units that were running long for me had normal times for them.

I think it is the program SWIM (Space Weather Information Monitor) that I run to monitor things like solar, weather and earthquake activity. It downloads information at different intervals during the day. STD trial version.

It sort of looks like when it interrupts SETI it messes up the time calculation but this is just a guess.

P.S. I anyone tries out STD Aurora Monitor software let me know if you start seeing work units that record taking extra long.

---

From an ad-hoc viewing of my actual crunch times it feels as though since the recent round of Windows updates crunch times have increased 20 to 30% or more. I am using the truxoft boinc client with Crunch3r's SETI app and have noticed that on my laptop actual cpu times (not reported cpu times) have increased from 50 to 55 minutes a wu to some now taking upto 1hr30min. WU's never use to take longer than 1hr prior to the updates (I think). On my 3.2GHzP4 with HT on times have gone from 45 to 55 minutes to 45 to ~1hr5min per wu.

Has anyone else experienced this?

Live long and crunch.

Yes, I have - I ended up going PURELY with Crunch3r's builds, for BOTH boinc.exe/boinc.dll & also seti 4.x (which, iirc, Crunch3r does credit Trux for portions of them in his code, part IS Trux's optimizations code - apparently, these guys collaborate & share their coding efficiency accomplishments with one another, which is GOOD imo).

I also see that you're doing what I did - "mixing & matching" client builds from BOTH Trux & Crunch3r... & finding what I did as well. It's "touchy" doing it, and you can get decreases. I did as well... it forced me back to Crunch3r's builds ONLY here.

Probably my mistake somehow, in doing the mix-match of their wares &/or config files most likely - See, I even eventually totally SCRAMBLED my seti folder doing that mix/match, but it was in the interest of experimentation to see how fast I could get units processed (in trying to see what mix was best)...

Anyhow, again, I went totally "Crunch3r" because my RAC is now what it was initially again... typically requesting between 6-11 points per unit processed & being granted between 18-32 per unit.

LOL, Crunch3r's builds give me results I can "live with" (far more, very happy with that, RAC's my goal - seeing how fast/efficiently I can process these units in the least amount of work for the system).

The reason being that Trux's MSVC++ optimized builds tend to show better iops processing in the benchmarks results (yes, I do take their results into account, I have no other real gauge other than doing the seti unit processing & that takes time to see).

(Thus, imo & 'in-theory', making Trux's wares for boinc.exe/boinc.dll the BEST for the boinc.exe/boinc.dll portion of this project's executables since they do iops work the most, as do most Win32 apps (they work mostly on integer data, not floating point data in variables typically - lol, using a floating point var for a counter for instance, would be dumb imo - it needs "real numbers" not approximations for e.g. - a loop counter))

So, it made sense to me to use Trux builds for the boinc.exe & boinc.dll section of this application client-server suite's setup. Better/best results in iops via the benchmarks vs. Crunch3r's builds.

This 'backfired' on me though, as far as MY personal goals were concerned (which is to gain highest RAC really, & to make this process as efficient as possible, doing the most work in least CPU cycles).

I.E.-> With the latest Trux builds for boinc.exe/boinc.dll (not seti 4.x executable - here I stayed with Cruncher's builds always), I started yielding SLOWER results for RAC than what I had in his earlier builds & also mixed in with Crunch3r's SETI 4.x builds also.

The seti 4.x executable, afaik, works on fpops (floating point data) & is the actual units processing workhorse) & if the benchmarks are ANY indicator/guide here?

Then, Crunch3r's builds are the way to go for THIS portion of this client-server suite's apps... SETI 4.x works on fpops data!

* The bottom-line IS that part - the SETI 4.x portion really since it is the actual units processing workhorse working on fpops data!

(Which Crunch3r's use of the Intel C++ 9.x compiler with IPP 4.1 libs excels @ vs. MSVC++ results for iops via the boinc benchmarks as a gauge for me)

The bottom-line's NOT not the mgt. portion in boinc.exe/boinc.dll etc.-et all, as it only coordinates communications w/ the servers & also the operations of SETI 4.x itself.

(boinc.exe &/or boinc.dll do mostly iops/integer op data processing (where MSVC++ tends to apparently excel @ & this is what Trux uses vs. Intel compilers which excel @ fpops floating point data processing & what Crunch3r utilizes for client optimizations @ the compiler optimizations level @ least, not hand-tuned stuff), but not for the units being processed (again the bottom line really))...

Theoretically @ least, imo, a mix SHOULD work the best, but you have to watch it when you do the mix/match... or, screwup like I did eventually & have to start over again until you find the one that yields the best results for you (which ought to be how FAST you can put out units really - again, the true bottom-line).

APK

P.S.=> Eventually, out of convenience & tiring of experimenting? Well, I ended up going PURELY with Crunch3r's builds (which DO have Trux's code in them from what I read on Crunch3r's site no less) on BOTH SETI 4.x executable AND Boinc.exe/Boinc.dll, & have not looked back - they give me the highest RAC is why! apk

---

http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"

The Gas Giant,

I've been watching my "to completion" times in the BOINC manager and the two 3.2 machines are still OK but the 2.4 machine is still running with high times.

Just in case you were onto something I removed the last five updates to see what will happen. I know I am risking having wrath on Microsoft coming down on me. I already have the little balloon thing popping up.

When I removed the updates I had to do it in a certain order. Maybe sometimes they don't install right.?

Anyway, if I notice anything different I'll try to check back in here.

---

Yeah, I need to check the AR of the wu's.

If you are seeing the times climb then the "to completion" times in the BOINC manager will be moving up if you are using the 5.2.13 version. At least I'm thinking that's the way it works. I wrote my times down a while back.

3.2GHz was 55:18 and is now 56:27

3.2GHz was 45:49 and is now 49:36

2.4GHZ was 55:49 and is now 1:17:24 and is headed back down (just saw it change to 1:15:55).

I'm thinking we have just had some bigger than normal work units. I went through a bunch of results today and I noticed a couple of honkers.

---

Maybe what you are seeing is the adjustment the calibrating client is giving to the reported time.

Take a look at this result. Once you dig deep enough you can get to where it show the actual and the reported time.

result

I didn't notice anything different on my machines after the update. I do have one machine that ran a couple of really long work unit and now the "to completion" estimate is way high. At least that is what I'm guessing caused it.

I have two 3.2 machines if you what to compare.

StokeyBob,

I did say actual cpu (not reported) time in my post. I am looking at the cpu time as it progresses in BOINC Manager/View not the reported time. I thought I had made that clear and the wu you point to is right in the middle of where I said the recently completed wu times were heading. This wu is one that took longer than 1hr actual cpu time, which was extremely rare. I will look deeper.

Thanks for the feedback.

Live long and crunch.

Paul.

From an ad-hoc viewing of my actual crunch times it feels as though since the recent round of Windows updates crunch times have increased 20 to 30% or more.

Has anyone else experienced this?

I have been noticing this effect over the last 2-3 days, and looking suspiciously at my crunch times. These seem to be taking longer that I remember (not yet using the Trux BOINC optimised client).

The increase appears variable, and in the order you mentioned, but not consistent.

---

It's good to be back amongst friends and colleagues

Maybe what you are seeing is the adjustment the calibrating client is giving to the reported time.

Take a look at this result. Once you dig deep enough you can get to where it show the actual and the reported time.

result

I didn't notice anything different on my machines after the update. I do have one machine that ran a couple of really long work unit and now the "to completion" estimate is way high. At least that is what I'm guessing caused it.

I have two 3.2 machines if you what to compare.

---

Haven't seen it myself. Any other changes made recently? I imagine you would have tmetioned them of course. I see nothing on my machines that have downloaded the recent updates.

Jim

---

Without love, breath is just a clock ... ticking.
Equilibrium

From an ad-hoc viewing of my actual crunch times it feels as though since the recent round of Windows updates crunch times have increased 20 to 30% or more. I am using the truxoft boinc client with Crunch3r's SETI app and have noticed that on my laptop actual cpu times (not reported cpu times) have increased from 50 to 55 minutes a wu to some now taking upto 1hr30min. WU's never use to take longer than 1hr prior to the updates (I think). On my 3.2GHzP4 with HT on times have gone from 45 to 55 minutes to 45 to ~1hr5min per wu.

Has anyone else experienced this?

Live long and crunch.

---

Paul
(S@H1 8888)
And proud of it!