I needed a notebook on short notice... And all that I could find had MS Vista.

Got one with a dual core Intel and Vista Home Premimum.

Installed Boinc (5.8.15)..

If I don't touch the notebook, all runs fine (I'm using a std install of boinc - with boincmgr). Projects are Einstein and CPDN..

If I do something as simple as a "restart".. most of the time the WU's in progress get trashed.. Sometimes everything in the queue!

It's like the proper WM_ messages arent send by the OS or not seen by boinc/einstein/CPDN apps, or boinc's not given the proper time to shut down cleanly...

Sorry if I didn't find this issue in the forum, but please point me to a link to the topic...

To be honest, Vista has a bunch of other problems - like it tells me I have no network when I do, and I'm spending my time sorting that out... But figured I should be able to crunch in the mean time!

Thank you all in advance, and once again.. sorry if I didn't read thru the whole forum, as I'm on a time crunch right now....

Try here.


You'll probably want to manually shut down BOINC. I've read that Vista shuts down really fast. You're right, it doesn't give BOINC enough time to shut down.

---

Kathryn :o)

Try here.


You'll probably want to manually shut down BOINC. I've read that Vista shuts down really fast. You're right, it doesn't give BOINC enough time to shut down.

Short time work-around, but I'm wondering how this will be resolved.

Does Boinc need to shutdown faster, or does Vista need to wait longer when told to do so by an app? "I'm still shutting down - try again in a bit"

There will be folks like me that were (yes I will say it) FORCED to Vista.. All new boxes from the big names seem to be running Vista, and this problem probably will get worse. I've had more WU's error out in the last 3 days than I've had since I started running Boinc..

Does Boinc need to shutdown faster, or does Vista need to wait longer when told to do so by an app? "I'm still shutting down - try again in a bit"

It's hard to speed up thing on BOINC or rather project app side. Imagine some large project run, such as Seasonal Attribution with its 100+ MB RAM usage to quickly flush its internal state to checkpoint file ... depending on RAM size it might be a no-go. If application gets interrupted while it is savin its state, the checkpoint file gets corrupted. When next started it's either start from beginning or assume that it crashed due to some other reasons (like bugs in code or parameter instability) and report as crashed.

It really is up to OS to allow enough time for applications to end. Or, if app doesn't end, it really should show some pop-up message asking user to proceed or not - just like XP does. Seems to me that Microsoft got to the other extreme regarding this issue. It was known that Windows 2000 was extremely slow shutting down as it gave more than enough time to all applications to cleanly stop.

---

Metod ...

If Boinc were to make two changes:

* treat Windows-kill messages as being the same as exit-code-zero-without-stop-file (i.e., ignore the stop file!)
* Don't force a checkpoint on receiving a shutdown message

That would save a lot of problems (although probably not all).


SAP (and the other climate projects) don't attempt to checkpoint on shutdown, since they can only do so at one point in their daily cycle. SAP does however get up to 450MB RAM and it takes a while to cleanly shut down even without the checkpoint overhead. If windows sends them a kill message it's invariably fatal to the model.

---

Copy the following text and paste it into the Notepad window, called WaitToKill.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"WaitToKillServiceTimeout"="20000"

The 20000 is 20 seconds. Increase/decrease to your liking.
To add this to the registry double-click the file. The UAC will come up, press continue, press Yes on the next window and OK on the one there-after. You need to reboot to make the changes have effect.

---

Copy the following text and paste it into the Notepad window, called WaitToKill.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl]
"WaitToKillServiceTimeout"="20000"

The 20000 is 20 seconds. Increase/decrease to your liking.
To add this to the registry double-click the file. The UAC will come up, press continue, press Yes on the next window and OK on the one there-after. You need to reboot to make the changes have effect.

Tried this using 40000 (40 sec) and after a few reboots, it seems to be working!

Thanks for the info!

BOINC 5.8.16 had some Benchmarking issues on Vista. It is less than 1/2. The Core 2 Duo T7200 (2.0G 4M L2) chip used to have a 3.9GFlOPs per core now has a 1.53GFlOPs per core. XP is fine, but Vista is not. The FPU speed is OK. The E6400 (2.13G 2M L2) is 4.07GlOPs per core.

Just wanted to bring this to someone's attention.

---

