[alexkan]

It has come to my attention that more work units are failing validation, at least on halimedia's machines. Depending on how bad this gets, I may have to pull alpha-6 temporarily. If you encounter a work unit that fails, grab it using the tool on Rick's website and contact me. (I may not have enough room in my inbox for them all, but I'll make room.)

Edit: Actually, yeah, this is bad. I'm removing the link. Send me failed work units if you already have the client.

[alexkan]

Ack, quick reply is wonky. Double post removed.

[Todd Madson]

Got it to run on the gui finally, copied the fft_wisdom file over and running now.
Stay tuned for results.

[Todd Madson]

First block 51:56, second 52:53 according to the Boinc Manager and that's with
running other things in the background. Impressive. I was usually just under or
just over an hour with Alpha5 (3600-4200 seconds typically).

We'll see how it goes tonight thru tomorrow.

[Knightrider]

My 26 wu's with A6 are valid ones so far, but they all have this entry on the wu page.

<core_client_version>5.2.15</core_client_version>
<stderr_txt>
OS X Altivec-optimized S@H application by Rick Berry and Alex Kan
version: EXPERIMENTAL alpha-6 (not for public distribution)

failed to load FFTW wisdom from bigfft_wisdom
using FFTW_ESTIMATE plan generation
OS X Altivec-optimized S@H application by Rick Berry and Alex Kan
version: EXPERIMENTAL alpha-6 (not for public distribution)

failed to load FFTW wisdom from bigfft_wisdom
using FFTW_ESTIMATE plan generation

</stderr_txt>

An example :- http://setiathome.berkeley.edu/resul...ltid=218107283


K.

[Todd Madson]

And mine here (valid with 36.81 credit) says:
http://setiathome.berkeley.edu/resul...ltid=217565117

"<core_client_version>5.2.13</core_client_version>
<stderr_txt>
OS X Altivec-optimized S@H application by Rick Berry and Alex Kan
version: EXPERIMENTAL alpha-6 (not for public distribution)

successfully loaded FFTW wisdom from bigfft_wisdom
OS X Altivec-optimized S@H application by Rick Berry and Alex Kan
version: EXPERIMENTAL alpha-6 (not for public distribution)

successfully loaded FFTW wisdom from bigfft_wisdom
OS X Altivec-optimized S@H application by Rick Berry and Alex Kan
version: EXPERIMENTAL alpha-6 (not for public distribution)

successfully loaded FFTW wisdom from bigfft_wisdom"

[Todd Madson]

Next two 41:57 and 42:06 - much better!
--
Update: looks like 8 have gone thru, one has been accepted, the remainder are pending.
I have not had any rejected yet. If you pull up the url for my machine you'll see some
failed and that was under A5 when I was trying to STOP it so I could install A6.

I'll keep an eye out for any that fail and will pm you.

[Lauger]

Alex,
Are you saying to NOT run A6 right now?

[alexkan]

Originally Posted by Lauger

Are you saying to NOT run A6 right now?

Yes, unless you're willing to help me debug alpha-6 by watching for work units that fail validation, and hanging on to them for me to test. (My inbox has a finite amount of space, so PM me if you're willing to do this.) I have no idea how bad the error rate is right now, and since I'm working off a new code base, I'll need more time to track the bugs down and squash them.

[halimedia]

Originally Posted by Knightrider

My 26 wu's with A6 are valid ones so far, but they all have this entry on the wu page.
...
failed to load FFTW wisdom from bigfft_wisdom
using FFTW_ESTIMATE plan generation
...
</stderr_txt>

It looks like you have either placed bigfft_wisdom in the wrong spot, or you haven't generated one using fft_test2. If the latter is the case, I'd suggest you create one - it will pay off doubly! The correct location for bigfft_wisdom is /Library/Application Support/BOINC Data/ (note that this is *not* the user library!). If the directory does not exist (e.g. if you're using BOINC Menubar, which stores its data in ~/Library/Application Support/BOINC Data/), you need to create it and stick bigfft_wisdom in there.

HTH,

Ron

[Todd Madson]

Update: So far it appears that 5 out of 27 work units have been approved, the rest
are all pending. So far there have been no rejections. And right now I'm generating
work units about every 30-40 minutes. Unreal.

[Mark Asiala]

Update on my DP 2.5 G5: I completed 20 WUs. 8 have verified, 1 is invalid, and 11 are pending but 2 of the 11 WUs are showing 3 results returned for that WU with status "Checked, but no concensus yet". This makes me think that those two WUs may turn up invalid as well. The other pending credit WUs do not have enough returned results yet to validate.

I do not plan on downloading more workunits until another version of alpha-6 is released. (I'm otherwise running EAH 100% on my G5 chasing my team's #1 position right now).

[TiloProbst]

Originally Posted by alexkan

(They're named 'bigfft_wisdom', if you hadn't noticed them before.) You'll need to place bigfft_wisdom in /Library/Application Support/BOINC Data. If you've got your BOINC support files installed somewhere else...I'll have to figure out how to deal with you, since the wisdom path is currently hard-coded.

I've posted results for fft and fft2 tests before, so could I please get an Alpha6 client?

btw my Application and Data folder is /Applications/Boinc5/ .. so what can I do?

could I stay with -dir /Applications/Boinc5/ , then put the wisdom file in Library/Application Support/BOINC Data/ and everything will run fine?

EDIT: Here are the numbers vor my 2x2GHz G5 (non DualCore), locally '>console' login, remotely started via ssh

OS 10.4.2, 1 GB of RAM (2x2x256), PC3200U
Hardware Overview:
Machine Name: Power Mac G5
Machine Model: PowerMac7,3
CPU Type: PowerPC G5 (3.0)
Number Of CPUs: 2
CPU Speed: 2 GHz
L2 Cache (per CPU): 512 KB
Bus Speed: 1 GHz

q033:/ tiloprobst$ /Applications/fftw_tests/fft_test2
Apple vDSP op / ip
1024 8603.700513 7989.150476
2048 9113.549432 8023.885913
4096 8302.127505 7895.160471
8192 4793.490286 4591.659116
16384 4944.863663 4674.249234
32768 1810.490935 3544.482254
65536 1042.467790 1777.718252
131072 1067.212992 1170.103270

weighted time 13.650000 11.470000 10.690000

FFTW3 interleaved op / ip (this may take a minute)
1024 8947.848533 6918.439588
2048 8202.194489 4585.077665
4096 7743.330462 5096.875747
8192 6462.335052 4235.025398
16384 4971.026963 3947.580235
32768 3400.787027 2827.620674
65536 2177.975302 2097.152000
131072 1782.579200 1687.648947

weighted time 7.850000 8.300000

[Todd Madson]

Update: 02Feb06:
Approved: 112
Pending: 94
Client Errors: 0
In Process: 10

[alexkan]

Quick update...(plus bonus rant)

It's going to take me a while to sort out what's actually wrong with the worker right now. From what I can tell, the changes I made to change FFT methods hasn't changed the results, since I'm getting the impression that rolling back my FFTW hybrid thing results in a client that produces (nearly) identically invalid results on the work units I've been sent. So it's going to be a bit of digging through our code and the reference code with MATLAB in hand, figuring out where things went south, and how much speed it'll cost to fix things.

Some good news, though--I've found what looks like the code to alpha-5. I might try making the same set of changes to add FFTW support and rereleasing the result as alpha-5.5 or something. Awful naming scheme, I know. Give me some time, though--I have other things on my plate right now. IIRC, none of the alphas have ever been totally 100% on validation, but it seemed like they were better.

Speaking of which, in the name of giving the SETI project good science, I'm now going to recommend that anyone who's still running alpha-6 to stop now, collect all invalid work units, unleash them upon my Gmail account (my account name at gmail.com), and go back to alpha-5. I'm getting more and more uncomfortable with the idea of allowing a client I know isn't working totally right to be returning work units, especially at the pace it currently finishes them.

The following is something of a rant regarding my efforts to fix alpha-6. Feel free to ignore it completely.

It's times like this that I wish I had taken a numerical analysis course somewhere in the past. The idea of validating against a reference client seems like such a shaky proposition, since the reference client isn't free from floating-point error, especially given that it, too, computes everything in single precision. It would be nice if the algorithms in SETI were documented somewhere and there was some system to test our functions against some canonical double-precision implementation, but you can't have everything, I guess.

Either way, writing MATLAB code to perform the equivalent results has been an interesting experience. I can only hope that I'll catch the bug before I burn out.

[Todd Madson]

Update:

Who all received invalid results? Halimedia?

Was it one machine or all machines?

I'm experiencing smooth sailing thus far - no client errors.

[Karl Schimanek]

Me, too.
15 of 300 invalid. No more than in alpha5 so far, IMO.

[halimedia]

Let's be clear about this: we're not talking about client errors. These are rare, and are most frequently caused by rogue WUs (i.e. the whole quorum will error-out). The problem that alpha-6 causes are *invalid* WUs - the WU results upload successfully, but do not validate. This is indicated by SETI granting 0.00 credits for the completed WU. You can see the 'validation: failed' status when looking at the result details.

As far as I understand from my correspondence with Alex, he has discovered at least some of the problems with alpha-6, and they are quite serious from a scientific standpoint. Therefore, alpha-6 should no longer be used - as stated by Alex previously. Remember: this is not primarily a race - it's about science!

I hope I'm not sticking my neck out by saying this, but I'm now testing a pre-release build of alpha-5.1 provided to me by Alex. It includes some improvements upon alpha-5, uses FFTW like alpha-6 does, but is siginifcantly slower than alpha-6 (and in the case of my Quad, even slower than alpha-5). The good news is that we have yet to see an invalid result, and that's what really matters. Alex says that he has some optimizations up his sleeve that should improve performance of this worker, but it will take some time for him to implement them. In the meantime, we'll watch the validation record of the pre-release build to be sure it behaves as expected.

HTH,

Ron

[halimedia]

Originally Posted by Karl Schimanek

Me, too.
15 of 300 invalid. No more than in alpha5 so far, IMO.

This has been my experience, too - roughly 5% of all alpha-6 results are invalid. That's a lot!!

[Mark Asiala]

Originally Posted by halimedia

This has been my experience, too - roughly 5% of all alpha-6 results are invalid. That's a lot!!

I think that is higher than my alpha-5 rate although I do not have 100 results to look at in order to get a more stable estimate. If I had to guess, I would think that the alpha-5 rate has been more on the order of 1-2%.

(...some thoughts I have on the production vs. accuracy issues...)

This raises the question in my mind, however, that if the system is designed to confirm results by consensus and powermacs are in the minority, is a slightly higher invalid rate tolerable if the system is there to catch them? I realize there is some probability that 2 or more powermacs using the alpha-x clients both have invalid results but are validated by concensus but with the new client we could cover 50% more workunits, at least from the powermac's contribution. It would seem that the potential increased contribution to the science based on greater productivity could offset the 3-4 percentage point increase in invalid results.

Further, I don't know the mechanism of the source code and the tolerance on the validation, but it also seems possible that the performance tweaks actually have less precision error but the other results are clustered and the majority rules approach could invalidate a result that is actually better.

Just my $0.02.

[alexkan]

Originally Posted by Mark Asiala

This raises the question in my mind, however, that if the system is designed to confirm results by consensus and powermacs are in the minority, is a slightly higher invalid rate tolerable if the system is there to catch them? I realize there is some probability that 2 or more powermacs using the alpha-x clients both have invalid results but are validated by concensus but with the new client we could cover 50% more workunits, at least from the powermac's contribution. It would seem that the potential increased contribution to the science based on greater productivity could offset the 3-4 percentage point increase in invalid results.

Further, I don't know the mechanism of the source code and the tolerance on the validation, but it also seems possible that the performance tweaks actually have less precision error but the other results are clustered and the majority rules approach could invalidate a result that is actually better.

Just my $0.02.

As far as I'm concerned, a higher invalid rate (I consider alpha-6's invalid rate to be significantly higher) isn't acceptable, because the changes that I made in between alphas 5 and 6 haven't really done anything special with regard to changing how the program calculates anything. In short, I was just using one math library in place of another--this isn't some sort of speed vs. accuracy tradeoff, at least in this case.

I believe there have been times in the past where performance tweaks really do have less precision error than the reference results. In general, computing sums of a large number of floating-point numbers is a bad idea (Google for "Kahan summation" if you want to see what I'm talking about), so some of the sums we've replaced with library calls should, in theory, result in a more accurate client than before. In any case, this situation is not one of them.

I'm still testing out different compiles of alpha-5.1 (or alpha-5.2, depending on what I decide to call it). What halimedia said about performance decreases is mostly gone. I'll have more conclusive numbers later, but for now, I just want to make sure my results are still validating. I hope the SETI project forgive me for the workunits my testing clients have botched.

[Mark Asiala]

Originally Posted by alexkan

As far as I'm concerned, a higher invalid rate (I consider alpha-6's invalid rate to be significantly higher) isn't acceptable, because the changes that I made in between alphas 5 and 6 haven't really done anything special with regard to changing how the program calculates anything. In short, I was just using one math library in place of another--this isn't some sort of speed vs. accuracy tradeoff, at least in this case.

I appreciate the more detailed reply. I guess what we need to keep in mind is the performance gains relative to the stock client with a lower invalid rate already achieved and to keep along that path.

The 'kahan summation' link was interesting, it reminds me of a process of 'Controlled Rounding' that we use in my work for controlling roundoff error when integerizing a long set of numbers. I took one numerical analysis class in grad school. It was interesting to see how many math Ph.D students had no concept of machine precision until they took that class.

[Todd Madson]

Alex: the one thing I noted in the old Seti Classic was that some of the same workunits
were processed by multiple individuals computers - I'm sure the same thing will happen
here for redundancy's sake.

It will be interesting to see the changes in the forthcoming alpha 5.1 (or 5.2).
If the performance decreases can be negated and the science improved then
there should be no objections by the "speed freaks" to going to this new client
once it's been tested thoroughly.

There really should be a reference unit that has a known final result that can
be tested but in a way real-world testing would be more indicative of proper
operation.

[Fortilan]

Hi everyone,

I am a new MacNN Forums user. I have recently installed the Altivec workers and optimised clients and have really benefited from the improvements, thanks to the members that have done this.

In return, I would like to offer the resources I have on my Mac's to see if I can help improve the workers/clients further.

I am currently running the 5.2.13 client.

Here's hoping I can help.

Regards, Fortilan

=== a little bit about me ===
I live in Sydney Australia. I have 3 Mac's at the moment, a G5 1.8GHz, a Mac mini G4 1.5Ghz, and a 12" Powerbook G4. All are running OSX 10.4.4.

[Fortilan]

Here are my results for the fft_test if it is still interesting to people on the forum:

Hardware Overview:

Machine Name: iMac G5
Machine Model: PowerMac8,1
CPU Type: PowerPC G5 (3.0)
Number Of CPUs: 1
CPU Speed: 1.8 GHz
L2 Cache (per CPU): 512 KB
Memory: 768 MB
Bus Speed: 600 MHz
Boot ROM Version: 5.2.2f2

Results of test

Standard Ooura
8 1572.864000
16 1048.576000
32 1747.626667
64 2097.152000
128 2446.677333
256 2097.152000
512 2359.296000
1024 2621.440000
2048 2306.867200
4096 2516.582400
8192 2271.914667
16384 1835.008000
32768 1123.474286
65536 986.895059
131072 575.025548
262144 510.118054
Optimized Ooura
8 1048.576000
16 1398.101333
32 2621.440000
64 1572.864000
128 1835.008000
256 2796.202667
512 2359.296000
1024 2621.440000
2048 2306.867200
4096 2516.582400
8192 2271.914667
16384 1835.008000
32768 1310.720000
65536 1048.576000
131072 575.025548
262144 510.118054
Apple vBigDSP
8 393.216000
16 1398.101333
32 2621.440000
64 3145.728000
128 3670.016000
256 4194.304000
512 4718.592000
1024 5242.880000
2048 5767.168000
4096 4194.304000
8192 3407.872000
16384 2097.152000
32768 1209.895385
65536 986.895059
131072 810.263273
262144 471.859200
Apple Altivec DSP
8 1572.864000
16 4194.304000
32 5242.880000
64 6291.456000
128 7340.032000
256 8388.608000
512 9437.184000
1024 5242.880000
2048 5767.168000
4096 6291.456000
8192 4543.829333
16384 4893.354667
32768 3145.728000
65536 1398.101333
131072 891.289600
262144 754.974720
FFTW3 (this may take a minute)
8 1572.864000
16 2097.152000
32 2621.440000
64 3145.728000
128 2446.677333
256 8388.608000
512 4718.592000
1024 10485.760000
2048 3844.778667
4096 4194.304000
8192 4543.829333
16384 3670.016000
32768 2621.440000
65536 1864.135111
131072 1485.482667
262144 1451.874462


I hope this helps the cause

[alexkan]

Originally Posted by Fortilan

Here are my results for the fft_test if it is still interesting to people on the forum:

I hope this helps the cause

Look for the link to fft_test2. You'll find that its results will be both more informative and more predictive of your results with the upcoming alpha-5.2. fft_test2's results are also a lot more interesting to me. Your results will also be useful for actually running alpha-5.2 once I release it, as I don't know of anyone else who has a bigfft_wisdom file for an iMac G5 at this point. (Read the post describing fft_test2 if you don't know what bigfft_wisdom is.)

Give yourself an hour or two to run fft_test2. You'll want to do it with as few processing running as possible. When you're finished with that, post those results (maybe clearing out the fft_test results in the process) and contact me about sending me your bigfft_wisdom.

For the rest of you, alpha-5.2 should be out maybe tomorrow or Monday. As with alpha-6, expect negligible or possibly even negative speed gains on G4s, but a hefty boost on G5s, inversely proportional to the number of processors. It's already looking quite reliable, but a day or two more of solid testing never hurt anyone.

[Todd Madson]

Alex: do we need to generate a new bigfft_wisdom file for alpha-5.2 to work properly
if we were previously running alpha-6?

Also, see:
http://pod.ath.cx/someworkunits.jpg

This was indicative of the processing times while I was using the machine. When I was
away most of yesterday (wife's birthday, continuing celebrations today) I was seeing
times in the 34-36 minute range. It seemed to be speeding up.

[alexkan]

Originally Posted by Todd Madson

Alex: do we need to generate a new bigfft_wisdom file for alpha-5.2 to work properly if we were previously running alpha-6?

There is no need for new bigfft_wisdom files for the upcoming switch to alpha-5.2. (It would be sadistic of me to require you all to run hours of benchmarks every time I release a new version...unless a new version of vDSP or FFTW comes out.)

Also, just to let you know ahead of time, alpha-5.2 will loosen the restrictions on where you need to put bigfft_wisdom. All you need to do now is put it in the same location as the worker binary. Hopefully, this will solve issues with all of you who didn't put your BOINC data in the same place that I did.

[virex]

In anticipation of this being released, does anyone have a wisdom file for the quad g5 that i could get?

[alexkan]

Originally Posted by virex

In anticipation of this being released, does anyone have a wisdom file for the quad g5 that i could get?

Courtesy of halimedia: http://inst.eecs.berkeley.edu/~alexk..._pm_g5_qc_2500 (you'll have to rename it to bigfft_wisdom)

Also, since I said Sunday or Monday and validation results are looking very good, here's alpha-5.2 as promised: http://inst.eecs.berkeley.edu/~alexk...lpha-52-g5.tgz

My apologies to G4 users--there will be no G4 release of this version. Also, this compile will not run on G4s, since it uses G5-specific instructions. Frankly, there doesn't seem to be a performance increase from what I've done this time around, since other factors negate the advantage of a slightly faster FFT. Maybe in the next release...

As mentioned before, all you have to do with the wisdom is put it in the same directory as the application and app_info.xml. As before, you'll be able to tell whether or not wisdom loaded successfully by looking in the results for each WU for the message "successfully loaded FFTW wisdom from bigfft_wisdom".

[Todd Madson]

Alex: what are you seeing in terms of crunch times versus alpha 5? alpha 6?

Does anyone have a bigwisdom file for a G5 2Ghz Dual that they would like to share?

[Mark Asiala]

Originally Posted by Todd Madson

Alex: what are you seeing in terms of crunch times versus alpha 5? alpha 6?

I'm getting times very close to alpha-6, maybe even a tad better but too few to tell at this point. Same speed and better validation rates, best of both worlds!! Kudos, Alex.

[TiloProbst]

well, while I don't think it is a good idea to exchange those wisdom files because they might have been created under different conditions, I provide direct links to mine:

wisdom file for Dual 2,0 G5 with 1 GB of RAM

wisdom file for Single 1,8 G5 with 500 MB of RAM (900 Mhz FSB!)

I recently spoke to a Seti team pal using a PC about the Quad Mac hitting the 4K RAC mark. he said that validation error rates of about 5% are absolutely common among PC client users like him, and he wondered why we would make such a fuss about it :-/ I am not trying to imply that we are over-reacting, actually I think that this issue is our chance to act as an good example

[alexkan]

Originally Posted by TiloProbst

well, while I don't think it is a good idea to exchange those wisdom files because they might have been created under different conditions, I provide direct links to mine:

wisdom file for Dual 2,0 G5 with 1 GB of RAM

wisdom file for Single 1,8 G5 with 500 MB of RAM (900 Mhz FSB!)

I recently spoke to a Seti team pal using a PC about the Quad Mac hitting the 4K RAC mark. he said that validation error rates of about 5% are absolutely common among PC client users like him, and he wondered why we would make such a fuss about it :-/ I am not trying to imply that we are over-reacting, actually I think that this issue is our chance to act as an good example

Thank you for providing those links, TiloProbst. You make a good point about different conditions for creating wisdom files, but hopefully these (and the ones I'll be posting eventually) will be helpful for those who don't want to mess around with stopping all work on their computesr and running FFT benchmarks for hours.

As for the validation issues, a similar thing was discussed when Howard Naparst was bringing out his clients, and eventually all the math issues were sorted out so that those clients (and their descendants, like Crunch3r's) should validate all the time as well. So in some sense, they've already set the example, and who are we to sacrifice accuracy for speed when it doesn't have to be that way?

Also, going from a 95% validation rate to a 100% validation rate is like a 5.26% boost in RAC, so who would refuse that?

Originally Posted by TiloProbst

wisdom file for Dual 2,0 G5 with 1 GB of RAM

Thanks, TiloProbst, I'll try it out...
Alex, what format should the bigwisdom file be? (Firefox's default assumes this is an HTML file.) And does it need to be names precisely "bigfft_wisdom"? (e.g. tiloProbst's is named "bigfft_wisdom_dual20g5") With or without an extension?

[alexkan]

Originally Posted by Andrew F

Thanks, TiloProbst, I'll try it out...
Alex, what format should the bigwisdom file be? (Firefox's default assumes this is an HTML file.) And does it need to be names precisely "bigfft_wisdom"? (e.g. tiloProbst's is named "bigfft_wisdom_dual20g5") With or without an extension?

It's just a text file. You should be able to open it up in a text editor and look at it. (Just don't edit it.) It does need to be named exactly "bigfft_wisdom", with no extension.

[TiloProbst]

@alexkan
funny you mention crunch3r, I know him from the planet3dnow forums

EDIT: sooner or later you will have to edit your start post of this thread, providing links for wisdom files .. not to speak about links to the most important bits of this thread

hmm the PC pal I spoke about actually uses crunch3rs client, achieving a 95% validation rate he said ... I will check on this if I don't forget.

I installed v5.2 on my Single 1,8 .. calculation times went down from ~4700-5200 to ~3200 .. so that is maybe a 35% gain from v5.0 to v.5.2 .. wow!

[Todd Madson]

Wisdom file for a G5 2.5 dual is here:
http://pod.ath.cx/wisdom/

[alexkan]

Kind of forgot to take care of some license issues. I'm taking the link down until I sort out the nitty-gritty of using FFTW, since it's GPLed. As far as I know, this should just be a matter of releasing our source code (which was GPLed to begin with) and adding the requisite notices.

Edit: OK, it's back up. Here's the source code, as required by both SETI BOINC and FFTW's licenses.

I'll be relinking the binary with the release version of FFTW in the next couple of days. (In practice, "the next couple of days" from me probably means tonight or tomorrow, since I prefer SETI to doing real schoolwork.)

[Mark Asiala]

Update for alpha-52 on my DP G5 2.5:
56 units complete, 30 have validated and 26 are pending. There have been no confirmed invalids yet.

Of those 26, however, 2 show three results returned without concensus. On both of those workunits, there is one other person using an intel optimized client (one Crunch3r, one Tetsuji Maverick Rai) so it is possible that the issue is with their result and not mine.

Times have been running along two streaks with one set around 2400 and recently I've had a streak of 1800-2000 seconds (perhaps getting easier workunits).

[TiloProbst]

v5.2 is now running since maybe 9 hours on my Dual 2.0 G5.

the amount of WUs in stock increased from ~300 to 400+ .. of maybe 20 WUs completed since then all WUs have been granted credits, only one pending. calculation time went down from something 4200-4600 to 2900-3100 ..

embarassing to see that in Summer 2005 I got ~240 RAC for the workers from the official Seti website, while now RACs of 1000+ are in range.

asked my friend on validation rates of his crunch3r clients for PC. he corrected me saying that the 95% validation rate was for the client he used before, while crunch3r achieves 99%+.

[gorbag]

When you guys are posting wisdom files, does "dual" mean dual core or dual processor? Maybe something more descriptive than "dual 2.0 g5" is needed, since there are several models that could be described that way...

[Rocketman Karl]

I'm running alpha-5 on a MDD Dual 1GHz G4. Here's what I'm finding:

1. FAST!. Wow, the official worker used to take about 22000 seconds on average, but a-5 has that down to under 7000. I've been running it since 2/2/06 and I haven't seen any failed validations.

2. But (there's always a but isn't there?), I am noticing that the RAM used by each worker does grow over time. It starts out low (in the 20MB area if memory serves), but by the time the unit is almost done, it's up over 100MB. It doesn't seem to happen all the time (some seem to hover around 24MB), but it seems to be more often than not. If I stop Boinc and start it again, the numbers return back to the 20's, but then grow again. I'm not sure, but it does seem to be associated with the work unit.

[TiloProbst]

Originally Posted by gorbag

When you guys are posting wisdom files, does "dual" mean dual core or dual processor? Maybe something more descriptive than "dual 2.0 g5" is needed, since there are several models that could be described that way...

I don't think so, a "Dual 2.0" is not a "Dualcore 2.0" or "DC 2.0" in short.

the wisdom files I posted have been generated on a Dual 2.0 or Single 1.8 respectively.

[alexkan]

Originally Posted by Rocketman Karl

2. But (there's always a but isn't there?), I am noticing that the RAM used by each worker does grow over time. It starts out low (in the 20MB area if memory serves), but by the time the unit is almost done, it's up over 100MB. It doesn't seem to happen all the time (some seem to hover around 24MB), but it seems to be more often than not. If I stop Boinc and start it again, the numbers return back to the 20's, but then grow again. I'm not sure, but it does seem to be associated with the work unit.

alpha-5 (as opposed to alpha-5.2) has a small memory leak in the Gaussian fitting code, courtesy of yours truly. I can and probably should recompile the client to fix this. Keep your eyes peeled.

[Todd Madson]

I'm typing this from a hotel room over 600 miles away from my Mac
right now - I started Alpha 5.2 this morning at 6:30 a.m. CST.

I don't see any problems so far that I can see. I'll keep you posted
as to problems - it appears to be generating work as fast as Alpha 6
for the most part but for some reason more credit is being applied
so my RAC is at an all-time high.

Speeds I've seen are generally 1900-2300 seconds, some stragglers
are in the 2500-2600 range but this is the minority and still far less
than the performance under Alpha 5. More later.

[alexkan]

Originally Posted by Todd Madson

Alex - what do you think about this? This is since 6:40 a.m. CST this morning.
I've since travelled about 600 miles south so am typing this from a laptop in
a hotel room (wireless). I won't be back at my Mac until early next week.

It's generating units at incredible speed but these came out invalid but
I'm not sure why. Ideas? My RAC is rising to an all time high but at
what cost?

It's the corruptive influence of my slightly-buggy alpha-6 release. As you can see from what was printed to stderr, all three of those WUs were touched at some point by alpha-6. These sorts of validation issues were the reason that I pulled alpha-6 and replaced it with alpha-5.2 in the first place.

I wouldn't worry about these for now. If you find a WU processed exclusively by alpha-5.2 that doesn't validate, do let me know.

[Todd Madson]

Sure. I had to edit my message because I looked further and realized they were all
handled by A6. A5.2 - no issues thus far. My laptop screen is far smaller than my
19" LCD I use with my G5. Sigh.

I'll try making my own wisdom file, if it's advisable...
Alex, how do we run this fft2_test in the terminal?