I just switched over from SETI classic to BOINC/SETI and I am enjoying it. I am using the optimized versions 4.27 BOINC and 4.11 SETI which cut my wu time in half went from 4 hours to 2 hours on all my machines.

I have 2 workstations with P4 1.8 Ghz with SSE2 optimized, 1 laptop with P4 1.8 GHz mobile with SSE2 optimized, and 1 workstation P4 3.0 Ghz with SSE3 optimized.

I was checking my results to make sure that I was actually providing good results which I am. I have yet to have a computation error or rejected results, and I am getting anywhere from 30% to 50% more credit than I am reporting.

My question though is why is the pending credit offline, it seems to have been that way for about a week now. Is that feature going to be turned on again? It would be nice to know how much outstanding credit I have "queued." TIA.

HokieForever

That link has been turned off since I moved over to Boinc several months ago. From what I understand that feature is not going to be turned back on anytime soon, if at all. It's just not a high priority I think. If you do a search I'm sure you'll find other threads dealing with this issue, as well as the dev's responses.

Happy Crunching. :)

I just switched over from SETI classic to BOINC/SETI and I am enjoying it. I am using the optimized versions 4.27 BOINC and 4.11 SETI which cut my wu time in half went from 4 hours to 2 hours on all my machines.

I have 2 workstations with P4 1.8 Ghz with SSE2 optimized, 1 laptop with P4 1.8 GHz mobile with SSE2 optimized, and 1 workstation P4 3.0 Ghz with SSE3 optimized.

I was checking my results to make sure that I was actually providing good results which I am. I have yet to have a computation error or rejected results, and I am getting anywhere from 30% to 50% more credit than I am reporting.

My question though is why is the pending credit offline, it seems to have been that way for about a week now. Is that feature going to be turned on again? It would be nice to know how much outstanding credit I have "queued." TIA.

HokieForever

Pending Credit has been off for many months now.
It has to do with perfomance issues. Its return has been asked for several times, but performance issues are always the answer.
All you can do is scroll through the Results page and add it up yourself ;(
Personally I cannot see how much extra work the database needs do - it already reports results fine, how much is it to filter on Granted=Pending?

---

Thanks for the info Digger. Now for the stupid question, how do you search, I must be going crazy because I cannot find a link to search anywhere in this forum. I had been using google and sometimes coming up with results in the forum. That is why I asked the question because I could not find any information as to if/when it was coming online.

HokieForever

Nevermind just found the search link it is on the main message board page listing all the message boards. I was only looking for the search link with in each message board. DOH!!

HokieForever

---

Test

---

Pending Credit has been off for many months now.
It has to do with perfomance issues. Its return has been asked for several times, but performance issues are always the answer.
All you can do is scroll through the Results page and add it up yourself ;(
Personally I cannot see how much extra work the database needs do - it already reports results fine, how much is it to filter on Granted=Pending?

Pending Credit would cause what we call a "Full Table Scan" for each use. What that means is that the database would have to look at each record to get the data it needs.

As part of the fundamental design of the BOINC server side components we have what amounts to a transaction oriented database (the issue, updating, and removal of results) with a standard datastore (forums, participant data) and this means that the balance between the two needs is very delicate.

For a transaction database the design calls for few, if any indexes beyond the primary key because each index has to be updated for each transaction. We can go back to my old analysis of the design where my reaction to having 10 indexes on the database was not, um, favorable.

With a more traditional datastore, where the transaction count is low and most access is for read (SELECT), having a large number of indexes is common.

We did not have access to any of this data in the older projects, but it is very easy to become "spoiled" and addicted to the convience features.

From a data analysis standpoint the page returned nothing of value as it was a list of the Work Unit IDs and a summary of the requested credit.

---

If the pending credit link is unlikely to be 'turned back on' why not just remove it compleatly, rather than leave it tantilisingly in sight, but not working?

Also it seems to me, from a non programmers point of view, that the amswer to the database search thing Paul mentioned ("full table scan") might be to only update the link 'pending credit' points to daily, when the XML export file is generated. It in effect would show only 'pending credits' that are old. That way I think it would mean it was the backup server that did the work, not the main database server? After all a result I return now that is pending now might get granted before the XML file was generated.

Don't make it a dynamic link, just a static one, reporting all credited "pending on or before XX:XX:XX UTC" and update once a day?

---

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

Pending Credit has been off for many months now.
It has to do with perfomance issues. Its return has been asked for several times, but performance issues are always the answer.
All you can do is scroll through the Results page and add it up yourself ;(
Personally I cannot see how much extra work the database needs do - it already reports results fine, how much is it to filter on Granted=Pending?

Pending Credit would cause what we call a "Full Table Scan" for each use. What that means is that the database would have to look at each record to get the data it needs.

As part of the fundamental design of the BOINC server side components we have what amounts to a transaction oriented database (the issue, updating, and removal of results) with a standard datastore (forums, participant data) and this means that the balance between the two needs is very delicate.

For a transaction database the design calls for few, if any indexes beyond the primary key because each index has to be updated for each transaction. We can go back to my old analysis of the design where my reaction to having 10 indexes on the database was not, um, favorable.

With a more traditional datastore, where the transaction count is low and most access is for read (SELECT), having a large number of indexes is common.

We did not have access to any of this data in the older projects, but it is very easy to become "spoiled" and addicted to the convience features.

From a data analysis standpoint the page returned nothing of value as it was a list of the Work Unit IDs and a summary of the requested credit.

I'm often faced with this sort of issue in Access.
The solution there is simple, create two queries. The first filtering
data according to which fields have indexes, then using the results of this
query as the source for the second which filters/sorts only the data returned.
Never needs a full table scan.There is a table scan, but only on the small temporary data created by query one.

I assume this cannot be done with web-page database work?

---

Just my opinion, but personally I don't find this to even be an issue. Granted I don't crunch as much as a lot of users, so it's not much trouble to simply go back through my results and look for the pending units. It's pretty rare I even feel the need to do that. Perhaps it's more of an issue to everyone else, but I wouldn't have a problem if the option was simply removed altogether.

Dig

Also it seems to me, from a non programmers point of view, that the amswer to the database search thing Paul mentioned ("full table scan") might be to only update the link 'pending credit' points to daily, when the XML export file is generated. It in effect would show only 'pending credits' that are old. That way I think it would mean it was the backup server that did the work, not the main database server? After all a result I return now that is pending now might get granted before the XML file was generated.

No. :)

The data shown on the web site is not connected in anyway to the stats information with the exception of the statistics pages. So, you cannot get there from here ... :)

@Mike.

As far as doing any kind of sub-scan, temporary table, etc. you still wind up with one full table scan.

With other comercial database engines like Oracle and I think DB2 now, you have a "bit-mapped" index that would allow a fast index scan because you could add a pending flag and index that. However, the version of MySQL being used does not have these types of indexes. As a matter of fact I don't think any of the veersion 4 have it yet. I have not looked to see if they will be in version 5 or not.

Even so, we still have the "tension" of the data base types and it is nearly impossible to balance the requirements of the two types. With transaction oriented databases you are doing large numbers of record changes (inserts, updates and deletes) and for almost all of that work you usually only need the PK.

For a data oriented (normal type of database) SELECT statements predominate and with this class you can then add indexes to your hearts content. But each index slows down all other activities. They only have the potential to add speed to queries. One of the falacies novices cling to is that performance problems can be improved with the addition of an index.

==========
Removing the page means that projects like Predictor@Home cannot then have that page. So, that is not a good alternative either. Though I could suggest that a configuration paramater might be appropriate to "hide" this standard page for sites like SETI@Home that don't want to use it ... It is just not a priority as it sits now ...

---

I'm often faced with this sort of issue in Access.
The solution there is simple, create two queries. The first filtering
data according to which fields have indexes, then using the results of this
query as the source for the second which filters/sorts only the data returned.
Never needs a full table scan.There is a table scan, but only on the small temporary data created by query one.

This was discussed as was only providing the link upto 24 hours AFTER you first click on it, so the database would do a nightly run but only update for those that had clicked on the link within the last x days. It was all shelved "for now" because of other higher priority goings on. i.e. Classic shutdown, keeping Boinc up and running full time, etc.

---