On Friday, April 1, 2005, 6:44:13 PM, Andrew wrote: <snip/>
CA> I also had a bad first experience with the persistent sniffer, and CA> switch to FireDaemon from SrvAny, and set the start priority for sniffer CA> to "Above Normal"; I can't prove it, but I'm convinced that without that CA> setting, Declude starves out other processes such as the persistent CA> sniffer, and then the other sniffer clients get impatient and process CA> the files themselves, causing more cpu pressure. This is an interesting thought --- when I pump it through the wetware it reminds me of a discussion I heard where Declude uses priority boosting as a kind of quazi locking mechanism to keep IMail from swiping files - or something like that... It may be different now or I may be remembering a fantasy,... however - In any case - adjusting the priority of the persistent SNF engine upward would cause a fundamental shift in power on the machine such that SNF would tend to influence the scheduling of all tasks by proxy. This would happen because during a heavy load the persistent engine would run flat out on the CPU until all of the messages in it's batch had been scanned... That particular stretch of code, for the most part, is so tight that you might be lead to believe it were a race condition if you didn't know better. Anyway --- given a sufficient priority boost - perhaps even a mild one, SNF would have a tendency to alternately usurp and release all of the CPU resources causing a kind of wave action to set up. With the exception of critical threads and IO handling, the system would tend to rock back and forth between processing messages and scanning them. (This would happen quickly enough and in large enough batches of work that most human-driven processes would never notice. It's almost like moving to a collaborative multitasking model and away from a preemptive one... actually the more I think about it, it seems like it might be a kind of blended model...) All of the other message processing (including SNF clients) would have a tendency to sleep through the scanning process - as a result, no client would ever really get the chance to become unhappy with the time it had waited... It would be like waking up after 100 years in line at the ATM machine to discover that your transaction had already been completed... only you can't account for the 100 years that went by. It's an interesting state to imagine... Also, during this time no other messages would be processed very far so the load for SNF would always be balanced. Specifically, the more heavily loaded SNF became the slower new messages would be added to it's queue - therefore a balanced equilibrium would be maintained at the full limits of the available hardware. Buffers would tend to become more full before any processing was handed off (that's actually more efficient, if less responsive)... all sorts of odd adjustments would happen to the world... The load failure sensitivity would move to new message acquisition and delivery and away from SNF scanning... and I believe, ultimately, toward the IO processes which are all going to survive because they have a higher interrupt and thread priority and because the actual workload there is much less (waiting 10s of milliseconds for the next 1500 bytes of data to show up is like waiting for the next new-year's party if you're a 2.4Ghz CPU...). I wonder if this is what really happens... (sorry for thinking out loud - just hoping to share insight if it's in there somewhere) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
