Trux

I'm trying this client on one of my machines but I get the impression it is over-calibrating (claiming too much). In many cases, my computer (with Crunch3r's SSE3 app) is now the highest or second-highest claimant by quite a margin, which seems unfair. You can view the host here

Are others seeing this trend too? If so, perhaps it needs to be throttled back a bit? Some examples:

WU 48141905
WU 48483490
WU 48483502
WU 48485185

---

*** Join the #1 Aussie Alliance on SETI ***

I'm trying this client on one of my machines but I get the impression it is over-calibrating (claiming too much). In many cases, my computer (with Crunch3r's SSE3 app) is now the highest or second-highest claimant by quite a margin, which seems unfair.

It looks just fine. Do not forget that the theoretical value of a full-length unit is around 30 cobblestones (32.32 cobblestones for the reference WU). Majority of todays computers underclaim in S@H. Only older coputers claim approx the right value, and the oldest ones often overclaim, although all of them should claim the same. That's exactly the reason for this calibration.

---

trux
BOINC software
Freediving Team
Czech Republic

It looks just fine. Do not forget that the theoretical value of a full-length unit is around 30 cobblestones (32.32 cobblestones for the reference WU).

OK with me :-)

Incidentally, have you seen the thread "Interesting Post @ Einstein on upload failures"? Is this something you can fix in your client perhaps? Would make it even better!

Personally I don't see a need to change it. I run the optomized SETI and BOINC clients, and still claime lower credits due to the faster times. About 90% of the time mine it not used as it is still the lowest claiming SETI unit.

For CPDN it dues not matter what you claime, all get the same credit for the same amount of work. How long you take makes no diferance.

For LHC mine is almost always thrown out as the high and not used for figuring credit.

At Rosetta there could be some improvements as you get the credit you claime.

At uFluids the lowest is used to grant credit, no effect for using optomized BOINC cliient.

Only 20% the way through the first SETI BATA unit, but don't think that it will make much diferance there, probably the same as LHC.

For results of using both optomized SETI and BOINC on a P4 2.4 Gig Click here

For SETI the optomized client dues claime more credit but still the lowest usually. It dues give more credit per hour only from being able to do more work with the Optomized SETI client.

Ray

---

Pizza@Home Rays Place Rays place Forums

Trux

I'm trying this client on one of my machines but I get the impression it is over-calibrating (claiming too much). In many cases, my computer (with Crunch3r's SSE3 app) is now the highest or second-highest claimant by quite a margin, which seems unfair. You can view the host here

Are others seeing this trend too? If so, perhaps it needs to be throttled back a bit? Some examples:

WU 48141905
WU 48483490
WU 48483502
WU 48485185

To me it looks like it's doing exactly what it should do.
It's making your PC claim the right amount of credit/WU.
It's the other 2 that are claiming too little credit, not yours claiming too much.
As Trux stated, the "cobblestone" PC should claim about 32 credits per WU with Seti.
It's just that modern processors, with Caches, perdictive fetching, etc, are able to process far more efficiently than the Cobblestone PC.
Hence a pc that has a benchmark twice as good as the cobblestone PC takes 1/4 of the time, not half the time, to do a WU, and so claims 16 cr, not 32.

---

Foamy is "Lord and Master".
(Oh, + some Classic WUs too.)

Hmmm, can't add process priority option since started the new client.
I closed all of boinc added the option and saved but after starting boinc again my initial truxoft_prefs.xml is back there.

Hmmm, can't add process priority option since started the new client.
I closed all of boinc added the option and saved but after starting boinc again my initial truxoft_prefs.xml is back there.

If you used the older configuration files (glob_prefs.xml or remote_hosts.cfg), try removing it from there.

---

trux
BOINC software
Freediving Team
Czech Republic

I see what you are tying to do, but won't that cause us to claime way to much on other programs?

Claiming around 32 gave a certain amount of credit per hour on the average. Even with the lower claimed credit we are getting more per hour due to doing a lot more WU's in a day.

But getting back to getting an average of around 32per WU would make our credits climb a lot faster for those of us doing them a lot faster.

Any idea when optomized clients will be out for the SETI BATA program? That one could really use them. They would still take a fast machine around 10 hours and take some of the strain off the server compaired to SETI BOINC run here. But a bit fasster than the P3 500 that I burned out that took 12 hours for a classic unit, with a lot more science being done.
Ray

---

Pizza@Home Rays Place Rays place Forums

Ray: please try reading the information posted in this thread and/or on the download page. Or look at the name of this thread :) You apparently misunderstood the purpose of the calibration, and the way it works.

EDIT: just to tell it briefly - the calibration will "normalize" the credits at all projects, it means at most of them it will reduce the claimed credits to avoid over-claiming. Only at project with optimized applications it will increase the credits. However, I really recommedn that you read more details about it either here, or on my website.

---

trux
BOINC software
Freediving Team
Czech Republic

If you used the older configuration files (glob_prefs.xml or remote_hosts.cfg), try removing it from there.

I'm not trying to remove anything I want to add something.:-)
I did de uasal things installing 5.3.11.tx31 and I added the return_results_immediately and the automatic credit self-calibration options in truxoft_prefs.xml, works fine after I started up. Then earlier this evening I realised I forgot to ad the process priority option as well. Now adding this tot de prefs.xml apears not to be working cause the old prefsfile is back after I start things up with Boincmanager.
As for glob_prefs.xml or remote_hosts.cfg I dont have them in the directory . I have a global_prefs.xml though .;-)
Nothing but the global prefs there and apart from reading it I din't touch a thing.

Another thing I noticed just a few moments a go, repeating the things described below, the files waiting to upload , due to the problems today with contacting the server, are showing increasing completion times ( under the work-tab) every time I shut the manager down and start up.

Edit: after trying to add that process priority option that is.

I think that I have run into problems with the optimized v5.3.11.t31.

It seemed fine at first except it seemed like the work units were taking longer. When I got home my machine had crashed 3 times and the work units were taking almost twice as long.

If you check you can see the time growing.

http://setiweb.ssl.berkeley.edu/results.php?hostid=1934972&offset=400

P.S. I didn't read close enough. I see that it is suppose to increase the reported time.

I not sure if I like it doing that. I do like the idea of claiming a fair amount of credits and I like to report result immediately. I'm going to have to think about this a little more.

I think the reason my machine crashed is it is having trouble connecting to report and download. None of my machines have tolerated prolonged connection failures for about the last six months.

---

People, please, please, please, do read the instructions and the explications! I am happy to help, but I am afraid I'll not be able sitting here permanently, and answering all the time the same questions over and over. The time reported is irrelevant. As well the benchmarks are completely irrelevant. This is well explained in the docs and here in this thread too. Look at the unit details in your web account for the real (uncorrected) values. The client has absolutely no impact on the application speed or the time spent on the calculation (and cannot have, since it's a separately and [practically] independently running program). Though, the client indeed does modify the reported time and reported benchmarks. That's exactly the prupose of the whole calibration as discussed quite in details here. The client also has no impact on any app crashes, or the recent uploading/downloading problems, so please avoid mixing these problems with calibration issues.

As for the process priority - there was indeed a bug in reading of the setting in the release tx31. Please download the release tx32.

---

trux
BOINC software
Freediving Team
Czech Republic

Thanks trux. While you were answering my question I was adding the P.S. to my last post.

---

Thanks trux. While you were answering my question I was adding the P.S. to my last post.

Again, please read and re-read what was already written. This was discussed in details too. There is nothing like claimed credit communicated to the server. Only benchmarks and the time - the server calculates the claimed credit from those two values. The client has to modify both in sake of correct values. Typically, with each WU completed, the final_time modification will be smaller and smaller, and the majority of the correction will be done through reporting corrected fpops value. If you do not like it, you have no other option than going back to your original client, which has the ugly effect that you either cheat in other projects, or strongly underclaim in S@H (or both of it).

---

trux
BOINC software
Freediving Team
Czech Republic

I just noticed something with 4.3.11.tx32 that I thought I'd pass on regarding truxoft_prefs.xml entries. When I entered the parameters, I used:

<set_cpu_affinity/>

But when the client rewrote the file, it came back as:

<cpu_affinity/>

It does seem to be fully functional with the shorter syntax, as CPU affinity is in fact being set - I just thought it might be useful to report here in case anyone else notices the same thing.

(of course, I also wonder if this might be a step in the direction of setting different "priority projects" for different CPU's)

Thanks again for all your work - the capability to use network masks was almost immediately useful, as my DHCP leases had timed out and been given different IP addresses due to a network disconnect, which made them inaccessible until making changes and restarting the clients on the target machines. Next time that won't be necessary!

I think the reason my machine crashed is it is having trouble connecting to report and download. None of my machines have tolerated prolonged connection failures for about the last six months.

Was having the same problem for a few months. About 3 weeks ago I finally found the culprit. My nic card was faulty and since I replaced it not one crash. This was a tough one to narrow down because I never thought that the nic was having any problems. Hope this helps you StokeyBob :)

Edit: sorry I'm OT

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

As for the process priority - there was indeed a bug in reading of the setting in the release tx31. Please download the release tx32.

Does installing this one over the tx31 means the callibration procedure is starting all over? Needed some 14 wu's tot complete to get cc in the 31,x range.

The client has absolutely no impact on the application speed or the time spent on the calculation .

That is thrue but the tx31 did increase the reported real cpu time as scetched under theci rcumstances in me previous posts.

For example

core_client_version>5.3.11.tx31</core_client_version>
<real_cpu_time>3794</real_cpu_time>
<corrected_cpu_time>4230</corrected_cpu_time>
<corrected_Mfpops>9408.2</corrected_Mfpops>
<stderr_txt>

This one completed in some 2800 secs. as was shown under the worktab ( 46 minutes and some secs.).Due to the connecting problems it showed also in the transfer map.I saw the completion time increasing every time I closed down the Boincmanager then tried to ad the process priority option and started the manager up again. Did that about three times. During the night de result got uploaded and indeed reported 3794 secs as real cpu-time.

This does'nt happen in the case of waiting to report.

I thought I should report that.

<set_cpu_affinity> and <cpu_affinity> are equivalent and you can use any of them. Originally I introduced the first one, but in the next official version the other one was included by the dev team, although there is not yet any functionality associated to it, and no affinity control yet, in the official version. I guess they will add it sooner or later. Hence, you can use any of the tags, but the client, for compatibility rasons, will always store it in the official form.

Updating to new releases is always possible, and it should not influence the past calibration.

---

trux
BOINC software
Freediving Team
Czech Republic

I like it.

TYVM to Trux for it.

This PC used to estimate 5 hours, and take 3.
Had it taken 5 hours, it would have claimed 50cr/wu.
But it took 3, so claimed 30cr/wu.
Now, it still takes 3, but the claimed credit is closer to the what it sould be.
Granted credit is up to the other 2 PC's that get the Wu, but at least I claim correctly.
I probably still average 24cr/wu granted, but at least I ask for the right amount.

The rest is out of my hands, and up to the validator.

---

Foamy is "Lord and Master".
(Oh, + some Classic WUs too.)