Minimum system requirements

> Does E@H have any minimumm system requirements specified somewhere?

No, not really. There are people successfully using slow cpus but to do this you need to ensure that the work hasn't become "stale" before it starts.

> I have an older laptop with a 400 Mhz Celeron. It is running SETI and E@H with
> resources split evenly. The system has no problme crunching SETI WU's, but it
> downloads only 1 Einstein WU at a time and that WU never completes in the 1
> week deadline.

This is probably because that single E@H work unit has been sitting on your machine for a couple of days whilst a previous work unit has been completing. By the time it gets to start, the bulk of the deadline has already been used up. Under those conditions it will never have a chance of completing within the deadline.

> Is this unit just flat too underpowered to work the Einstein project, or is
> there something I might be doing wrong?

No, it is possible for that machine to complete work within the deadline but you will need to make some changes to your general preferences. Before I suggest the change, might I comment that another option might be to devote that machine entirely to Seti by detaching E@H from it and to make up for that by just slightly increasing your resource share for your other, faster machines, say to a 51/49 split for example rather than 50/50. That would be one option that would work for that older machine.

However, even your faster machines are having problems. Take your single cpu P4 3.0G for example. At the time of writing this, there are 4 work units on hand and two of those will expire on April 18. You are going to be lucky for the second one to complete before the deadline. In fact, your last completed work unit exceeded the deadline by 18 hours but was granted credit simply because another machine was even later than yours.

I believe that your best option in preventing this problem is simply to keep less work on hand by lowering your "connect to network" interval under your general preferences. My guess is that you have it set around 1 to 2 days. It's a very long story which you can find by using the search function on these message boards but in a nutshell, there is always a tendency for too much work to be downloaded for E@H in a multi-project environment. You should simply experiment with lowering that number until you find a "sweet spot" that works for your configuration.

The default value is 0.1 days for a very good reason. You should set your value back to something like that until your excessive cache clears. Whenever you make a change, do an "update" to force the new value to be recognised immediately. The new value will apply to all projects, so all caches will reduce. Over a couple of days, once the caches have reduced, start increasing the value slowly until you find one that will still allow your E@H work to complete in time and give you enough work for Seti so that an outage there doesn't immediately run you out of work. My guess is that you will find that something like 0.3 to 0.5 days may be a reasonable compromise.

> Oh, and I am seeing the ATI problem as well. Two machines, an ATI 9600 XT and
> an orginal ATI all-in-WONDER both with latest drivers. SETI screensaver works
> fine. Einstein is blank.
>

> As per my original post that computer, after it's attachment to E@H,
> downloaded a total of 1 workunit and began it's processing immediately. It did
> not sit "stale" for any period of time.

The computer I've looked at has an ID of 104746 and indeed has one only work unit currently in its queue. I presume this is the computer we are talking about as it's the only one with just one WU?

If this is the only work downloaded by that machine, how come it has a granted credit of 108.11 and an RAC of 19.13??? Presumably the machine has been able to complete work at some stage in the past? Presumably you would have actual figures of exactly how long it took to complete that work. Why did you say in your original message that this machine "...downloads only 1 Einstein WU at a time and that WU never completes..."???

Under normal circumstances, as you have four machines three of which have multi WU queues, it is hard to understand how your 4th machine is able to only ever have one work unit at a time. Everybody else always gets extra work and this is why so many are complaining about the deadline being too short. If you have a magic formula that allows you to limit that box so that you never have "stale" work then you should share it as everybody who wants to have sufficient Seti work without getting extra E@H units would be most grateful for the information.

> ... it does not appear that this computer
> would be able to complete a single workunit by the imposed deadline even if
> were dedicated 100% to E@H and running 24/7. If it did, it would be by a very
> narrow margin.

You must have really screwed up the configuration of your machine then or it must be an absolute dog. If you search through these boards you will find statements like the following:-

> My oldest and slowest machine is a 166 MHz box; it is running ALL projects
> except CPDN. Even this machine finishes WU's before the deadline is over !

or perhaps this one

> My 200 MHz machine which returned WU's within 70 hours (it was doing E@H 100%)
> hasn't gotten a WU in quite a while now.... :-(

You will find both of those within 1 minute if you do a keyword search for a thread title containing the search string "deadline 1 week". They are both in the very first hit. Also in the very first hit is a message or two from Prof Bruce Allen, the CEO of this project giving his thoughts about the one week deadline. You will even find the reason why the 200mHz machine which could do a work unit in less than 3 days was prevented from getting more work. It actually makes very interesting reading. Go and read all about it.

> I do not beleive this is true. It does not appear that this machine can
> complete a single workunit in the time alloted even if completely dedicated to
> E@H. I am going to detach that machine from the project once the queue is
> drained and use it for other BOINC projects that are less demanding.

Believe what you wish. I have a 466mHz celeron desktop. It does E@H work units in about 45-50 hours. Admittedly it is a desktop and probably would be faster than equivalent speed laptops. However your 400mHz laptop should be able to do a work unit in around 55-60 hours or so. If it can't do it within 168 hours (1 week deadline) then there is something seriously wrong with the way you have configured things.

> I used this process in the past to determine the current cache size the
> systems could handle without WU's expiring. I simply need to adjust the one
> machine that is not running as often as before.

The general preferences you set up apply to all machines unless you group them separately. You can't adjust one machine on its own unless you put it in a separate group. The three available groups are "home", "work" and "school". Once you start having different requirements for different machines you will quickly start running out of available groups.

> I have found that with a small cache size (like .1 to .5), combined with the
> fact that the BOINC projects either run out of work or go down quite often, my
> computers frequently ran out of WU's in the past.

Supporting multiple projects is a pretty good caching system itself. In the last two months, supporting just Seti and E@H, you would never have been out of work with a "connect" setting of 0.5 days. I know I haven't been with an interval of just 0.2 days which I find absoultely fine for my requirements.

> Since I have no problems with other BOINC projects, I have to wonder if the 7
> day limit for WU on E@H or perhaps the overall size of the WU is too
> restrictive. It may not be practical to reduce the sizes or increase the time
> limit, but if it can be done it would make participation by slower systems
> more feasible.

People don't seem to understand that the developers have a perfect right to set whatever limits they see fit. This subject comes up continuously and the developers have stated their reasons in the past. Personally, as I've stated in previous messages, I think the limits are too short as well. However, that same message has been given to the developers many, many times already and it is now becoming quite tedious. The developers are fully aware of public sentiment and have chosen to stay with 1 week. It's time to either accept that and live with it, or move elsewhere.

Before anyone posts another winge about short deadlines please go and read the huge volumes that have already been written about it and realise that it has all been said before, many, many times over. Then decide to save your fingers.

If you do actually go and look up what has been previously posted on the subject, you will find the complete story, including reasons and including strategies for coping with it.

> It would appear that my post has somehow offended or annoyed you. I apologise
> for this, as it was not my intention.
>
>
> I had, what I thought, was a simple question and made the assumption this
> message board was the appropriate place to ask the question.
>
> It would appear that there does seem to be a problem with this particular
> computer in question and I welcome any constuctive suggestions as to what the
> porblme may be.
>
> Certainly, the owners of this project can set the parameters of the project
> however they wish. I did not mean to imply otherwise.
>
Look in task manager and see what processes are taking CPU time (If you click on CPU at the top of the window, it will sort by CPU usage). If there is some process taking large amounts of CPU time that you are not expecting, you should ask why that task is taking so much time. Give us a list of the processes that take the most time, and we will try to help.