BOINC 5.8.16 had some Benchmarking issues on Vista. It is less than 1/2. The Core 2 Duo T7200 (2.0G 4M L2) chip used to have a 3.9GFlOPs per core now has a 1.53GFlOPs per core. XP is fine, but Vista is not. The FPU speed is OK. The E6400 (2.13G 2M L2) is 4.07GlOPs per core.

Just wanted to bring this to someone's attention.

Did they try rerunning benchmarks a bunch of times? There's a bug somewhere where dual cores will drop one of the benchmarks by about half seemingly randomly.

On a Pentium D, I ran them maybe 6 or 7 times before I got an accurate one on more than one occasion.

---

Kathryn :o)

BOINC 5.8.16 had some Benchmarking issues on Vista. It is less than 1/2. The Core 2 Duo T7200 (2.0G 4M L2) chip used to have a 3.9GFlOPs per core now has a 1.53GFlOPs per core. XP is fine, but Vista is not. The FPU speed is OK. The E6400 (2.13G 2M L2) is 4.07GlOPs per core.

Just wanted to bring this to someone's attention.

Did they try rerunning benchmarks a bunch of times? There's a bug somewhere where dual cores will drop one of the benchmarks by about half seemingly randomly.

On a Pentium D, I ran them maybe 6 or 7 times before I got an accurate one on more than one occasion.

Trouble is BOINC runs the benchmarks every 5 days so 5 days later your benchmarks might be out to lunch again. There is no need to let BOINC mess up your benchmarks. First, set the benchmarks yourself then tell BOINC not to mess around with your settings. The steps are:

1. Set all projects to "no new tasks".

2. Drain your WU cache of all WUs except for 1 WU for each project you crunch. To do that, suspend 1 WU from each project and allow the rest to crunch, upload and report.

3. Shutdown BOINC and backup your client_state.xml file.

4. Open client_state.xml file in Notepad. Use Notepad or some other plain text editor, not Wordpad or Word because those editors try to put text formating commands into the file you are editing and you definitely don't want that in your client_state.xml.

5. About 10 lines from the top find lines that start with:

• <p_fpops> - this is the floating point benchmark
  
• <p_iops> - this is the integer benchmark
  
• <p_calculated> - this tells BOINC when to re-calculate the benchmarks
  

6. Alter the numbers following <p_fpops> and <p_iops> to whatever they should be.

7. Alter the number following <p_calculated>. Initially, it will be something like 1171776064.343750 which tells BOINC to re-calculate the benchmarks every 5 days. Increase the 3rd digit from the left by 1 to tell BOINC to re-calculate something like every 30 years. OK, it's not exactly 30 years but it's a very long time and your benchmarks will stay the way you set them until that time. Thus 1171776064.343750 would become 1181776064.343750.

8. Check your typing carefully. When you're satisfied, save the file and exit Notepad.

9. Let the remaining WUs in your cache crunch before you allow more new WUs to download or else BOINC will download too many. Actually, if you blow this part it's not a big deal, you can just abort whatever you know you can't finish in time.

It is rumored that in previous versions of BOINC each number you edit must be followed by 6 decimal digits. I don't know if those rumors are true but play it safe and make sure there are exactly 6 digits to the right of the decimal points in the 3 numbers you edit.

Post your thank you notes using a sockpuppet unless you want some BOINC Kop like Sekerob following you around from projecty to project accusing you of being a credit cheater.

Whether the previous instructions are appropriate, the owner/mods of this forum can decide,...

Apparently the appropriatness of said thread and appropriatness of BOINC Kopping have been considered and a decision has been rendered.

Copy the following text and paste it into the Notepad window, called WaitToKill.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl]
"WaitToKillServiceTimeout"="20000"

The 20000 is 20 seconds. Increase/decrease to your liking.
To add this to the registry double-click the file. The UAC will come up, press continue, press Yes on the next window and OK on the one there-after. You need to reboot to make the changes have effect.

Tried this using 40000 (40 sec) and after a few reboots, it seems to be working!

Thanks for the info!

As an update, I bumped the value to 60000 (60 secs) as CPDN was having problems...

Why oh why can't Vista just wait for the "I'm really done" response from apps.... (or prompt with the "wait or kill" dialog if it takes too long..)

I guess it's because Vista needs to "phone home" to MS as often as possible for updates..... :(

This reminds me of DOS 4.0...

Well, not really comparable to the shutdown problem here, but a nice report on how Vista features can evolve: Windows shutdown crapfest ;)

---