Work buffer cache settings don't seem to work

Hi,

I've been running S@H for a while now and can't figure something out. I recently changed both my online preferences and my local computing preferences to specify a minimum work buffer of 10 days. I had previously had this setting at .1 day which seems to be the default. I also specify 10 days for the Max additional work buffer. This second option has always been set to 10 days for me.

I made the change because the number of work units that were being cached for me was insufficient for more than about a 2 day downtime of the SETI servers. The problem is that since I made the change, I see no difference in the number of work units in my local work buffer. My machine is regularly asking for more work units, but I get messages that say "The computer has reached a limit on tasks in progress."

I ran out of CPU work units again during the most recent outage on 1/14-1/15. Thus, it doesn't seem that this option works. Does anyone else see this? Is there anything I can do to make it work, or is this a S@H restriction?

Thanks in advance,
Jon



____________

Well, it's been in the News:

Continued server problems.
We're continuing to have issues due to a database problem early last week and a botched attempt to fix it.

The problem is that the result and host tables in the database have grown large enough, and hosts have gotten fast enough that the lookup of result in process for a host and the enumeration of new results to send don't finish before the web connection times out either on the server or the client side. This resulted in hosts being assigned large number or results to compute without the transaction that tells them about these results being completed. The host. think it received no results would then contact the server for more results, which it would again not receive.

This isn't a hardware problem. The database currently fits in memory and the processors are fast. We've just crossed a threshold where each host computes fast enough that host queues and the result table have become large enough to cause this problem. To solve it, we've put per host limits on results in process back in place. But hosts that are having this problem will probably continue to have it until the average number of results per host has fallen to a workable level. That could take weeks.

For a more permanent fix, we plan do more work in each result by quadrupling the size of the workunits. But that fix will probably take months to implement and test.

Thanks!

I do remember seeing that news post, but I didn't associate it with this problem. Looks like we have to wait for the permanent fix.

Regards,
J



____________