Page 1 of 11 12345 ... LastLast
Results 1 to 10 of 103

Thread: TeaTimer CPU load after startup thoughts

  1. #1
    Member of Team Spybot PepiMK's Avatar
    Join Date
    Oct 2005
    Location
    Planet Earth
    Posts
    3,601

    Default TeaTimer CPU load after startup thoughts

    Since many people ask about it, we gave the issue some thoughts as to what could be done about this:

    1. We could display it's acitivity; if it is showing which process it is scanning, that might make it more understandable.
    2. We could remember which files have already been scanned (hash of files) and thus "skip" known ones; would have to clear this cache after each update though since new updates might lead to different results.

    Thoughts please
    Just remember, love is life, and hate is living death.
    Treat your life for what it's worth, and live for every breath
    (Black Sabbath: A National Acrobat)

  2. #2
    Spybot Advisor Team [Retired] md usa spybot fan's Avatar
    Join Date
    Oct 2005
    Posts
    5,859

    Default

    PepiMK (Patrick):

    To start with, perhaps just an explanation of what TeaTimer is doing when it first starts would help.

    For example:

    Right now I have 53 processes running and if my Avira Antivir's "Active Processes" scan count is correct those 53 processes are using 2144 files (exe, dll, etc.).

    If I run my cursor over the TeaTimer system tray icon I see:
    • 88292 processes blacklisted.
    • 283740 known rating available.

    If I were to restart TeaTimer would it compare the 2144 files against the list if 88292 blacklisted processes, the 283740 rated processes, both or are there other things TeaTimer is doing?

    Getting an answer is one thing, learning is another.


    Microsoft Windows XP Home Edition running on a 2.40GHz IntelŪ PentiumŪ 4 Processor with 512 MB of RAM and a 533 MHz System Bus.

  3. #3
    Member of Team Spybot PepiMK's Avatar
    Join Date
    Oct 2005
    Location
    Planet Earth
    Posts
    3,601

    Default

    You're right, a quick overview might be helpful
    Those 283740 ratings are those entries from the RunAlyzer database that are of use here (e.g. LSPs are not monitored by TeaTimer, so they're not in the list). These are loaded from TTLassh.sbs.

    For each new, changed or deleted registry item, the lassh (hash sum of various of its properties) is calculated, and looked up in this list.

    While this includes the MD5 of an associated file, that is very quick, and lookup of the created lassh in a hash table returns a result immediately as well. So this part doesn't take user-noticable time.

    The 88292 processes are gathered from the regular detection databases, read from all .sbi files found (if you create your own, that would be more or less those File and DownloadFile rules as described on the OpenSBI wiki, though file paths etc. would be disregarded).

    TeaTimer tests every new process it finds against this database of 88292 items, and when you start TeaTimer, it will regard every running process as such a new process. In your case, that would mean those 53 processes, not those 2144 which probably includes both loaded modules and file handles.

    As for the speed, this is very similar to what thw new SDFiles.exe is doing, which is slow I have to admit. The changes appearing in 1.6 were mostly to reduce memory usage. By pre-organizing the data in memory, scans per file would be faster, but memory usage would increase. Keeping the in-memory database means slower per-file scans (I'm also thinking on various ideas how this could be improved).
    Just remember, love is life, and hate is living death.
    Treat your life for what it's worth, and live for every breath
    (Black Sabbath: A National Acrobat)

  4. #4

    Default

    hello,

    yes, please do so - the more visible information the user gets, the more are we able to find out, report & repair (system) errors ... (if any)


    ---
    in my case: (that's why I came here today :-) )
    my system resets / windows crashes without warning whenever teatimer starts - I don't know why yet, but it's everytime I start teatimer manually (it's already taken out of autostart / system start for observation)

    once I saw some kind of message: "you have more then 1083 files in temp" or something - then a count down (pretty fast) then my system crashes / resets again ...

    I do NOT say that teatime is the result of my system crashes - I had teatimer running before without any probs - but this time (only) it's different ...
    it could be some systemfile or virus and teatimer causing some kind of chain-reaction with the anti-virus software or something like this - anyways:

    it would be nice to see what files are getting checked by the teatimer so I can find out what file is causing that trouble ...
    (spybot 1.6 - winxp sp3)
    danke,

    oliver
    milius.net

  5. #5
    Senior Member
    Join Date
    Oct 2005
    Location
    Los Angeles
    Posts
    219

    Default

    Millus
    you seem to have a different problem
    start a new thread
    also post what AV and firewall you run
    do you or did you have any older AV or anti spyware installed
    did your machine come pre installed with a suite or AV?

    run CCleaner to clean up those temp files

    appreciate your comments on this topic
    Last edited by wyrmrider; 2008-07-15 at 19:22. Reason: typos

  6. #6
    Spybot Advisor Team [Retired] md usa spybot fan's Avatar
    Join Date
    Oct 2005
    Posts
    5,859

    Default

    PepiMK (Patrick):

    Thank you for the explanation.

    Both proposed enhancements have merit. The first would allow people to see that TeaTimer was actively scanning during startup and the second should reduce the startup time/utilization except immediately after updates.

    I can't think of anything else except possibly ordering the blacklisted processes and doing a binary lookup if it is not already being done.

    Getting an answer is one thing, learning is another.


    Microsoft Windows XP Home Edition running on a 2.40GHz IntelŪ PentiumŪ 4 Processor with 512 MB of RAM and a 533 MHz System Bus.

  7. #7
    Senior Member
    Join Date
    Oct 2005
    Location
    Los Angeles
    Posts
    219

    Default

    Is anyone surprised that T-timer is actually doing its job?

    There may be other ways to slice the baloney but for now
    you want resident protection- you get protection

    you want to clean up afterward then turn it off
    ps
    other Antispyware programs with resident protection take even longer

    you could also run Win Patrol (or similar) which would monitor and tell you something has already infected your system and maybe able to reverse the action
    does not have the "lag"

    (I run Win Patrol ALSO, IN ADDITION TO A real time Anti Spyware protector)

    you could also run System Safety Monitor, a virtual machine, Process Guard or similar

    All trade offs and all approaches open to discussion

  8. #8
    129260
    Guest

    Lightbulb

    Quote Originally Posted by md usa spybot fan View Post
    PepiMK (Patrick):

    To start with, perhaps just an explanation of what TeaTimer is doing when it first starts would help.....
    Ya, how about a notification balloon, like when you install avast antiviruis, it shows the balloon and does a box pop up that explains what stuff is, so that you know what the icon is and what it does. I think that would be the best option so that people would understand teatimer better upon first install of spybot. If md spybot fan meant something else, then oops, but I think something like i suggested would be a good way to understand teatimer.
    Last edited by 129260; 2008-07-15 at 21:50.

  9. #9
    129260
    Guest

    Default wow

    I feel really dumb. I read that thread so fast haha, i misunderstood what milius.net meant. I read that thread and that got me onto showing more teatimer information. Disregard my above reply lol.
    Last edited by 129260; 2008-07-15 at 23:47.

  10. #10
    Member Zer0 Voltage's Avatar
    Join Date
    May 2008
    Location
    Right behind you... BOO!
    Posts
    49

    Default

    @wyrmrider: Perhaps you should fully familiarize yourself with the problem reports and history before making any assumptions. This is a case of obvious abnormalities, not a need for trade-offs or alternatives and most certainly not some baloney case of TeaTimer doing its normal job. This is a case of TT needing a fix for a real and verifiable problem.

    First, on some systems, the TeaTimer process NEVER recovers. It jumps to 99% on start/restart and stays there. Period. Not for a few minutes. Not for a few hours. Permanently - at least until forced closed the hard way.

    On other systems, it jumps to 99% usage at boot and stays there for [at least] a few minutes, but then it does recover. But such a long spike shouldn't even be needed for truly normal activity in the first place.

    And unfortunately, until it recovers or is killed, an affected system is unusable because of the CPU flood.

    Other programs with resident protection DO NOT take even longer. On systems where this problem exists, every other real-time solution works fine - only TT is showing spikes.

    Of further significance is that these problems were introduced during the beta period. These problems were not always present. I know because I originally reported a similar (and likely related) TT crash problem here:

    http://forums.spybot.info/showthread.php?t=30453#7

    and it was only after that got fixed that the CPU spike issues began. In fact, as I said then, there were no similar TT problems up until RC2 (or maybe RC1). The original problem was not present in beta 1 and 2 and the spikes didn't occur until a fix was put in place for the reported TT crash.

    This all seems to be of rather critical importance to any potential resolution...

    So what changed in TT between beta 2, RC1, and RC2?

    And perhaps since this also never occurred before 1.6, what is TT doing now that it didn't do in 1.5.x?

    Once we define what changed, the logical test is to then disable whatever changed and see if the problems persists.

    At the very least, a way of displaying - or preferably logging - all TT activity would also be useful (as Patrick suggested). Trying to do that with something like Process Monitor just got too out of hand (generating 50+ Megs of data every few seconds).

    I am somewhat skeptical that this will come down to "normal" behavior, however, since on nearly identical systems with the same software and configuration different levels of the problem can occur - plus, like I said, the problem didn't occur with the betas.

    FYI, when TT does do something it is supposed to do, it does not spike - even on affected systems. It has a brief but normal resource increase, but that's it. I can only make a permanent spike [at will] by fully exiting and then later restarting it (at least on some systems). Further FYI, I have no TEMP files (auto-scrubbers in place) and usually <40 processes running. So anything TT does should be unnoticeable and instant (which truly normal "doing its job" TT behavior is).

    Anyway, thanks very much for continuing to look into this PepiMK. If you need me to help test anything or provide any other details, please just let me know. I may not be available much now though.

    Sorry if I posted any redundant info here, but evidently while I was away some people decided to start multiple separate threads for the same related issue...

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •