I'd like to clarify a couple points. The Windows 10 setting which can use your computer's upload bandwidth to share updates to/from other PCs (peer-to-peer), can be found in Settings -> Update & security -> Windows Update -> Advanced Options -> Choose how updates are delivered. There's an option to turn on/off the feature entirely, and an option to decide whether to "share to/from PCs on my local network" or "additionally share with internet PCs".
We noticed, on the Vista x64 machine with 8GB ram, that Thunderbird and Microsoft Security Essentials were interacting quite a bit and consuming large amounts of RAM and moderate amounts of CPU. I suggested to disable the Windows Indexing of the messages, which is controlled in Thunderbird via the "Allow Windows Search to search messages" feature. We'd uncheck it, click OK, but then it'd come back checked. We had to close Thunderbird, disable the Windows Search (indexing) service, start Thunderbird, disable the feature, close Thunderbird, re-enable the Windows service, open Thunderbird, and verify the change took. That sound help somewhat. The BOINC option for "Leave non-GPU tasks in memory while suspended", is pretty self-explanatory, and there's a tooltip that goes into more detail. The tooltip says "If checked, suspended tasks stay in memory, and resume with no work lost. If unchecked, suspended tasks are removed from memory, and resume from their last checkpoint." The tasks decide when to checkpoint (saving data to disk). Windows decides when to swap out memory pages to a swap file, not BOINC. And, even if a task was fully sent to the swap file, it will be resumed right from where it left off, with this BOINC option checked (except GPU tasks, which MUST be fully unloaded on suspend, because the GPU memory doesn't support swapping). So, in general, it's recommended to leave the BOINC option on, I believe. PS: To my knowledge, tasks do not save their state to disk at BOINC shutdown. They only save their state to disk, at a checkpoint and at completion. For startup options, there's one inside BOINC. Go to Options -> Other Options -> General, and find the option for "Run Manager at login?". You can use that to stop BOINC from starting on login, on a non-service-install at least (theoretically - not sure if I've ever tested it). Additionally, if you want the BOINC client to not run tasks until a specified timeout occurs, you can use the <start_delay> option in cc_config.xml to do so. More details on setting that up can be found here: http://boinc.berkeley.edu/wiki/Client_configuration I believe it's likely that the real culprit here, will be multiple programs fighting for a limited amount of memory. We were unable to see the problem manifest itself. But, when it does, I'd look to Resource Manager, to see if the swap file is being hit hard on the Disk tab, and also look at memory usage to see if it's over-committed. Your BOINC value of "Use at most 35% memory" may still be too high, if you have any other memory-intensive applications competing with it. That's my hunch at least. Kind regards, Jacob > To: [email protected] > From: [email protected] > Date: Fri, 13 Nov 2015 20:36:01 -0600 > Subject: Re: [boinc_dev] Problems with cached memory under 64-bit Windows > > I found the older messages from Christian Beer; it appears that he's > only reporting > problems, not exploiting them. > > I've never had P2P or Windows 10 on the computer showing the worst signs > of the > problem. > > My internet connection is the highest speed U-Verse connection available > for this > location, and does not appear to be having any significant problems. > > In the last few days, Jason Klein and I spent about 2 hours looking for > the problem. > We found that part of the problem was due to a poorly documented setting > under > Thunderbird (the email/newsreader program I use) that told Windows to index > the Thunderbird messages so that searches outside Thunderbird could find > them. > Changing that setting was difficult - the first half dozen tries or so > didn't work. I've > already reported that as a bug to Mozilla. I had no use for this > indexing, but it took > significant amounts of memory and CPU time. In case someone else has > the problem, > the partial fix we found was to start Thunderbird, Tools, Options, > Advanced, System > Integration, turn off Allow Windows Search to search messages. Note that > changing > this setting does not seem to work properly unless done in the window > opened by > clicking Check Now. > > With this partial fix, I no longer have problems starting the non-BOINC > 32-bit > programs while running BOINC, but the cached memory is often still slow > at releasing > memory when such non-BOINC 32-bit programs need more memory. > > I've considered running only BOINC while looking for the problem; this > is unlikely > to show the problem, since the main sign of the problem is slowdowns of > non-BOINC > 32-bit programs running at the same time that BOINC is running. It is > not necessary > for this 32-bit program to be Thunderbird for the problem to show. > > We considered changing the BOINC setting under the Advanced View, Tools, > Computing preferences, Leave non-GPU tasks in memory while suspended, but > could not agree on what we expected this change to do - it's just too poorly > documented and may have changed over the years. Does it allow workunits > read back from the swap file to resume where they were suspended, or does it > make such workunits resume from their last checkpoint? > > I have not found a way of restarting Windows without also having BOINC > start up > shortly afterwards. It seems likely that doing this could affect > whether BOINC files are > loaded into cached memory, though. > > Robert Miles > > ------------------------------ > > > > Date: Tue, 10 Nov 2015 21:34:41 +1030 > > From: Jason Groothuis <[email protected]> > > To: Robert Miles <[email protected]>, > > "[email protected]" <[email protected]> > > Subject: Re: [boinc_dev] Problems with cached memory under 64-bit > > Windows > > > > Part sounds like genuine application client & application leaks being > > explored by Christian Beer, and other parts sound almost like your host > > might be P2p serving windows 10, which apparently is a thing. How's your > > internet connection ? > > > > ------------------------------------------------------------------------------------------------------ > > Jason Richard Groothuis > > bSc(compSci) > > > > ------------------------------------------------------------------------------------------------------ > > > > > >> To: [email protected] > >> From: [email protected] > >> CC: [email protected] > >> Subject: Re: [boinc_dev] Problems with cached memory under 64-bit Windows > >> Date: Tue, 10 Nov 2015 04:45:19 -0600 > >> > >> Either a Windows restart or a Windows reboot is another partial > >> workaround, but their effects last only until Windows finishes > >> reloading cached memory - perhaps half an hour. Of the two, a > >> Windows reboot takes longer and appears to have no more effect. > >> > >> Or did you mean a reboot during the longer workaround that involves > >> resetting the projects? I described it as requiring removal and > >> restoring the projects instead by mistake, but resetting the > >> projects instead is sufficient. It looks like it is likely to be > >> at least a week before it gives enough of a slowdown for such a > >> test to give results comparable to resetting and restarting. > >> > >> Robert Miles > >> > >> -----Original Message > >> Date: Tue, 10 Nov 2015 20:08:39 +1030 > >> From: Jason Groothuis<[email protected]> > >> To: Robert Miles<[email protected]>, > >> "[email protected]" <[email protected]> > >> Subject: Re: [boinc_dev] Problems with cached memory under 64-bit > >> Windows > >> > >> Q: does a reboot clear the condition faster ? > >> > >> ------------------------------------------------------------------------------------------------------ > >> Jason Richard Groothuis > >> bSc(compSci) > >> > >> ------------------------------------------------------------------------------------------------------ > >> > >> > >>> To:[email protected] > >>> From:[email protected] > >>> Date: Tue, 10 Nov 2015 03:34:35 -0600 > >>> Subject: [boinc_dev] Problems with cached memory under 64-bit Windows > >>> > >>> I found a partial workaround for this problem, enough to allow starting > >>> 32-bit programs for a few week after the workaround is applied. > >>> > >>> Set Activity to Suspend network activity. Set ALL projects to No new > >>> tasks. Set Activity back to either of the enabled settings. Now, for > >>> each project with no workunits on your computer, Remove that project > >>> to delete its project files. For the projects that still have > >>> workunits on your computer. wait until all those workunits are finished > >>> and reported back to the server. Then Remove those projects as well. > >>> When there are no projects left, shut down the BOINC client. Restart > >>> or reboot Windows. Restart the BOINC client. Add all the removed > >>> projects again. If you see No new tasks on any of the projects, enable > >>> new tasks for those projects. > >>> > >>> It's now allowing 32-bit programs to start from the console, but still > >>> often very slow at giving them more memory when they need it. > >>> > >>> -----Original Message > >>> Date: Mon, 26 Oct 2015 20:45:28 -0500 > >>> From: Robert Miles<[email protected]> > >>> Subject: [boinc_dev] Problems with cached memory under 64-bit Windows > >>> > >>> What I'm seeing indicates that is what's supposed to happen, but not > >>> quite what is actually happening. It seems to preload memory just as > >>> you expect, but NOT free much of the preloaded memory of BOINC-related > >>> files when it is under memory pressure because a 32-bit program or an > >>> attempt to start a 32-bit program needs it. It does seem to free > >>> preloaded memory as needed when a 64-bit workunit needs it, and starts > >>> up 64-bit programs fast enough that I'd also expect it to free > >>> preloaded memory as needed for 64-bit programs started from the console. > >>> > >>> If BOINC has no control over this, then the most that BOINC developers > >>> can do is to allow reducing the total size of the project directories, > >>> as I previously requested, and try to help persuade Microsoft to allow > >>> more control over SuperFetch and provide a way to see just what > >>> SuperFetch has stored in the preloaded memory. > >>> > >>> I don't especially want to start removing the more memory-hungry > >>> BOINC projects from my computers, except for the few projects that > >>> allow downloading only 64-bit workunits, which seems to be the only > >>> option I currently have. Many of the programs I want to run from the > >>> console simply aren't available in 64-bit forms. > >>> > >>> -----Original Message > >>> Date: Tue, 27 Oct 2015 00:10:46 +0000 > >>> From: Rom Walton<[email protected]> > >>> Subject: Re: [boinc_dev] Problems with cached memory under 64-bit > >>> Windows > >>> > >>> From my understanding Superfetch tries to use all the memory on a > >>> machine. > >>> It preloads various programs and files into memory just in case you want > >>> you use them. If Windows finds itself under memory pressure, it just > >>> forgets about the stuff in the cache to make room for the stuff you want > >>> at that moment. > >>> > >>> As far as I know, there isn't anything a program can do to control that > >>> behavior in Windows. > >>> > >>> ----- Rom > >>> > >>> -----Original Message----- > >>> From: boinc_dev [mailto:[email protected]] On Behalf Of > >>> Robert Miles > >>> Sent: Monday, October 26, 2015 5:15 PM > >>> To:[email protected] > >>> Subject: [boinc_dev] Problems with cached memory under 64-bit Windows > >>> > >>> Probably, but finding a name for the cause of the problem offers little > >>> help in fixing it. > >>> > >>> ---- Robert > >>> > >>> -----Original Message-----Date: Mon, 26 Oct 2015 14:56:54 +0000 > >>> From: Rom Walton<[email protected]> > >>> To: Robert Miles<[email protected]>, > >>> Subject: Re: [boinc_dev] Problems with cached memory under 64-bit > >>> Windows > >>> > >>> I believe you are running into SuperFetch. > >>> > >>> See: > >>> http://www.osnews.com/story/21471/SuperFetch_How_it_Works_Myths > >>> > >>> ----- Rom > >>> > >>> -----Original Message----- > >>> From: boinc_dev [mailto:[email protected]] On Behalf Of > >>> Robert Miles > >>> Sent: Monday, October 26, 2015 10:51 AM > >>> To:[email protected] > >>> Subject: [boinc_dev] Problems with cached memory under 64-bit Windows > >>> > >>> BOINC appears to have a problem with filling the cached memory in a way > >>> that prevents Windows from using that cached memory for any 32-bit > >>> programs until the next restart or reboot. Problem seen under 64-bit > >>> Windows Vista and 64-bit Windows 7; 64-bit Windows 10 appears to have a > >>> similar problem even if it does not call anything cached memory; I do > >>> not have any running other versions of Windows to check. > >>> > >>> 64-bit workunits appear to be able to get cached memory freed if they > >>> need it. I do not run 64-bit programs from the console often enough to > >>> tell if such 64-bit console programs can also free cached memory or not. > >>> > >>> One of my computers with 8 GB of memory and 64-bit Windows Vista is now > >>> often unable to start its email program unless I have shut down BOINC. > >>> Another computer, with 16 GB memory and Windows 10, does not have as > >>> obvious a problem yet, but the email program is often slow to start or > >>> run there. > >>> Suspending BOINC to free CPU use does not help. > >>> > >>> My Windows Vista computer currently has 5319 of its 8190 blocks of > >>> physical memory labelled as cached, and is slow to respond when I start > >>> a 32-bit program with significant use of memory. > >>> > >>> Still, the help files do not appear to explain what cached memory is, > >>> whether it is useful to reduce the amount of cached memory, and if so, > >>> how to do this. > >>> > >>> So many files on the hard drives that defragmentation, full virus scans, > >>> and other operations on all the files take 3 to 5 days, even with > >>> nothing else running. These are mostly message files from using Windows > >>> Mail and Windows Live Mail to read newsgroups, and save most of the > >>> messages read or even downloaded but not yet read. This is so long that > >>> I seldom run any operations that require reading all the files. Quick > >>> virus scans find nothing of interest, though. > >>> > >>> The motherboard appears to be at the maximum amount of physical memory > >>> it can handle. > >>> > >>> Could several of you join me in asking Microsoft to add an explanation > >>> of whether it is useful to reduce the amount of memory cached, and if > >>> so, how to reduce the cached memory? I'd like for them to provide a > >>> program to show more about what is being cached, including any file > >>> names, so that users can look harder at the files cached most often. For > >>> example, I'd like to check if files that a program used months ago but > >>> but not more recently are getting stored in the cache every time that > >>> program runs. > >>> > >>> I've found information on what memory caches are supposed to be used for > >>> (faster access to items likely to be used again), but it looks like > >>> BOINC does not allow enough of the cached memory to be freed when 32-bit > >>> programs need more memory. > >>> > >>> One idea of how to change BOINC to reduce the number of BOINC-related > >>> files in cached memory: BOINC already has a feature for allowing > >>> frequently used files to be stored in project directories so they can be > >>> saved for any future workunits that need them. A new feature could be > >>> added to allow BOINC servers to tell BOINC clients that some of the > >>> files in the project directories are not expected to be used again, and > >>> therefore should be deleted from the project directories so that they > >>> cannot be loaded into cached memory in the future. > >>> This may need some thought about what to do if a project mistakenly > >>> lists a file as no longer needed, but some later workunit tries to use > >>> it anyway. > >>> Note that both the server and the client will need to have sufficiently > >>> recent software for this new feature will work, so it should be designed > >>> in a way that will allow older BOINC software to ignore it if only one > >>> end of the connection supports the feature. > >>> > >>> I have not found a definite way to duplicate this problem, but the > >>> following method seems likely: Start with a computer with 8 GB of > >>> memory or less, and running 64-bit Windows. Install a recent version of > >>> BOINC, if it isn't already installed. Connect it to each of the > >>> following BOINC projects, and run each of their applications at least > >>> once: > >>> > >>> World Community Grid > >>> rosetta@home > >>> ralph@home > >>> PrimeGrid > >>> Milkyway@Home > >>> GPUGRID > >>> FiND@Home > >>> Einstein@Home > >>> Albert@Home > >>> > >>> These projects were the ones that use the most disk space on my > >>> computers, and therefore probably have the most space used in their > >>> project directories. > >>> My computers are connected to enough other projects to have about 20 > >>> projects in all connected. > >>> > >>> Now, with all but one of the CPU cores running 32-bit CPU workunits, and > >>> a GPU workunit also running, start trying to start some 32-bit program > >>> that uses a lot of memory. > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
