Strange behavour as you say BOINC 6.6.2 Seti NNT plus WU's suspended still downloaded 18 WU's.

edit}

24/01/2009 17:25:11|SETI@home|Sending scheduler request: Requested by user.
24/01/2009 17:25:11|SETI@home|CPU work request: 0.00 seconds, 0 instances
24/01/2009 17:25:11|SETI@home|CUDA work request: 0.00 seconds, 0 instances
24/01/2009 17:25:11|SETI@home|Reporting 1 completed tasks
24/01/2009 17:25:16|SETI@home|Scheduler request completed: got 18 new tasks



Michael.

I had a strange behavior last night with the 6.6.2. SETI was set to No New Work and the Boinc Manager and the work cache to 1 day. Even so I set SETI to NNW the Boinc Manager was loading over 160 Seti extended WUs and 20 Astropuls WUs, thats much ure then the PC can do in one day. As a result he SETU WUs are all running in high prio mode. While I also have other projects running, I had to cancel the most of them.

After a restart of the Boinc Manager the permanent loading of new work stops for a while. Then I restarted the whole PC and the Boinc Manager load again new work although SETI was set to NNW.

What's wrong? Bug in the 6.6.2? I don't will downgrade to 6.6.0 while this is the first version with separate calculation for GPU and CPU.

That exact behaviour has caused me to go back to 6.6.0 after I had received 1800 WU's in 2 days with NNT set for most of the time.

F.

So did I. I now have so many AP's on my Pentium D that I risk not making deadlines .... One day cache on that machine, and it collected what must be a couple of weeks worth of work. I always had trouble getting AP's. I guess that changed :-)

Regards,
John.

I had a try at 6.6.2 also, but had no text in the boinc panels and couldn´t make it work so next day shifted back to 6.6.0
My cache was then filled with 225 AP and 1200 MB workunits ???
Talk about a days work here ??

I just tried 6.6.2 and it worked all fine and dandy except when I went to the tasks tab.... Boinc manager either locks up or crashes to the desktop...

I guess it has a problem with to many tasks... oh well

---

Do you Good Search for Seti@Home? http://www.goodsearch.com/?charityid=888957
Or Good Shop? http://www.goodshop.com/?charityid=888957

Yeah, if you go to your tasks page from your Account page you will probably find it got you a whole herd of new Work Units.

---

PROUD MEMBER OF Team Starfire World BOINC

I just tried 6.6.2 and it worked all fine and dandy except when I went to the tasks tab.... Boinc manager either locks up or crashes to the desktop...

I guess it has a problem with to many tasks... oh well

Did the same thing for me. If you want tons of work on hand though, 6.6.2 is the one you want to have. It keeps downloading work until it hits the daily limit then continues the next day and the next and the next until you downgrade.

---

Boinc....Boinc....Boinc....Boinc....

I just tried 6.6.2 and it worked all fine and dandy except when I went to the tasks tab.... Boinc manager either locks up or crashes to the desktop...

I guess it has a problem with to many tasks... oh well

Did the same thing for me. If you want tons of work on hand though, 6.6.2 is the one you want to have. It keeps downloading work until it hits the daily limit then continues the next day and the next and the next until you downgrade.

Yep, I've certainly noticed that. This is the first time I've ever had over a thousand WUs lined up on the one machine!

Meanwhile, the Linux-CUDA from Crunch3r is working fine. It runs out of VRAM if I've got the KDE4 desktop running. It then completes the WU on the CPU. When logged out, the full process completes in the GPU VRAM. Good stuff...

Now waiting for the 6.6.2 bugfix release!

Happy fast crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

6.6.0 has been stable for me, both on P4 and T5500, XP and vista.

6.6.3 is available

---

Fool me once, shame on me.... I think I'll wait on this one until the reports start coming in. :)

---

PROUD MEMBER OF Team Starfire World BOINC

OK, and the Linux-CUDA is running seet 'n' smooth. Looks like there isn't enough VRAM in 256MB to run the s@h CUDA gaussians checks AND have KDE4 running with multiple desktops. Whilst logged out, there have been no more out-of-memory errors.

Is Fred still around with his results scraper to produce some pretty graphs of the speedup seen? Or is there anyone else with his scraper code?

Happy GPU-fast crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

OK, and the Linux-CUDA is running seet 'n' smooth. Looks like there isn't enough VRAM in 256MB to run the s@h CUDA gaussians checks AND have KDE4 running with multiple desktops. Whilst logged out, there have been no more out-of-memory errors.

Is Fred still around with his results scraper to produce some pretty graphs of the speedup seen? Or is there anyone else with his scraper code?

Happy GPU-fast crunchin',
Martin

Sorry, SETI-Pal can't cope with AstroPulse WU's never mind CUDA. In any case, the CUDA results don't include any useful processor time from what I have seen so there would be nothing to draw graphs from?

F.

---

Sorry, SETI-Pal can't cope with AstroPulse WU's never mind CUDA. In any case, the CUDA results don't include any useful processor time from what I have seen so there would be nothing to draw graphs from?

Good to see you still around.

I was wondering if the new (and multifarious) formats might be 'difficult'.

So what do the time numbers actually indicate?...

Which then comes to how can we measure what speed-up we're getting?...

All I can say at the moment is that it is working and that I've got more WUs stacked up than I've ever had before...

As to how it all adds up?

Any stats junkies out there to the rescue?

Happy fast crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Sorry, SETI-Pal can't cope with AstroPulse WU's never mind CUDA. In any case, the CUDA results don't include any useful processor time from what I have seen so there would be nothing to draw graphs from?

Good to see you still around.

I was wondering if the new (and multifarious) formats might be 'difficult'.

So what do the time numbers actually indicate?...

Which then comes to how can we measure what speed-up we're getting?...

All I can say at the moment is that it is working and that I've got more WUs stacked up than I've ever had before...

As to how it all adds up?

Any stats junkies out there to the rescue?

Happy fast crunchin',
Martin

Well, the CPU time reported is just that - the CPU time taken to feed the GPU. None of the stderr that I have seen include a figure for the GPU time.

So far as I can tell ATM, the only way to measure the improvement is to capture a copy of your BM Messages, work out the wall-time from start to stop of a sample of AR's which can be compared with similar AR's from before you started using CUDA to give a rough approximation of the speed up (since the old records will hold CPU time rather than wall-time).

F.

---

Sorry, SETI-Pal can't cope with AstroPulse WU's never mind CUDA. In any case, the CUDA results don't include any useful processor time from what I have seen so there would be nothing to draw graphs from?

Good to see you still around.

I was wondering if the new (and multifarious) formats might be 'difficult'.

So what do the time numbers actually indicate?...

Which then comes to how can we measure what speed-up we're getting?...

All I can say at the moment is that it is working and that I've got more WUs stacked up than I've ever had before...

As to how it all adds up?

Any stats junkies out there to the rescue?

Happy fast crunchin',
Martin

Well, the CPU time reported is just that - the CPU time taken to feed the GPU. None of the stderr that I have seen include a figure for the GPU time.

So far as I can tell ATM, the only way to measure the improvement is to capture a copy of your BM Messages, work out the wall-time from start to stop of a sample of AR's which can be compared with similar AR's from before you started using CUDA to give a rough approximation of the speed up (since the old records will hold CPU time rather than wall-time).

F.

And getting those AR's is the tedious part of the analysis - I'm sure I can get the runtimes from the logs easily enough.

Any chance you could be persuaded to work up a version of the vac which would simply spit in the eye of any APs and move on?

And getting those AR's is the tedious part of the analysis - I'm sure I can get the runtimes from the logs easily enough.

Any chance you could be persuaded to work up a version of the vac which would simply spit in the eye of any APs and move on?

I'll take my zzzz time to think about that one, if I may?

The following are some of the conflicting inputs to my cogitation:

That ability to run the vac against any host came from its use of the web pages to collect the data. But every time it runs, it has to collect ALL the results still available on the Task pages, dump those which have no value in the CPU time column, check for -9's and dump those and then open up the task page for any that it has not seen before to get the AR and other interesting data (e.g. App version, etc). This can take anything from 20 minutes to an hour when the pipes to Berkeley are NOT clogged for my quaddie (before I added the GPU). It just would not run at all at the moment.

An alternative, I guess - because I have not looked in detail - would be use Boinc LogX to supply some (all?) of the data but this would mean it would be for personal use only; i.e. has to be run by each individual for his/her own machine(s).

It would certainly be useful for building a table of times (assuming we can get GPU times somehow) vs CUDA devices though there may be other wrinkles here that are not apparent (e.g. I was reading on the F@H pages that the newest NVidia beta drivers are noticeable faster that the current recommended - I haven't noticed any speedup in clearing my massive backlog of VLAR's but have noticed a 10 deg C drop in GPU temp). And the only way to build such a table would be to continue the existing method of data collection.

I'm off to cogitate some more...

F.

---

I think I've solved the AR problem, at least for local research.

Adapting Alexander Klietz's work at Beta for locating VLARs to kill manually, I came up with

findstr /p "<true_angle_range>" %1\*.* >> all_ar.txt
start Wordpad all_ar.txt

Notes:

1) The /p avoids listing the program file in the output
2) I'm passing the search location as a parameter (%1), so run this from a shortcut with the actual path to the BOINC Data folder you want to scrape
3) >> appends output to the previous file - will build up a big file, with duplicates
4) Calling Wordpad helps to tidy up the formatting, and also to find and eradicate the surplus result file(s) which will be in the output.

Shouldn't be too difficult to come up with a version suitable for daily scheduling. The output format from findstr is consistent enough to do the next stage of processing in a database: now to work on the start/finish logs.

6.6.3 is available

Thanks!!

Just installed it on three hosts running Raistmer's MB 6.08 mod CPU team Cuda. Purrs along perfectly and is asking for work properly. So far just running Seti main haven't tried letting it play with other projets yet. This is a big step. This looks like the one. At least it is step in right direction. Many thanks to all involved in making this possible.

---

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm... that's funny...'" -- Isaac Asimov

May want to look here first before you get too attached to it...
http://setiathome.berkeley.edu/forum_thread.php?id=51703

---

PROUD MEMBER OF Team Starfire World BOINC

There is also a major bug in the calculations of LTD ... a change was checked in but no new version as yet ... compile your own is Dr. Anderson's advice ...