-
Senior Member
Wait for x seconds of idle time
If you can figure it out and it is doable, it would be really cool if you could provide a setting in one of the config files somewhere that we could use to instruct the client to wait for x seconds of computer idle time before kicking in. Now that the client is taking up so much memory it has become a noticeable performance killer on Windows 2000 installs, even at the default priority level.
If you could monitor the windows idle process and see that it has at least 95% of the cpu time for x (5, probably) seconds before restarting the client and also have the client surrender all cpu usage when another process gets more than 5% of the cpu it might aid in keeping the existence hidden... er ... less obtrusive.
If this isn't feasible then I will just schedule the service to stop during business hours and then resume after hours if the user happens to leave their computer on overnight.
Thanks Howard.
P.S. this is a lower priority than beefing up the backend stuff.
-
Ancient Programmer
Here's me in agreement. That would really help in lessening the perceived impact of starting the program.
And EVERYTHING is secondary to the new backend!
-
Moderator
And there's always the ScreenSaver....
-
Senior Member
Is there any option to use the screensaver but not display the graphics? Seti@home has such an option as far as I remember, and using this option improves the speed of the client. I guess the screensaver is a bit slower than the textclient ...
-
-
Senior Member
Even before the -rt switch there were users that were very aware that DF was running, even on 1.6 GHz machines. If the client could stay completely out-of-the-way while users are interacting with the computer it would just make it that much more transparent and accepted.
-
Member
I see a distinct slowdown and pointer jerkiness (even on the fast Xeon systems). I became convinced that it was caused by interaction between DF and the NAI AntiVirus client and did some experiments.
Initially the scanned file count was going up too quickly to read.
Using a test machine, I excluded the files in the distribfold folder and could then see the scanned file count going up around twice a second, with the last file scanned always something like C:\WINDOWS\TEMP\nn_-nnnnnnnn
Totally switching off the AV on a test machine seems to cure the response problems. (Obviously this isn't practical for real machines, but it showed the source of the problem)
I can exclude the distribfold folder on standard machines (although this opens a theoretical security hole) but can't exclude the temp directory (as that would be a very real security hole!).
If these temp files are so frequently accessed, why are they on disk rather than kept in memory? (Even if they have to be on disk, is there a good reason they aren't put in the distribfold folder?)
Ni!
-
Moderator
The TEMP files are the protein.trj data file unpacked. They ARE loaded in memory if you do -rt, thats mainly what it does. You could be right about the NAV. I don't run that and I never notice any slowdown as long as I use the default priority setting.
-
Senior Member
Thanks Gunslinger, I also find that it is the interaction between NAV and the DF client that is causing the slowdown.
Howard, is there any chance that you could move the temp files to the DF client directory instead of the Windows TEMP directory? I can turn off the NAV file scanning in the DF folder, but agree with Gunslinger that it would be a bad idea to disable it in the Windows TEMP directory.
I have people that double-click on every email attachment that comes their way. I don't dare run without at least one virus scanner active on every desktop.
-
Member
Originally posted by KWSN_Millennium2001Guy
Howard, is there any chance that you could move the temp files to the DF client directory instead of the Windows TEMP directory?
Hmmm, I seem to remember that you can use the TEMP environment variable under windows (or TMP under Un*x) to set the temp directory? Can somebody confirm this? I definitely know this works under Linux, and hope it works under Windows, too.
Hope this helps,
Jerome
edit: sorry, I wasn't thinking properly. Of course this would probably mean that all temp data gets written to the DF folder. So: could another environment variable be used (or could this be configured via a command line switch, as requested)
-
Moderator
I will attempt to do that for the next release, so if I forget, remind me. Ill just look for an environment variable like DFPTEMP or something and if its undefined it will default to the normal TEMP on whatever OS.
-
Stir Fried
-
Member
Originally posted by Brian the Fist
I will attempt to do that for the next release, so if I forget, remind me. Ill just look for an environment variable like DFPTEMP or something and if its undefined it will default to the normal TEMP on whatever OS.
Excellent news!
If possible, could you also add a parameter into the service configuration file to perform the same function for those of us using net services on the Windows platforms?
Incidentally, I've been able to reduce most of the slowdown/jerky mouse problems by applying the Network Associates Hotfix that was pushed out to corporate customers today (McAfee Engine Version 4.1.60 HotFix 1)
From my testing it is apparent that, even when the -rt flag is in use, the temporary file is still touched once for each completed structure. Any chance that this could be corrected? (If so, it would have the side benefit of allowing the hard drive to spin down between uploads)
Ni!
-
Senior Member
Originally posted by Brian the Fist
I will attempt to do that for the next release, so if I forget, remind me. Ill just look for an environment variable like DFPTEMP or something and if its undefined it will default to the normal TEMP on whatever OS.
What is the name of the environment variable? Is it possible to include the temp path in the service.cfg file somehow? I would rather have the client be self-contained than have to edit the registry on 100 plus machines to add a new environment variable.
-
Moderator
The environment variable is DFPTEMP
It is in the latest Readme or whatsnew I think. You'll have to add it to your environment if you wish to use that feature though, sorry. Most people don't have 100 computers and so it isnt a problem for them
-
Senior Member
I just tested it, it works perfectly. Now I will begin the task of editing the registry manually on my farm.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules