@TRUX,

Take a look at this post over at uFluids regarding this host. It would appear that your client is greatly exaggerating to the extreme the amount of credit this participant is claiming. I remember reading that your client is only supposed to effect SETI so I thought you'd want to see this.

That person must have modified it more to get those claims.

I've had a few instances recently on a couple of hosts where the 5.3.12.tx36 client has crashed. The latest from this morning had this in the stderrdae.txt:

***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0033F114 read attempt to address 0x00000008

The crash isn't coinciding with a benchmark.

Edited to add:

I looked further back in the same stderrdae.txt file and found I still had a few errors from previous crashes of 5.3.12.tx36. Two more are identical to the one above (same addresses), the other one is:

***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040C885 write attempt to address 0x00C45738

In total the client's crashed on that PC 3 times since 1st Feb. Another PC which has also had the client crash 3 times in that time has the same addresses as above.

I don't know if these crashes are specific to the trux client or not.

---

@TRUX,

Take a look at this post over at uFluids regarding this host. It would appear that your client is greatly exaggerating to the extreme the amount of credit this participant is claiming. I remember reading that your client is only supposed to effect SETI so I thought you'd want to see this.

That person must have modified it more to get those claims.

But then wouldn't that person need the source code of the client and not just the executable?

Take a look at this post over at uFluids regarding this host. It would appear that your client is greatly exaggerating to the extreme the amount of credit this participant is claiming. I remember reading that your client is only supposed to inflate SETI so I thought you'd want to see this.

That person must have modified it more to get those claims.

Yep, Trux's website does say the source code is available. The person @ uFluids with the inflated host is Mirisek.

wow,

that's some high credit claimed and granted.

http://www.ufluids.net//results.php?hostid=1597&offset=40

---

wow,

that's some high credit claimed and granted.

http://www.ufluids.net//results.php?hostid=1597&offset=40

There used to be a quorum of 3 but there were some issues and the quorum was eliminated. Because of this host the quorum has been set to 2.

wow,

that's some high credit claimed and granted.

http://www.ufluids.net//results.php?hostid=1597&offset=40

There used to be a quorum of 3 but there were some issues and the quorum was eliminated. Because of this host the quorum has been set to 2.

I know that is what Robert said he was going to do but the ones i got today say,initial replication 4 and quorum 3.

---

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.

thanks, trux!

tx37 has been working like a charm here - waiting with much anticipation for release of a post-tx42 revision with the ability to set CPU affinity by project, though (and the last little post-tx39 fix of lowercase project names). Can hardly wait to see what other goodies are in store.

---

.

Thanks again for this gem!

It's working great for me on a variety of machines now, running both Windows and Linux. The following bug is both minor and easy to work around, so I almost didn't want to bother you with it, but it does appear to be a bug, so I figured I should...

The netmask extension doesn't handle the a.b.c.d/n format correctly. In fact, there are also errors in your examples on the web page! For instance:

12.111.22.123/12 = 12.111.22.123/255.255.0.0 = 12.111.0.0 ==> 12.111.1.1-12.111.255.255

I believe this should be:

12.111.22.123/12 = 12.111.22.123/255.240.0.0 = 12.96.0.0 ==> 12.96.0.1-12.111.255.254

Enough of that, though, on to what the program is doing. Using the following values (on the left) in my remote_host.cfg file produces the masks shown on the right (taken from the BOINC console log).

192.168.131.0/31 -> 192.168.131.0/255.255.127.0 (0x007fffff)
192.168.130.0/30 -> 192.168.130.0/255.255.63.0 (0x003fffff)
192.168.129.0/29 -> 192.168.129.0/255.255.31.0 (0x001fffff)
192.168.128.0/28 -> 192.168.128.0/255.255.15.0 (0x000fffff)
192.168.127.0/27 -> 192.168.127.0/255.255.7.0 (0x0007ffff)
192.168.126.0/26 -> 192.168.126.0/255.255.3.0 (0x0003ffff)
192.168.125.0/25 -> 192.168.125.0/255.255.1.0 (0x0001ffff)
192.168.124.0/24 -> 192.168.124.0/255.255.0.0 (0x0000ffff)
192.168.123.0/23 -> 192.168.123.0/255.127.0.0 (0x00007fff)
192.168.122.0/22 -> 192.168.122.0/255.63.0.0 (0x00003fff)
192.168.121.0/21 -> 192.168.121.0/255.31.0.0 (0x00001fff)
192.168.120.0/20 -> 192.168.120.0/255.15.0.0 (0x00000fff)
192.168.119.0/19 -> 192.168.119.0/255.7.0.0 (0x000007ff)
192.168.118.0/18 -> 192.168.118.0/255.3.0.0 (0x000003ff)
192.168.117.0/17 -> 192.168.117.0/255.1.0.0 (0x000001ff)
192.168.116.0/16 -> 192.168.116.0/255.0.0.0 (0x000000ff)
192.168.115.0/15 -> 192.168.115.0/127.0.0.0 (0x0000007f)
192.168.114.0/14 -> 192.168.114.0/63.0.0.0 (0x0000003f)
192.168.113.0/13 -> 192.168.113.0/31.0.0.0 (0x0000001f)
192.168.112.0/12 -> 192.168.112.0/15.0.0.0 (0x0000000f)
192.168.111.0/11 -> 192.168.111.0/7.0.0.0 (0x00000007)
192.168.110.0/10 -> 192.168.110.0/3.0.0.0 (0x00000003)
192.168.109.0/9 -> 192.168.109.0/1.0.0.0 (0x00000001)
192.168.108.0/8 -> 192.168.108.0/0.0.0.0 (0x00000000)
192.168.107.0/7 -> 192.168.107.0/0.0.0.0 (0x00000000)
192.168.106.0/6 -> 192.168.106.0/0.0.0.0 (0x00000000)
192.168.105.0/5 -> 192.168.105.0/0.0.0.0 (0x00000000)
192.168.104.0/4 -> 192.168.104.0/0.0.0.0 (0x00000000)
192.168.103.0/3 -> 192.168.103.0/0.0.0.0 (0x00000000)
192.168.102.0/2 -> 192.168.102.0/0.0.0.0 (0x00000000)
192.168.101.0/1 -> 192.168.101.0/0.0.0.0 (0x00000000)

It looks to me like the mask is shifted right 8 bits from what it should be for a given mask length. The workaround of course is just to use the a.b.c.d/m.m.m.m format, which works fine.

---

Is there any update on this trux?

I was looking forward to the new options that were going in after tx37, but I also need some of the new features that are in the 5.3.28 client.

---

Is there any update on this trux?

I was looking forward to the new options that were going in after tx37, but I also need some of the new features that are in the 5.3.28 client.

5.3.28 is a developmental build used by us "boinc Alpha testers" to get the bugs out. If the minor version(the middle number) is even then it's released as a stable build, odd numbers are developmental. This applies to the "official berkeley releases". Trux may or may not make his clients out of these builds. The new 5.4.x is due out pretty darn soon, and it may smarter to wait for it before he makes another client.

tony

---

I know that - the current trux client is based on 5.3.12 which is also a development build. Earlier trux clients were based on the 5.3.* branch too.

I want to run 5.3.28 for Ralph too, but really need some of the options in the trux client.

---

Off-Topic: mmciastro, I'm not Boinc Alpha tester, but recently I've got a lot of problems behind one authentication proxy (messages "Network error: Send failed since rewinding of the data stream failed") without finding any help. So I tried the 5.3.27 version which solved it. I have few notes to it, where could I send them?

Peter

I have few notes to it, where could I send them?

Peter

boinc_dev@ssl.berkeley.edu

There is a filter and email is examined prior to being posted to the mail list. Include "boinc Proxy something" in the subject line. If it doesn't go through, I'll give you my email addy and you can send them to me, and I'll forward them.

tony

So I tried the 5.3.27 version which solved it. I have few notes to it, where could I send them?

Peter

Peter, I see your email on the mail list.

tony

So I tried the 5.3.27 version which solved it. I have few notes to it, where could I send them?

Peter, I see your email on the mail list.

Thanks, Tony. Initially it did not came through, but I finally decided to subscribe to the list (as I'm reading the notes anyway once in a while).

Peter

Hi,

I don't know if this off-topic here but,
I have been using BOINC client version 5.3.12.tx36 for powerpc-apple-darwin and these are the results after calibrating the credits. Everything seemed to work until I restarted BOINC Manager.

CC calibration: blocked [negative calibration limit] 13.30 >> 8.44 (time: 6598s >> 4081s / Gfpops: 1.02 >> 1.10)
CC calibration: blocked [negative calibration limit] 13.25 >> 8.40 (time: 6568s >> 4063s / Gfpops: 1.02 >> 1.10)
CC calibration: blocked [negative calibration limit] 12.07 >> 8.29 (time: 5988s >> 3912s / Gfpops: 1.02 >> 1.20)
...
CC calibration: 12.69 >> 23.81 (time: 6294s >> 7173s / Gfpops: 1.02 >> 3.27)
CC calibration: 12.70 >> 24.47 (time: 6300s >> 7261s / Gfpops: 1.02 >> 3.36)
CC calibration: 12.92 >> 25.51 (time: 6409s >> 7464s / Gfpops: 1.02 >> 3.44)
CC calibration: 11.78 >> 23.77 (time: 5840s >> 6864s / Gfpops: 1.02 >> 3.52)
CC calibration: 12.77 >> 26.34 (time: 6333s >> 7510s / Gfpops: 1.02 >> 3.59)
....
this went on for over 30 consecutive WU's.

after I restarted the BOINC Manager calibration seems to be starting all over again:

CC calibration: 12.76 >> 26.85 (time: 6329s >> 7566s / Gfpops: 1.02 >> 3.67)
-->RESTART<--
[---] truXoft add-on: calibrate_credit = SETI@Home
CC calibration: blocked [negative calibration limit] 13.28 >> 8.85 (time: 6625s >> 4237s / Gfpops: 1.01 >> 1.15)
CC calibration: blocked [negative calibration limit] 12.96 >> 8.64 (time: 6466s >> 4135s / Gfpops: 1.01 >> 1.15)

Is this normal? I just closed the application and opened it again after a restart.
Does it always start over again every time I restart the BOINC client?
Anybody else experienced similar behavior?

Thanks a lot!

Hi,

I don't know if this off-topic here but,
I have been using BOINC client version 5.3.12.tx36 for powerpc-apple-darwin and these are the results after calibrating the credits. Everything seemed to work until I restarted BOINC Manager.

[snip]

Is this normal? I just closed the application and opened it again after a restart.
Does it always start over again every time I restart the BOINC client?
Anybody else experienced similar behavior?

Thanks a lot!

Definately not off topic. Trux's calibrating client sometimes takes 20-30 or more WU's to start calibrating correctly. It will start off like what you saw, the negative, but over time it starts adjusting appropriately. Let it continue to run, don't keep exiting and re-starting it. Its doing exactly as it should.

Jeremy

---