Results 1 to 16 of 16

Thread: Wait for x seconds of idle time

  1. #1
    Senior Member KWSN_Millennium2001Guy's Avatar
    Join Date
    Mar 2002
    Location
    Worked 2 years in Aliso Viejo, CA
    Posts
    205

    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.

  2. #2
    Ancient Programmer Paratima's Avatar
    Join Date
    Dec 2001
    Location
    West Central Florida
    Posts
    3,296
    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!

  3. #3
    And there's always the ScreenSaver....
    Howard Feldman

  4. #4
    Senior Member wirthi's Avatar
    Join Date
    Apr 2002
    Location
    Pasching.AT.EU
    Posts
    820
    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 ...

  5. #5
    You could always run the clients without the '-rt' command, like how it was before.

    (Yeah, I know you'd be sacrificing speed! )

  6. #6
    Senior Member KWSN_Millennium2001Guy's Avatar
    Join Date
    Mar 2002
    Location
    Worked 2 years in Aliso Viejo, CA
    Posts
    205
    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.

  7. #7
    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!

  8. #8
    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.
    Howard Feldman

  9. #9
    Senior Member KWSN_Millennium2001Guy's Avatar
    Join Date
    Mar 2002
    Location
    Worked 2 years in Aliso Viejo, CA
    Posts
    205
    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.

  10. #10
    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)

  11. #11
    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.
    Howard Feldman

  12. #12

  13. #13

    Thumbs up

    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!

  14. #14
    Senior Member KWSN_Millennium2001Guy's Avatar
    Join Date
    Mar 2002
    Location
    Worked 2 years in Aliso Viejo, CA
    Posts
    205
    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.

  15. #15
    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
    Howard Feldman

  16. #16
    Senior Member KWSN_Millennium2001Guy's Avatar
    Join Date
    Mar 2002
    Location
    Worked 2 years in Aliso Viejo, CA
    Posts
    205
    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
  •