Question for you WCGers

R

relic

[H]ard|DCer of the Month - August 2007
Joined
Mar 30, 2001
Messages
9,318
Both of my 32-bit systems run the BOINC client fine along with the F@H GPU client.
Both of my 64-bit systems (1 NVidia and 1 Intel chipset) lock up running BOINC requiring a reboot before they will respond. All are Vista.

Anyone been able to resolve this issue with x64 + BOINC? No one on the WCG forum seems to have a clue and the latest BOINC client doesn't help. :(

I'm trying to help out the WCG team since I'm not willing to baby sit the chronic EUEs on the F@H SMP client thus I have idle Quads, but it needs to be stable before I can run it on my work systems.
 
I'm hoping the rest of the WCGers will weigh in here with some info on what OS they're running (Vista x86 or x64 and if not XP x86 or x64) along with what BOINC or WCG client version they're running.

It's a shame to waste good cores not crunching, but I can absolutely see your point about not compromising work/critical machines. It's one thing to experiment with dedicated crunchers but quite another to risk an important machine.

Couple of questions for you as I think this could end up being an issue of conflict with the Boinc client/service trying to get up and running and conflicting with another service (maybe Defender or some such).

1. How long after the system starts does it hang? I'm guessing within the first 3-6 minutes after startup

2. Did you uninstall the client upon reboot (I'll assume a safe mode reboot if so) or just disable the service?

3. Is a GPU client actively running on either or both machines when trying to startup?

4. Is there any event logs on either system that would point to whether the Boinc.exe (the actual service) or one of the WU/science files were the cause of the hang?

5. Were you ever able to get into Boinc manager before it hung? Or did it hang either while trying to start Boinc Manager or while Boinc Manager was up?

I've got a couple of suspicions and maybe a work around but it's tough as I'm running all XP x86 machines so my limited knowledge may not help.

One of the things I did on both my quad installs (both of which are running GPU clients as well) was create an ascii xml config file to override default Boinc settings and provide a delay for startup to give ALL other system services and commonly running programs time to get started and running. It's called "cc_config.xml" , resides in the "data folder" which in my case is "C:\Documents and Settings\All Users\Application Data\BOINC" and looks like this:
Code: 
<cc_config>
<options>
	<start_delay>300</start_delay>
</options>
</cc_config>

That's a five minute delay and probably is a bit extreme, but I haven't had any issues with it and it gives plenty of time for my system to get fully up and running before firing off the Boinc service.

Just some random thought here, but will be interested for some of the other WGCers to weigh in.
 
all my machines are xp 32bit or server 2003 32bit :(
 
Ran it on my main machine overnight for about 8 1/2 hours with no problems whatsoever. No lockups or anything like that and it chewed through a good number of work units. This is with the WCG BOINC client version 5.10.45. I did not install it as a service since I'm not running all the time on this machine and the screensaver was disabled because I hate screensavers and just let the monitor power down.

It's the rig in the sig running Vista64 SP1. It is a recent install as I reinstalled over the weekend. About the only difference from the normal Vista install is that I have Windows Defender disabled. Otherwise, pretty much everything else has been left alone for the time being.

I do not use the default install location for the client as I prefer to keep all my clients for any DC project in a different place so I don't have to redownload or reinstall them so I don't have any type of permissions problem.

That's about all the relevant info I can think of at the moment.

 
Nomad8u,

They will lock up randomly, sometimes just a few minutes after boot, sometimes they'll run a couple of hours.

I can get into the manager if the system doesn't hang right away and everything appears to be running normally. No indication of problems and the manager works fine.

When the systems do freeze it happens mid keystroke with no warning...no blue screen or crash, just freezes in that spot. The logs don't show anything prior to the subsequent startup Everest Ultimate freezes when the screen does so I can see that the temps, CPU load, RAM available and voltages are all fine.

It was suggested that I try one project at a time to see if one is causing the issue, but I can't play with these systems for extended periods, people need to work. Is one project more stable than the others?

As these are business systems I can't disable AV or play much, but the same software is also running on the two 32-bit systems without issue.

All have 8800GTs and are running the Cuda drivers and all run f@h GPU2 but that's the only similarity other than all being quads. Chipsets and other hardware are different.

One 32-bit system is identical hardware (but only 4GB RAM vs 8GB) to one of the 64-bit systems. The 32-bit runs fine, the 64-bit locks up.

Any ideas are welcome, but I can't just "play around" people lose work when they freeze.

Thanks,
relic
 
I run the Help Conquer Cancer and Human Proteome Folding 2 projects on all my machines with no trouble.

Also, what AV are those machines running? It wouldn't be the first time we've seen conflicts between AV software and DC projects. I'm running Avira AntiVir on my machine as I got sick of the horrible interface and a few problems with AVG 8 and neither one has ever caused me problems. If the problem turns out to be with the AV software and not fixable, at least we'll know what the problem is. Maybe you could try adding the directory the client is installed on to the exceptions list for the AV software.

Another thought I had. Is the indexing service turned on? I'm not sure if that has caused problems with DC projects before but it could be a possibility. The only drive set to be indexed on my system is the OS partition and none of my clients on any of my machines are installed on the OS partition. I believe Vista may do defragging in the background as well although I don't remember for sure. Back when running XP and the old console folding clients, the folding clients would EUE if they were running while a defrag was going on. It seems the clients hated to be defragged while running. I haven't disabled anything like that with this Vista install and my clients seem to be just fine, though.

I think I've about run out of ideas for the moment. This problem is going to annoy me until something is figured out, though.

 
Man, I sure wish I had some "pearls" of wisdom to solve your problems Mr relic :(

ATM I have two (2) Q6600's doing the WCG CPU client without any problems. One Q6600 is OC'ed to 3.0 Ghz (9x333) and the other is OC'ed to just 2.8 Ghz (freaking board I think, in another board the CPU ran fine at 9x333, same MEM, everything) They both have the GPU2 client on core #3 (it's been the default core for me, 8800gs, 8800gt) I have the FahCore11.exe set to "BelowNormal" priority. On the WCG client I set the boinc.exe, BoincMgr.exe and all three of the WCG .exe's to priority "low" (which is default for me) and I set the affinities (through "task manager") to lock on cores #'s 0,1, 2 (for me they default to cores #0, #1, #2, #3.) :)

The reason I say I can't be of any help is both Q6600 boxen use the WinXP w/SP3 OS (32 bit). Perhaps using the delay script that nomad8u suggested may help. I know in the rare times I stop and start the WCG program and the GPU2 client (lately it's been more frequent because I like to watch the Wall Street Bailout (err..., I mean rescue bill) on the floors of the US House of Representatives and the US Senate. I watch the US House of Representatives on the New York Times Web page or the Chicago Times Web page and the Senate on the Washington Post Web page) When doing the before mentioned I always start the GPU2 client first, watch it through the "command prompt" until it does one or two steps and then fire up the WCG client. :D

Please keep us posted if you get any advice as to what cures your problems :p. I've been seriously considering going to a Vista 64 bit OS, but now I don't know. I'm certainly not going back to the WinSMP client, which IMO is super duper crapola. ;)

Oh yeah, don't anybody loose any head hair or get "jock itch" because this post is too freakin' long. :rolleyes:

Foldin' and WCGn' for the CURE

 
Some additional info on the two freezing systems:

Install directory was C:\boinc and c:\boincdata on one and d:\boinc and d:\boincdata on the other

AV is AVG 8 on one and Symantec Client Security (enterprise) on the other.

Both are domain member PCs with the logged user set to be a local administrator on the PC.

Both are Vista x64 SP1 with all critical updates and all drivers up to date.

One is an Intel Chipset the other NVidia

Both 8800GTs with latest CUDA drivers.

Projects are Help Fight Aids, Proteome folding and Conquer Cancer.

All the 32-bit and 64-bit systems are configured identically with no windows firewall and UAC disabled. All are also setup identically for Boinc.

Just in case any of this makes sense to anyone.
 
I removed all of the projects except Fight Cancer.
Found a new CUDA driver (177.84) had been released so I installed it.
Using the 6.2.19 x64 version of BOINC.
Set the client to run at 80%

So far this setup doesn't lock up, instead it has brief periods of very choppy glacial slowness where the system appears to hang for a second or two then recover. Nothing in the system logs to indicate a problem. Still not acceptable but an improvement.

C'mon you WCG gurus...I'm giving this my best attempt....gimme something. :)
 
Any indications of memory leaks on the 64bit OS's?

Our company (unrelated to these topics) has that problem where the (main) developer is on i386 and "forgets" about the extended memory of x64. I quick kick in the pants and he 'remembers' to clean up his memory handling.
 
oraldlight said:
Any indications of memory leaks on the 64bit OS's?

Our company (unrelated to these topics) has that problem where the (main) developer is on i386 and "forgets" about the extended memory of x64. I quick kick in the pants and he 'remembers' to clean up his memory handling.
Click to expand...

Hadn't thought of that. I believe the free memory reported by Everest was over 5GB, but that may not report fragmented, non-sequential RAM correctly.

hmmm.
 
We see our problem with the commit charge slowly increasing until it surpasses the physical ram amount. From that point north, our product gets a little unstable and unpredictable in how it will crash.
 
After a bit of thought I don't think a memory leak could be an issue, due to the fact it will freeze in 2-3 minutes sometimes.

So far it's been fairly stable with the last changes. I'll see how it goes overnight.
 
You must log in or register to reply here.
Back
Top