cant see some processes (EDIT: Comdo and other Security Suites)

[norain]

Since the last few updates of Comodo Internet Security I can no longer see it running in Process Lasso.
The name of the process is cmdagent.exe. There is also cfp.exe but I think that is the gui. They prohibit changing any attributes of their processes. I want to lower its priority, so hopefully there is some way to do it.  I am not sure why it isn't being seen by Process Lasso. The sysinternals program "Process Explorer" sees it and tracks its actions just fine.  So far, I've found nothing  that can change anything about this process. I think it runs as a service. At least I should be able to see it and watch it chew up cpu resources.  This runs as user "NT AUTHORITY\SYSTEM"
Any idea how they can remain hidden to Process Lasso?

[Jeremy Collake]

Due to Comodo's aggressive Tamper Detection system (whatever clever name they gave it), we had to avoid 'looking at' their processes. Otherwise their tamper detection system, being as smart as it is, emits thousands of duplicate log events and hogs the PC. In contrast, some other products simply block write access, or make limited logs. Comodo was just way too aggressive, not much that could be done - and we tried several possibilities. It makes me wonder sometimes if they don't want task managers looking at their processes, though are of course obliged to support the 'big names' and those built into Windows.

[norain]

Ok, I wondered if it might be intentional.  Well, I think I'll find another security product. I hate not being able to control the Comodo processes. I have to turn off most of their protection to operate, as I have numerous real-time programs running all the time.  Process Lasso works well to enforce user programs to play well with each other.
I do have a really serious problem with randomly losing data due to DPC latency on the firewire and USB ports. I don't know any product that really helps this out. I have tried Process Lasso tricks but so far have not had much success fixing that particular problem.
Boy, if Process Lasso could help with that...that would be great. (hint) 

[Jeremy Collake]

I have to remain neutral since I have a relationship with all these companies, so have no issues with Comodo, Symantec, or anyone else - to be clear.

However, it is fine to hear Comdo is uninstalled. Be sure not to run without security software. I can not responsibly recommend that! Anyway - Comodo's tamper detection really is one of the worst. I test against it knowing it will flare up for Process Lasso daring to open it's processes with read virtual memory rights. These rights are needed to read certain metrics shown by Process Lasso. They can't really harm anything, BUT .. well, I can't control Comodo. Symantec does the same thing. Symantec eluded to a work-around using non-standard APIs, which is no big problem since I already use the NT Native APIs. However, that didn't work either. As expected, the same permissions are used no matter from which level you open the process.

That said, there *might* be alternatives that I haven't found yet. These include advanced ways to 'incidentally' open the process, etc... However, sneaking around just to 'look at' a process seems absurd. At least to me. Worst is that since there is little to no 'log throttling', the tamper detection events themselves can bring the PC to a grinding halt. Thousands of duplicate log entries (the security software's log) that serve no real purpose and would do nobody any good. Have I spoken to them about it? Yes, but 'them' is a person, and at a corporation it all about finding the right person. Second, they don't really give a rats butt, nor get paid to - thus it has been hard to have any action taken on this issue. Thus, for now, I avoid the processes.

As for DPC Latency dropping out, I have planned to SHOW the DPC Latency, but can't promise any improvements .. Each system likely has its own unique cause, and most (not all) involve monopolization of one resource or another. Whether a hardware bus or a stream of software IRPs, there is always something hogging the 'attention' (we'll call it) of the PC - even if just briefly. ProBalance is designed to be the best I can do. It really has a minimal impact on DPC latency though, except perhaps in lab conditions or certain rare scenarios.

Out of curiosity, what have you got going on such that you are monitoring your DPC Latency? Real-time multimedia creation or playback? Games? Perhaps by explaining how Process Lasso helps you, we might get to how it could assist you better.

[BenYeeHua]

So you has been using latencymon and found that the DPC latency are cause by 2 drivers that used by firewire and USB ports?
As I know, having a high DPC latency on USB are caused by third-party usb 3.0 and updating the driver or disable maybe can solve it.
I don't have a Firewire, and had Google it, some DPC latency are caused by Displaycard or Wifi driver(can be solved/reduced by using WLAN Optimizer).

Sorry for my Bad English.

[Jeremy Collake]

So you has been using latencymon and found that the DPC latency are cause by 2 drivers that used by firewire and USB ports?
As I know, having a high DPC latency on USB are caused by third-party usb 3.0 and updating the driver or disable maybe can solve it.
I don't have a Firewire, and had Google it, some DPC latency are caused by Displaycard or Wifi driver(can be solved/reduced by using WLAN Optimizer).

Pretty much what I said - an I/O device hogging a bus . Some bad drivers could cause such issues, sure. Some USB 3.0 drivers may be too poorly optimized to handle the throughput that some USB 3.0 devices can handle. Same could go for Firewall Firewire. UPDATE: I speak mostly about their inclination to self-throttle, or sufficiently share the bus.

What REALLY needs done .. and this is what Microsoft's kernel does .. is throttle the I/O activity. Actually limit it. Now, Process Lasso's 'Hard Throttling' does this to CPU activity, but it doesn't take much CPU activity to issue I/O requests, and is a dangerous operation anyway. Thus, I don't recommend it here.

