Thanks for correcting the directory. I checked current situation on another computer. I have one small stderr.old file in c:\users\\appdata\local\virtualstore\programdata\boinc\slots\1 but it is not copied to c:\programdata\boinc\slots\1. It would probably not cause any problems even if it was more than 20MB large. But I still think, that all boinc files should be stored in c:\programdata\boinc and no file should be stored in the ...virtualstore\programdata\boinc directory. This usualy means, that program did not have access to boinc directory when it was writing the file.
Unfortunatelly for you, I cannot give you any other advice than to delete large files from the ...virtualstore\programdata\boinc\slots directory. This was mine problem and it was solved by deleting those files. Your problem may be different or more complicated. You can also check directory c:\programdata\boinc\slots directly. But be careful in this directory, boinc need it to work properly. It is also hard to say what files should be here and what should not be here. It depends on application currently running in the slot and I am no expert in this ... My only observation is, that slot directory is usualy small (most files here are links with only few bytes of data). But there are exceptions, for example slot directory with einstein cuda task takes about 20 MB and it seems to be correct size for this application.
To playing computer games while running boinc: I run 4 CPU tasks and one cuda task on quad core and I have mostly no problems. There are no frequent einstein application crashes while playing games. Only few games need to stop boinc computation to run smoothly. It is also unprobable that playing computer game would create large file in place where boinc checks disk usage of an application, the crash message would be probably different.
When I installed I let BOINC install to default directories. The program has been running fine ever since the install in this Win7 machine, so I can't explain why any permissions might have changed. As far as I know, they haven't, but I could be wrong. I frequently am at this age.
Five more WU's failed last night.
I don't really know what to do about it. Everything I've tried hasn't fixed the problem. It bothers me that something is wrong even though the work will eventually get done. I just hate the inefficiency of letting my machine run 24/7 and having failed WU's. Seems like a waste of electricity when that happens.
I'll just keep plugging away and if someone comes up with a solution, then great! If not, I'm not losing a huge amount of time, but I may investigate crunching for some other project. I do crunch for Collatz, but that is gpu only. Einstein is cpu only. Maybe it's time to get back into SETI, although when I left them, their servers were down more than up, so we'll see about that.
Thanks for your comments. I wish a resolution could be found.
I've just re-read all of this thread and the previous one you started. There should be an easy solution.
I have a large number of hosts on this project. The majority of them have a single model of 20GB drive dating back around a decade although I acquired them around 5 years ago. The standard configuration on each drive is to have both Windows XP and Linux. Years ago a lot of them ran Windows but all were set up as dual booting and the large majority now run Linux. Each drive has 5 partitions - Win C:, Win D:, Linux root (/), Linux swap and Linux /home. The approx sizes of those partitions are 4GB, 4GB, 6GB, 1.5GB and 3.5GB respectively. I tend to use things until they die :-). I expected these disks to die a long time ago but they don't seem to want to.
These hosts crunch mostly without problems - I just don't see any errors due to lack of disk space. I probably will in the future because the large data files associated with the GW project are tending to accumulate so when I do have the occasional look, I am seeing decreasing free space on the 3.5GB /home where BOINC resides. When I need to, I will manually remove (edit) the entries in the state file for those data frequencies which are no longer current and then delete the actual files on disk. You can't just delete the files on disk because the scheduler will see them as 'missing' and simply send them back to you.
I'm not suggesting that you need to edit your state file - far from it. I'm just trying to point out that it's possible to run this project on very minimal disk resources. It would be easier not to have so many partitions but I do like to be able to completely reinstall the OS without disturbing the user data. With Linux, I have on many occasions stopped BOINC, rebooted a live CD of a later version of the OS, formatted and reinstalled the root partition and then restarted BOINC with a very minimal down time.
So what about your problem. I suspect there are quite a number of factors that you need to consider to resolve the problem. I can see you are using the latest BOINC version. All my small disk Linux hosts are using quite an old version and there may be significant differences with newer versions. I have no information about recent versions so I'm not sure whether this might be an issue or not.
You mentioned you have at least a 1TB drive (I think). What's probably more important is the size of the partition on which BOINC resides. I believe (and I could be wrong) that the various preferences all relate to the BOINC partition only and not the size of the drive.
You listed your preferences as
Quote:
-Use at most xxx GB of space - (swap space). 20 gb
-Leave at least xxx GB of space free 100 gb
-Use at most xx % of disk space (!!!) 50%
-Use at most xx % of page file 100%
Gundolf replied, making this observation
Quote:
Does the client still give a line like this in the startup messages: 08-Jun-2012 02:08:46 [---] Preferences limit disk usage to 1.86GB
Quote:
-Leave at least xxx GB of space free 100 gb
-Use at most xx % of disk space (!!!) 50%
Why do you keep so much from BOINC? I'd try (at least temporarily) values of 1 GB and 99% respectively.
Your response indicated that you weren't sure what Gundolf was driving at so let me explain.
Firstly, looking at your startup messages is very useful in seeing what BOINC thinks it is actually limited to. You should take a look and tell us what the figure is.
Secondly, by insisting on 100GB being kept free and by preventing the usage of the partition on which BOINC resides to NOT grow above 50%, you are "keeping so much from BOINC". As an example, if your disk was a single partition and you had stored 500GB of movies, TV shows, whatever, BOINC would not be allowed to store a single extra byte - although you still had 500GB free space!
The 'safe' action is to set those particular prefs to exactly what Gundolf suggested - 1GB and 99% - so that you don't get caught out if your non-BOINC uses of your disk grow enormously. The best way to ensure BOINC use doesn't get out of control is to rely on the first listed pref (which isn't swap space as you called it). When I look at computing preferences on the website, it's listed as "Disk: Use at most xx GB". 20GB ought to be plenty there. The 4th pref controls use of swap space.
I don't know if the problem you are having is some oddity in the version of BOINC you are using. Hopefully it wont be. Just make the two pref changes Gundolf suggested and see what happens. At the moment you don't seem to have any new FGRP tasks so you'll have to wait until you get some more. Perhaps you have disabled that particular sub-project?
Also, tell us the size and free space of all partitions on your disk.
I'm assuming that there are two partitions. One is called F: and is System Reserved. It is 100mb in size and 28.2MB are used. The capacity of C: is 1.36TB with 209GB used and 1.15TB free.
Here is what my Event Log from BOINC Mgr says:
7/27/2012 1:02:20 AM | | Starting BOINC client version 7.0.28 for windows_x86_64
7/27/2012 1:02:20 AM | | log flags: file_xfer, sched_ops, task
7/27/2012 1:02:20 AM | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6
7/27/2012 1:02:20 AM | | Data directory: C:\ProgramData\BOINC
7/27/2012 1:02:20 AM | | Running under account mdawson
7/27/2012 1:02:20 AM | | Processor: 8 GenuineIntel Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz [Family 6 Model 26 Stepping 5]
7/27/2012 1:02:20 AM | | Processor: 256.00 KB cache
7/27/2012 1:02:20 AM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 syscall nx lm vmx tm2 popcnt pbe
7/27/2012 1:02:20 AM | | OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, (06.01.7601.00)
7/27/2012 1:02:20 AM | | Memory: 12.00 GB physical, 24.00 GB virtual 7/27/2012 1:02:20 AM | | Disk: 1.36 TB total, 1.16 TB free
7/27/2012 1:02:20 AM | | Local time is UTC -7 hours
7/27/2012 1:02:20 AM | | NVIDIA GPU 0: GeForce GTX 680 (driver version 301.42, CUDA version 4.20, compute capability 3.0, 2048MB, 1756MB available, 2167 GFLOPS peak)
7/27/2012 1:02:20 AM | | OpenCL: NVIDIA GPU 0: GeForce GTX 680 (driver version 301.42, device version OpenCL 1.1 CUDA, 2048MB, 1756MB available)
7/27/2012 1:02:20 AM | | Config: use all coprocessors
7/27/2012 1:02:20 AM | | Config: don't compute while launcher.exe is running
7/27/2012 1:02:20 AM | | Config: don't compute while swtor.exe is running
7/27/2012 1:02:20 AM | Collatz Conjecture | URL http://boinc.thesonntags.com/collatz/; Computer ID 49610; resource share 100
7/27/2012 1:02:20 AM | Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 2221041; resource share 100
7/27/2012 1:02:20 AM | Einstein@Home | General prefs: from Einstein@Home (last modified 22-Jul-2012 05:21:31)
7/27/2012 1:02:20 AM | Einstein@Home | Computer location: home
7/27/2012 1:02:20 AM | Einstein@Home | General prefs: no separate prefs for home; using your defaults
7/27/2012 1:02:20 AM | | Reading preferences override file
7/27/2012 1:02:20 AM | | Preferences:
7/27/2012 1:02:20 AM | | max memory usage when active: 9214.82MB
7/27/2012 1:02:20 AM | | max memory usage when idle: 9214.82MB 7/27/2012 1:02:20 AM | | max disk usage: 20.00GB
7/27/2012 1:02:20 AM | | max CPUs used: 6
7/27/2012 1:02:20 AM | | (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
7/27/2012 1:02:20 AM | | Not using a proxy
There are only two lines that relate to the hard drive. I've highlighted those lines in red. I'll set the two parameters as you and Gundolf have recommended and then wait and see what happens. I left swap space at 50%. Since I have so much available space, I didn't think the numbers for those parameters would actually matter.
What is interesting to me is that STan told me about errant stderr.old files. I had originally found one at c:\users\mdawson\appdata\local\virtualstore\programdata\boinc\slots\0. At the time I deleted the file. In checking now, I see where there is a newer stderr.old file where you'd expect it to be (c:\program data\BOINC\slots\0 and \slots\4. There are 6 slot directories. The others don't have an stderr.old file. In looking at the directory structure STan talked about, there are only 2 \slot directories created. 0 and 4, but this time neither has an stderr.old file. I can't explain that either.
Hopefully this info will help get to the bottom of this.
mdawson, Thanks for
)
mdawson,
Thanks for correcting the directory. I checked current situation on another computer. I have one small stderr.old file in c:\users\\appdata\local\virtualstore\programdata\boinc\slots\1 but it is not copied to c:\programdata\boinc\slots\1. It would probably not cause any problems even if it was more than 20MB large. But I still think, that all boinc files should be stored in c:\programdata\boinc and no file should be stored in the ...virtualstore\programdata\boinc directory. This usualy means, that program did not have access to boinc directory when it was writing the file.
Unfortunatelly for you, I cannot give you any other advice than to delete large files from the ...virtualstore\programdata\boinc\slots directory. This was mine problem and it was solved by deleting those files. Your problem may be different or more complicated. You can also check directory c:\programdata\boinc\slots directly. But be careful in this directory, boinc need it to work properly. It is also hard to say what files should be here and what should not be here. It depends on application currently running in the slot and I am no expert in this ... My only observation is, that slot directory is usualy small (most files here are links with only few bytes of data). But there are exceptions, for example slot directory with einstein cuda task takes about 20 MB and it seems to be correct size for this application.
To playing computer games while running boinc: I run 4 CPU tasks and one cuda task on quad core and I have mostly no problems. There are no frequent einstein application crashes while playing games. Only few games need to stop boinc computation to run smoothly. It is also unprobable that playing computer game would create large file in place where boinc checks disk usage of an application, the crash message would be probably different.
STan, When I installed I
)
STan,
When I installed I let BOINC install to default directories. The program has been running fine ever since the install in this Win7 machine, so I can't explain why any permissions might have changed. As far as I know, they haven't, but I could be wrong. I frequently am at this age.
Five more WU's failed last night.
I don't really know what to do about it. Everything I've tried hasn't fixed the problem. It bothers me that something is wrong even though the work will eventually get done. I just hate the inefficiency of letting my machine run 24/7 and having failed WU's. Seems like a waste of electricity when that happens.
I'll just keep plugging away and if someone comes up with a solution, then great! If not, I'm not losing a huge amount of time, but I may investigate crunching for some other project. I do crunch for Collatz, but that is gpu only. Einstein is cpu only. Maybe it's time to get back into SETI, although when I left them, their servers were down more than up, so we'll see about that.
Thanks for your comments. I wish a resolution could be found.
RE: ... I wish a resolution
)
I've just re-read all of this thread and the previous one you started. There should be an easy solution.
I have a large number of hosts on this project. The majority of them have a single model of 20GB drive dating back around a decade although I acquired them around 5 years ago. The standard configuration on each drive is to have both Windows XP and Linux. Years ago a lot of them ran Windows but all were set up as dual booting and the large majority now run Linux. Each drive has 5 partitions - Win C:, Win D:, Linux root (/), Linux swap and Linux /home. The approx sizes of those partitions are 4GB, 4GB, 6GB, 1.5GB and 3.5GB respectively. I tend to use things until they die :-). I expected these disks to die a long time ago but they don't seem to want to.
These hosts crunch mostly without problems - I just don't see any errors due to lack of disk space. I probably will in the future because the large data files associated with the GW project are tending to accumulate so when I do have the occasional look, I am seeing decreasing free space on the 3.5GB /home where BOINC resides. When I need to, I will manually remove (edit) the entries in the state file for those data frequencies which are no longer current and then delete the actual files on disk. You can't just delete the files on disk because the scheduler will see them as 'missing' and simply send them back to you.
I'm not suggesting that you need to edit your state file - far from it. I'm just trying to point out that it's possible to run this project on very minimal disk resources. It would be easier not to have so many partitions but I do like to be able to completely reinstall the OS without disturbing the user data. With Linux, I have on many occasions stopped BOINC, rebooted a live CD of a later version of the OS, formatted and reinstalled the root partition and then restarted BOINC with a very minimal down time.
So what about your problem. I suspect there are quite a number of factors that you need to consider to resolve the problem. I can see you are using the latest BOINC version. All my small disk Linux hosts are using quite an old version and there may be significant differences with newer versions. I have no information about recent versions so I'm not sure whether this might be an issue or not.
You mentioned you have at least a 1TB drive (I think). What's probably more important is the size of the partition on which BOINC resides. I believe (and I could be wrong) that the various preferences all relate to the BOINC partition only and not the size of the drive.
You listed your preferences as
Gundolf replied, making this observation
Your response indicated that you weren't sure what Gundolf was driving at so let me explain.
Firstly, looking at your startup messages is very useful in seeing what BOINC thinks it is actually limited to. You should take a look and tell us what the figure is.
Secondly, by insisting on 100GB being kept free and by preventing the usage of the partition on which BOINC resides to NOT grow above 50%, you are "keeping so much from BOINC". As an example, if your disk was a single partition and you had stored 500GB of movies, TV shows, whatever, BOINC would not be allowed to store a single extra byte - although you still had 500GB free space!
The 'safe' action is to set those particular prefs to exactly what Gundolf suggested - 1GB and 99% - so that you don't get caught out if your non-BOINC uses of your disk grow enormously. The best way to ensure BOINC use doesn't get out of control is to rely on the first listed pref (which isn't swap space as you called it). When I look at computing preferences on the website, it's listed as "Disk: Use at most xx GB". 20GB ought to be plenty there. The 4th pref controls use of swap space.
I don't know if the problem you are having is some oddity in the version of BOINC you are using. Hopefully it wont be. Just make the two pref changes Gundolf suggested and see what happens. At the moment you don't seem to have any new FGRP tasks so you'll have to wait until you get some more. Perhaps you have disabled that particular sub-project?
Also, tell us the size and free space of all partitions on your disk.
Cheers,
Gary.
Gary, I'm assuming that
)
Gary,
I'm assuming that there are two partitions. One is called F: and is System Reserved. It is 100mb in size and 28.2MB are used. The capacity of C: is 1.36TB with 209GB used and 1.15TB free.
Here is what my Event Log from BOINC Mgr says:
7/27/2012 1:02:20 AM | | Starting BOINC client version 7.0.28 for windows_x86_64
7/27/2012 1:02:20 AM | | log flags: file_xfer, sched_ops, task
7/27/2012 1:02:20 AM | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6
7/27/2012 1:02:20 AM | | Data directory: C:\ProgramData\BOINC
7/27/2012 1:02:20 AM | | Running under account mdawson
7/27/2012 1:02:20 AM | | Processor: 8 GenuineIntel Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz [Family 6 Model 26 Stepping 5]
7/27/2012 1:02:20 AM | | Processor: 256.00 KB cache
7/27/2012 1:02:20 AM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 syscall nx lm vmx tm2 popcnt pbe
7/27/2012 1:02:20 AM | | OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, (06.01.7601.00)
7/27/2012 1:02:20 AM | | Memory: 12.00 GB physical, 24.00 GB virtual
7/27/2012 1:02:20 AM | | Disk: 1.36 TB total, 1.16 TB free
7/27/2012 1:02:20 AM | | Local time is UTC -7 hours
7/27/2012 1:02:20 AM | | NVIDIA GPU 0: GeForce GTX 680 (driver version 301.42, CUDA version 4.20, compute capability 3.0, 2048MB, 1756MB available, 2167 GFLOPS peak)
7/27/2012 1:02:20 AM | | OpenCL: NVIDIA GPU 0: GeForce GTX 680 (driver version 301.42, device version OpenCL 1.1 CUDA, 2048MB, 1756MB available)
7/27/2012 1:02:20 AM | | Config: use all coprocessors
7/27/2012 1:02:20 AM | | Config: don't compute while launcher.exe is running
7/27/2012 1:02:20 AM | | Config: don't compute while swtor.exe is running
7/27/2012 1:02:20 AM | Collatz Conjecture | URL http://boinc.thesonntags.com/collatz/; Computer ID 49610; resource share 100
7/27/2012 1:02:20 AM | Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 2221041; resource share 100
7/27/2012 1:02:20 AM | Einstein@Home | General prefs: from Einstein@Home (last modified 22-Jul-2012 05:21:31)
7/27/2012 1:02:20 AM | Einstein@Home | Computer location: home
7/27/2012 1:02:20 AM | Einstein@Home | General prefs: no separate prefs for home; using your defaults
7/27/2012 1:02:20 AM | | Reading preferences override file
7/27/2012 1:02:20 AM | | Preferences:
7/27/2012 1:02:20 AM | | max memory usage when active: 9214.82MB
7/27/2012 1:02:20 AM | | max memory usage when idle: 9214.82MB
7/27/2012 1:02:20 AM | | max disk usage: 20.00GB
7/27/2012 1:02:20 AM | | max CPUs used: 6
7/27/2012 1:02:20 AM | | (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
7/27/2012 1:02:20 AM | | Not using a proxy
There are only two lines that relate to the hard drive. I've highlighted those lines in red. I'll set the two parameters as you and Gundolf have recommended and then wait and see what happens. I left swap space at 50%. Since I have so much available space, I didn't think the numbers for those parameters would actually matter.
What is interesting to me is that STan told me about errant stderr.old files. I had originally found one at c:\users\mdawson\appdata\local\virtualstore\programdata\boinc\slots\0. At the time I deleted the file. In checking now, I see where there is a newer stderr.old file where you'd expect it to be (c:\program data\BOINC\slots\0 and \slots\4. There are 6 slot directories. The others don't have an stderr.old file. In looking at the directory structure STan talked about, there are only 2 \slot directories created. 0 and 4, but this time neither has an stderr.old file. I can't explain that either.
Hopefully this info will help get to the bottom of this.