In ETL files we have a bunch of OS events that we do not have in EventPipe *.NetPerf files. This lack of information is unfortunate, and we should fix it. Here are some missing things.
These could be put on the ProcessInfo event
The Processor Speed
The Processor Count (And whether it is hyperthreaded).
The Time zone where the data is collected
Total Machine Memory (when will paging start).
Expected sampling rate for the thread sampling.
To replace the page fault events, some memory statstics, logged every second or two. (Can get from System.Diagnostics.Process including
* Working Set
* Peak Working Set
* Virtual Memory Allocated
* Private Memory Allocated
* Page Faults.
* Disk I/O bytes and number.
* Average Disk response time (if available).
* Network activity.
We also need an unambiguous version number for the runtime (we have the Runtime/Start but it should be a rundown event (always logged even in circular buffer), and the version number should be accurate (today we don't have a sensible version number).
In short a trace should never be WORSE than any common performance counter.
This is a very straightforward work item (and can be implemented in managed code).
In ETL files we have a bunch of OS events that we do not have in EventPipe *.NetPerf files. This lack of information is unfortunate, and we should fix it. Here are some missing things.
These could be put on the ProcessInfo event
To replace the page fault events, some memory statstics, logged every second or two. (Can get from System.Diagnostics.Process including
We also need an unambiguous version number for the runtime (we have the Runtime/Start but it should be a rundown event (always logged even in circular buffer), and the version number should be accurate (today we don't have a sensible version number).
In short a trace should never be WORSE than any common performance counter.
This is a very straightforward work item (and can be implemented in managed code).