[BenYeeHua]

Pretty much what I said - an I/O device hogging a bus . Some bad drivers could cause such issues, sure. Some USB 3.0 drivers may be too poorly optimized to handle the throughput that some USB 3.0 devices can handle. Same could go for Firewall.

What REALLY needs done .. and this is what Microsoft's kernel does .. is throttle the I/O activity. Actually limit it. Now, Process Lasso's 'Hard Throttling' does this to CPU activity, but it doesn't take much CPU activity to issue I/O requests, and is a dangerous operation anyway. Thus, I don't recommend it here.

Make some correction, that person say Firewire(IEEE 1394) 
Seen like you need a rest after ver 6 become a stable version.
----
Ya, the Microsoft's kernel always delay the function for few years(that having on linux), don't know in Windows 8 has this problem or not.
As I/O is a problem in the tablet(Surface, for example)
Just like Bufferbloat, when need to drop the packet, it just keeping it 
And what harm will get if throttle the I/O activity?
As example, throttle the I/O activity on wifi adapter, packet delay?

[Jeremy Collake]

Blame it on spell correct ;p. I obviously meant Firewire (not in dictionary, is now).

As for throttling I/O, the problem is the type of I/O, the best way to do it, and how to minimize the unpredictable results of doing so. While in some cases, such as TCP/IP network I/O, where packets are designed to be 'lost', you can just drop packets. Not true of all protocols going over the network though. The end result, depending on what packet is dropped, can also vary a lot. That is ONLY for TCP/IP network I/O though.. other types of I/O simply can not be dropped. Disk I/O for instance. You can't drop it. The best you could do is delay it, but that probably would just make things slower, and would require a file system filter driver (what security software uses to scan every file that is opened), or a disk layer filter driver. The results of delaying any specific I/O Request Packet (IRP) are unpredictable on the calling applications though, all the way up the stream. Could easily lead to a cascading series of failures, possible extreme responsiveness issues, or even deadlock or livelock in a worst case scenario.

[Jeremy Collake]

Oh, and it is not the old days anymore, but back in the old days, adjusting your PCI latency could help a lot with DPC latency. It is the time a device is allowed to hold the PCI bus. Lower it, and it ensures more devices have a chance to get the bus. Raise it, and bandwidth on the bus is improved for particular devices.

[BenYeeHua]

Oh, and it is not the old days anymore, but back in the old days, adjusting your PCI latency could help a lot with DPC latency. It is the time a device is allowed to hold the PCI bus. Lower it, and it ensures more devices have a chance to get the bus. Raise it, and bandwidth on the bus is improved for particular devices.

Ya, I know about PCI latency, normally an old MB is 64, and the new MB is 32 for default.
So by throttling I/O is difficult to prevent I/O Request Packet (IRP) issues, other way to lower DPC latency?

And why windows 8 can (make other program) operating smooth like having a SSD(by using hdd as system disk)?
By reducing page fault?

[DeadHead]

FYI, software such as "Easy Tune" (and similar) triggers DPC Latency spikes. In other words, spikes in DPC Latency is not always caused by hardware and/or faulty drivers. Be sure to check your systems thoroughly when using that type of analyzing software.

[Jeremy Collake]

FYI, software such as "Easy Tune" (and similar) triggers DPC Latency spikes. In other words, spikes in DPC Latency is not always caused by hardware and/or faulty drivers. Be sure to check your systems thoroughly when using that type of analyzing software.

Indeed, which is why software that makes changes to the system registry, services, or other things in a claim to 'boost' performance should be taken with a grain of salt. Not only can it be counter-productive, but it can cause real problems.

[Jeremy Collake]

So by throttling I/O is difficult to prevent I/O Request Packet (IRP) issues, other way to lower DPC latency?

Again, depends on the cause. The *exact* cause must be isolated. You've partially done that, but to be more precise would require serious digging (time being money, cheaper to buy a new PC ;o). Anyway, no other way I know of, though Google may help more than me, but I'm sure you've been through it for ages .

And why windows 8 can (make other program) operating smooth like having a SSD(by using hdd as system disk)?
By reducing page fault?

That is a good question. It does run snappy, or at least appears to (part could be illusions). I am not sure what they did, to be honest. Perhaps their 'page out' (to keep free cache space in RAM) is less aggressive, that is a possibility. Perhaps they increased SuperFetch with some 'default' set of common data to prefetch and try to keep cached, instead of having it populated as the machine is used. They may have removed a lot of unnecessary code from the kernel too, sanity checks and such that they could feel comfortable removing from the release build since this NT6 derived kernel is now more mature than it once was. I will have to research this .

I will read their official docs about their improvements, and go through their code. I will let you all know when I know more.

[BenYeeHua]

Again, depends on the cause. The *exact* cause must be isolated. You've partially done that, but to be more precise would require serious digging (time being money, cheaper to buy a new PC ;o). Anyway, no other way I know of, though Google may help more than me, but I'm sure you've been through it for ages .

LOL, I am just 17 years old, I not that old. 

Finding the cause and changing the hardware is more easily.(time being money, like you say)
-----

That is a good question. It does run snappy, or at least appears to (part could be illusions). I am not sure what they did, to be honest. Perhaps their 'page out' (to keep free cache space in RAM) is less aggressive, that is a possibility. Perhaps they increased SuperFetch with some 'default' set of common data to prefetch and try to keep cached, instead of having it populated as the machine is used. They may have removed a lot of unnecessary code from the kernel too, sanity checks and such that they could feel comfortable removing from the release build since this NT6 derived kernel is now more mature than it once was. I will have to research this .

I will read their official docs about their improvements, and go through their code. I will let you all know when I know more.

With SuperFetch improved, but booting more faster, can opening the program more faster after boot without giving time to fetching the data?
Maybe like you said, removed a lot of unnecessary code, but using the reduced load time to load the data that needed after boot.(that what I like to do, reducing the boot time to load the unnecessary programs, and using it on load the necessary programs)
I found also Windows 8 need more time to copy/moving a file/folder compare to Windows 7.

The maximum possible is kernel, maybe they also changing the useless Windows Disk Defragmenter and the way to writing file into HDD.
As I know, having some gaps after/before the file/folder can making the new data continuity(if they are writing on the gaps, not randomly writing at other place), and make defrag more faster.
And the best way for now is buying a SSD and using it as a System Disk(and putting most used file on it), using HDD as a storage disk.

Trying to find out why is difficult as Microsoft just explain a little(I am lack of source/time to find it), by reading what they had say(about the video call, I forgot to bookmark the link  ), I think windows 8 is reducing the lag/delay that can be feel and increasing the lag/delay that can't be feel(for example,incremental GC).

[Jeremy Collake]

Also, one thing we also must remember, as I'm reminded of from time to time, a default Windows 7 or Windows XP install is pretty darn snappy itself. I will post details as I know of the specific optimizations they made.

[BenYeeHua]

Also, one thing we also must remember, as I'm reminded of from time to time, a default Windows 7 or Windows XP install is pretty darn snappy itself. I will post details as I know of the specific optimizations they made.

Thank~

[arcanum]

PCI latancy et stuff like that can be modified via BIOS settings.

That was oldskool way when we tuned the shit via bios.

I managed to get 679 of ree DOS ram

Thise were the times

-arc

[Jeremy Collake]

Yea, sadly haven't seen it as a BIOS option in a long time. There is also some software that lets you set it per-device on your PC, dynamically - at runtime. Apparently this is a 'setting' of many Windows device drivers. I can not say whether this utility worked or not, but it is somewhere out there ... Nice little utility, would show the current PCI Latencies of a list of devices, and let you change them - an operation that seemed to persist.

BTW, official definition of PCI Latency, since mine may have been less clear:

How this works is that each PCI device that can operate in bus-master mode is required to implement a timer, called the Latency Timer, that limits the time that device can hold the PCI bus. The timer starts when the device gains bus ownership, and counts down at the rate of the PCI clock. When the counter reaches zero, the device is required to release the bus. If no other devices are waiting for bus ownership, it may simply grab the bus again and transfer more data.

- Source Wikipedia

[BenYeeHua]

Yea, sadly haven't seen it as a BIOS option in a long time. There is also some software that lets you set it per-device on your PC, dynamically - at runtime. Apparently this is a 'setting' of many Windows device drivers. I can not say whether this utility worked or not, but it is somewhere out there ... Nice little utility, would show the current PCI Latencies of a list of devices, and let you change them - an operation that seemed to persist.

PCI Latency Tool?
All the similar tool are outdated.
So be careful when using it, by buying a PCI-E sound card is a better way to avoid it(when DPC latency has no problem), or using ASIO buffer is a better way also(but with increased delay).

[edkiefer]

PCI Latency Tool?
All the similar tool are outdated.
So be careful when using it, by buying a PCI-E sound card is a better way to avoid it(when DPC latency has no problem), or using ASIO buffer is a better way also(but with increased delay).

you are correct PCI-E have no timers .-

As I remember it some devices would hog the PCI bus (vid, sound cards) .

here the tool .

http://downloads.guru3d.com/download.php?det=951

[Jeremy Collake]

It is superseded by newer buses that don't have latency timers/counters like this, but the legacy PCI bus still exists on most systems and many devices are attached to it. Especially some on-board devices, and of course whatever you've got in the PCI add-on slots (not PCIe).

Thanks for the link Ed

[edkiefer]

right, if you use PCI card then I am pretty sure it still applies but it been many yrs since video cards used PCI  . we went to AGP1,2x,4x , PCI-E for vid's .

The link I posted says its no good for AGP and PCI-E right in description . I kind of remember ATI having the issue with a 256 values, if you lowered it it supposedly help with saturating the PCI bus .

[Jeremy Collake]

Thinking about it, BenYeeHua has the right idea.

Since most on-board sound cards are going to be connected to the legacy PCI bus, replacing it with a PCIe sound card would yield a great improvement .. assuming the user is using on-board sound, and that PCI bus saturation is even the cause.