I've been logging the output from the Linux CLI BOINC client to text files to get a clear view of what 's going on. To simplify matters, I adjusted the resource sharing between SETI and CPDN to 50/50 (actually 100/100)....and updated the preferences on all systems.

Linux client: 4.05

SETI still seems to get most of the time...and I see why.

When I first start the client, SETI may begin and run for one hour - if a WU does not finish.

If SETI finishes a WU within the hour it is alotted for processing, it will start anotehr WU....and go for one hour before being pre-empted.

The CPDN model then processes for exactly one hour.

The SETI WU will resume, and EVER AFTER will process for TWO hours for each ONE CPDN processes.

Bear in mind that if the SETI WU completes within that TWO hours, it will reset the clock form that point for TWO hours.

Which explains why CPDN has been making snail-like progress despite the projects being set at 50/50 and the -update_prefs have been reset.

Summary: Ratio set 50/50 (100 / 100)

1. The 50 / 50 will be maintained for at least the first cycle of pre-emption (subject to a SETI WU completing and resetting the clock in it's time).

2. All subsequent cycles will 2:1 in favour of SETI (subject to a SETI WU completing and resetting the the clock on its time.)

Nice detective work. I haven't been monitoring as closely but I have noticed that my laptop (windows XP) seems to be doing the same thing (running seti@home with LHC@home). And it frequently resets the progress of the seti@home work unit when it tries to resume it. Or it will just stop processing all together with message: "SETI@home - 2004-09-08 21:09:31 - resume_or_start(): unexpected process state 8" until I restart BOINC. Have you seen that on linux? There are obviously some bugs to work out in the timeslicing code :)



-------------------------------------------
- A member of The Knights Who Say NI!
Possibly the best stats site in the universe:
http://boinc-kwsn.no-ip.info

> Nice detective work. I haven't been monitoring as closely but I have noticed
> that my laptop (windows XP) seems to be doing the same thing (running
> seti@home with LHC@home). And it frequently resets the progress of the
> seti@home work unit when it tries to resume it. Or it will just stop
> processing all together with message: "SETI@home - 2004-09-08 21:09:31 -
> resume_or_start(): unexpected process state 8" until I restart BOINC. Have
> you seen that on linux? There are obviously some bugs to work out in the
> timeslicing code :)
>



I haven't seen that error on Linux.

The Linux client (4.05) has been rock solid as a far as stability goes.

I have had it wipe out all projects when I started the same executable in the same directory with a DIFFERENT userid.

That was annoying.

What I and a couple of others seem to have seen in 4.05 is that each WU was counted for resource share rather than the project. This has apparently been fixed in 4.08. So if you had the resource shares set to 1:1 S@H / CPDN, and you had 2 S@H WUs on your computer, S@H would get a share of 2 for CPDNs 1.

Noticing the exact same behavior with WinXP. Wondering if 2:1 CPDN/SETI resource ratio offsets the discrepancy?

> Noticing the exact same behavior with WinXP. Wondering if 2:1 CPDN/SETI
> resource ratio offsets the discrepancy?

Tried it last night and it appears to make no difference at all.

Of the instances observed since I set favour to CPDN as 2:1 over SETI, it has worked thus:

1. If a resumed SETI WU completes any time within TWO hours (assumed because of behaviour observed in 2, below), the clock is reset and the new WU will run for ONE additional hour. So a split-WU incident may run anywhere from 61 minutes to 2:59 minutes. This is indicated, but not confirmed. Sample seen was 38 minutes on a resumed WU, followed by one hour on a new WU - then pre-empted.

2. If a WU does NOT end within 2 hours, then SETI is pre-empted at 2 hours and CPDN will then run for ONE hour - despite having sharing set to double the amount of SETI. This is confirmed.

Conclusion based on Observed Behaviour in past 12 hours:

What you set the resource sharing value to makes no difference whatever. The work will proceed as above.

System: AMD Athlon XP 2800+, Xandros Linux 2.0 (Debian-based), BOINC v4.05, typical SETI WU completion time is 2:50

In any case, the problem appears to have been fixed in 4.08.