Latencymon что это за программа
Как пользоваться latencymon
Если системные прерывания нагружают процессор.
Виной тому, что процессор перегружен практически в течение всего сеанса могут быть так называемые системные прерывания, а это, в свою очередь, означает, что проблема кроется в области установленного на компьютере оборудования или драйверах для этих устройств. Но предупреждаю сразу: даже объёма всей этой статьи не хватит, чтобы вычленить все причины (и тем более варианты их решений) почему системные прерывания просто убивают Windows. Ибо подход к поиску проблем усложняется использованием куда более сложного инструмента, чем тот, что описывается здесь.
Что такое системные прерывания и как попробовать справиться с перегрузкой процессора?
Причиной прерываний (точнее, слишком медленной время от времени работы) могут служить девайсы внутри вашего компьютера, установленные программы, а иногда и сам процессор. Ведь системные прерывания – есть некая форма взаимодействия между программой/«железом» и самим процессором. Всякий раз, когда новому процессу нужно появиться в системе, процессор бросает все дела и выполняет задачу. Неважно, нажал ли пользователь мышку или процесс запущен по расписанию, задача сразу добавляется в очередь на исполнение. По её выполнению процессор возвращается к предыдущему состоянию.
Как понимаете, системные прерывания вполне могут сигнализировать системе и пользователю, что в данный момент некоторые вычисления идут с ошибкой, что и выражается в серьёзных потреблениях ресурсов процессора этим «процессом». В здоровой системе системные прерывания «потребляют» НЕ БОЛЕЕ 2% от общего объёма работы процессора. Хотя мне встречались и процессоры с показателем прерывания от 3 до 10 %% – всё зависит от конфигурации. Но если вы заметили, что процессор тратит на прерывания хотя бы 5 – 10 %% от своей вычислительной мощности от сеанса к сеансу, это сигнал того, что у компьютера проблемы.
Системные прерывания. Как бороться с высокими показаниями?
Каждый из следующих шагов потребует перезагрузки системы. Не потому что так принято, а потому проблемы с прерываниями решаются часто простым перезапуском Windows.
Самое первое средство, которое поможет определить, виноваты ли битые драйверы в том, что системные прерывания нагружают процессор, это немецкая утилита DPC Latency Checker. Скачайте её по этой ссылке:
Установки не потребуется. Суть утилиты проста. Запускаем и начинаем работу в Windows до тех пор, пока системные прерывания не начнут нам мешать. Вот окно нормально работающей сборки:
А вот они начинают себя проявлять:
Утилита в поле комментария на английском языке советует вам перейти в Диспетчер устройств и приступить к поэтапному отключению сетевых устройств, звуковых карт, USB контроллеров, устройств bluetooth. Советую прислушаться. После каждого отключения всматривайтесь в Диспетчер задач и окно утилиты, посмотрите, как система реагирует на временное отключение оборудования. Продолжите отключением всех внешних устройств: модемы, внешние диски, флешки. И если в какой-то момент наметятся изменения к лучшему, примите решение об обновлении драйвера к устройству. Но чтобы не было проблем с запуском Windows, вот эти устройства лучше не отключать (эти драйверы жизненно необходимы, но это тоже драйверы, и вполне возможно придётся переустановить дрова на материнскую всем пакетом как при установке Windows начисто):
На такой же манер действует и программа LatencyMon
Она потребует установки, зато также бесплатна. Её задача – поиск файлов драйверов с высоким показателем вычислений, потраченных на отложенный вызов процедуры (процесса, который вызывается процедурой обработки прерывания в ответ на само прерывание, но необязательно сразу же исполняется). За этим мудрёным названием скрывается процесс поиска драйверов, в файлах которых хранится информация о том, что драйвер слишком много требует от процессора для обслуживания своего, приписанного конкретно ему устройства. Вот страница издателей:
на которой, впрочем, я своими слепыми глазами ссылки для скачивания не нашёл, а потому представлю вам возможность скачать программу с моего сайта
СКАЧАТЬ БЕСПЛАТНО ПРОГРАММУ LatencyMon
Переходим во вкладку Drivers и отсортируем их по наиболее уязвимым показаниям, нажав на колонку DPC count:
К первым в строчке присмотритесь: они и могут быть причиной ваших проблем.
Был один момент, когда ну никак не удавалось вычленить причину тормозов. Помог случай: пользователь “хапнул” вирус, который совершенно уничтожил DirectX, причём действовал крайне избирательно, убивая именно системные файлы Windows, оставляя DirectX игровые dll-ки. Пришлось ремонтировать систему обновлением, и – о чудо! – вместе с дрянью пропали и системные прерывания. Я не пожалел немного времени, но результат оказался неожиданный. Виновниками оказались не вирусы и не драйверы, а пакеты обновлений. Вот их имена:
Я настаиваю, что именно ПОСЛЕ УСТАНОВКИ ИМЕННО ЭТИХ ОБНОВЛЕНИЙ конкретный пользователь начинал мучиться от перегрузки системными прерываниями. Как-то так… вам информация к размышлению.
Тоже может послужить причиной того, что системные прерывания нагружают процессор донельзя. Приступайте к проверке, если предыдущий поиск битых драйверов успеха не принёс. А поможет вам в поиске проблем с “железом” сама Windows и встроенные утилиты самодиагностики. О них я писал уже в статье Тестирование компьютера: встроенные утилиты. Пробегите глазами, информация окажется полезной, не сомневайтесь. Знайте – отошедшие от разъёма шлейфа также могут быть виновниками злоключений. Я лично сталкивался с проблемами и перегрева процессора, и “забывчивости” про-апгрейдить BIOS для новенькой Windows 10 (об этом ниже) – везде итогом были заметные системные прерывания.
ПРИМЕЧАНИЕ. Если системные прерывания одолели ваш ноутбук, вам придётся убедиться, что у вас нет проблем с умирающим аккумулятором. Прочтите статью, как проверить батарею ноутбука собственными силами.
Собственно, речь идёт о том, чтобы сбросить звуковые эффекты в Windows до установленных по умолчанию. Щёлкните по иконке звука правой мышкой и нажмите на Устройства воспроизведения:
Во вкладке Воспроизведение щёлкните два раза по пункту дефолтных устройств (у меня Динамики), пройдите во вкладку Дополнительные возможности и установите галочку напротив Отключить все эффекты. Применить – ОК. Перезагружаемся и проверяем:
Не исключено. BIOS – первая программа, которая запускается после нажатия на кнопку включения компьютера. Так что время проверить обновления для вашей BIOS. А чтобы поиски нужной версии не затягивались во времени, проверьте версию вашей BIOS прямо сейчас. В консоли команд cmd наберите последовательно две команды:
systeminfo | findstr /I /c:bios wmic bios get manufacturer, smbiosbiosversion
I в первой команде – это большая латинская i.
Причина в жёстком диске?
“Вполне себе и даже очень”. Самый простой способ – проверьте диск на ошибки с помощью встроенных средств типа chkdsk. Если после “прогона” системные прерывания поутихли, причина обнаружена. Однако в случае, когда проблема появляется вновь и вновь, при всём том chkdsk неизменно обнаруживает ошибки, у вас проблемы (с жёстким, БП или материнской платой) – готовьтесь к худшему.
P.S. Ну, судя по отзывам проблема народ теребит. Обещаю тему развить в следующих статьях.
Решение проблемы подвисания компьютера (Windows 7, 8)
Starting and stopping LatencyMon
When LatencyMon starts, it will display a message to click the Start button to start analysis. Click the start button. The page under the Main tab will give an overview of the most important information. A detailed report is available under the Stats tab. When you are done click the Stop button.
On a multi processor system, LatencyMon offers the option to exclude one or more CPUs from being measured by selecting them from the options menu. For a complete analysis you should select all available CPUs. This feature may be useful to check which CPUs are connected to interrupts and verify how ISRs and DPCs are distributed among available processors. Also it may allow you exclude certain processes to which you have assigned a certain affinity.
High DPC or ISR routine execution times: how to proceed
If LatencyMon reports the DPC and ISR execution times to be too high, you should take a look at the responsible drivers. It may be that these drivers belong to a device that is non-critical for the operation of your computer. If for example tcpip.sys or ndis.sys is reported as the culprit, chances are the problems are caused by your wireless network adapter, if you have one. You could consider disabling the WiFi adapter and receive internet via an Ethernet cable. You can disable devices by right-clicking on My Computer and selecting Device Manager, right-clicking a device and selecting disable. You should run LatencyMon again to check if the situation has improved, there might still be another device or driver causing audio latencies.
Note that if high latencies have been reported to be caused by drivers which are critical for the operation of your computer such as motherboard drivers, there may be nothing you can do to get your computer suitable for processing real time audio.
Hard pagefaults: how to proceed the investigation
We believe that hard pagefaults are the most common cause of audio dropouts. The effect of a program hitting hard pagefaults while playing audio is usually dramatic. One problem with pagefaults is that they often come in groups so that a row of pagefault causes interruption of the audio stream. Another problem with them is that unlike ISRs and DPCs, putting in more processors into a system will not help you to avoid them. Page faults need to get resolved immediately and any thread that hits them is suspended until the pagefault is resolved. Hitting a hard pagefault on a page file or memory mapped file that is backed on a drive that is spun down because of a power feature may interrupt a program for several seconds until it can proceed. If hard pagefaults are reported but no high DPC and ISR execution times you should investigate if these are the cause of audio dropouts. The difficulty with pagefaults is that they are common to occur so it’s hard to find out if they are the cause of audio dropouts and stutter. In order to find out if pagefaults are the cultprit you need to know that the pagefault occured in the process responsible for producing audio and also while it was producing audio.
To verify that the hard pagefault occured in your audio program, take the following steps:
Hard pagefaults should only be considered a problem if you can hear they are actually interrupting the audio stream. It is common for any program which uses a lot of memory to hit hard pagefaults. By observing the Processes view while audio is playing you can find out if hard pagefaults are being hit while audio is playing. If you found out that pagefaults are the cause of audio dropouts you should read the next section on how to avoid them.
How to avoid hard pagefaults
Other causes of audio dropouts, pops and clicks
This section summarizes a list of other possible causes of audio dropouts, clicks and pops. If there are no high DPC or ISR execution times reported and hard pagefaults are not the cause of the problems you should consider these.
Audio buffer sizes
To reduce midi to audio latencies (that is the time between a key press on a MIDI keyboard and the occurrence of the actual sound), the audio buffer size of the audio driver should be as low as possible. But it must be supportable by the system. The acceptable limit of 2000µs for DPC and ISR execution times has been arbitrarily chosen. The lower your audio buffer size, the lower the tolerance for long execution times of DPC and ISR routines and page fault resolution. In order to retain a system that does not drop out you may need to increase your audio buffer size. So it might be that your system is not suitable for low midi to audio latency but you might still be able to find an acceptable balance that works.
If a software synthesizer or effect requires too much execution time to compute its audio buffers in time it will cause stutter, clicks or pops. This can for example easily happen when playing too many voices or too many virtual instruments at the same time in a software synthesizer.
If there are simply too many threads competing for CPU time an audio program may not get enough attention from the scheduler to process its audio buffers. Threads are selected based on a priority scheme but if there are multiple programs running with threads running at high priority, there may just be not enough CPU time available for the audio software to fill its buffers in time. Threads responsible for producing audio normally run at highest or real-time priority. Competing threads with a lower priority may still get scheduled because the balance set manager which is part of the operating system will boost threads with a lower priority to avoid thread starvation. Closing down unnecessary programs, services and getting more CPUs will help you.
Bugs in audio software
Bugs in audio software can of course create all sorts of artifacts including pops and clicks. If problems are limited to one particular audio program or plugin, chances are it’s the program’s fault. It also deserves mentioning that exception handling requires a lot of processing power and causes interrupts to occur on the processor on which it’s running. A very common example is an audio plugin program which does not mask off floating point exceptions so that each division by zero or other forseeable problem causes an interrupt to occur.
Bugs in hardware or audio drivers
Bugs in hardware and audio drivers may also be responsible for causing stutter, pops and clicks.
All execution times are calculated based on a fixed CPU clock speed which is listed. For most accurate results you should disable variable clock speed settings in your BIOS setup such as Intel TurboBoost, SpeedStep and AMD Cool N Quiet.
Because of the nature of the software, it does not make sense to run this program inside a virtual machine if you wish to obtain useful measuring results.
LatencyMon documentation and articles
Note: this content is currently being updated.
LatencyMon русская версия
Когда компьютер лагает, выдает баги, а звуки заметно проедают или отстают (например, во время процесса прохождения игры), то на первый взгляд может показаться, что проблема кроется в соединении с интернетом. Это не всегда так. Бывает, что лаги появляются от системных ошибок. Чтобы удостовериться в этом и просто мониторить задержки всех процессов, была создана утилита LatencyMon. Бесплатно скачать последнюю версию приложения на русском языке вы сможете в самом конце странички.
Описание и возможности
LatencyMon – это приложение, предназначенное для анализа системы, позволяющее определить, насколько ваш ПК способен воспроизводить музыку и звуки без регулярных сбоев. Да-да, первоначально утилита предназначена для определения причин искажения звуков. Назовем главные функции софта:
Как пользоваться
В этом разделе мы расскажем, как установить программу на ПК пошагово с поясняющими скриншотами, а также о том, как пользоваться LatencyMon.
Загрузка и установка
Итак, вот подробная инструкция по установке:
Инструкция по работе
Этот инструмент предназначен для профессионалов и продвинутых пользователей, которым требуются полные отчеты, помогающие юзерам найти процессы, вызывающие задержки звука. Управление интуитивно понятное: значок зеленого треугольника запускает анализ, красный квадрат – приостанавливает его.
Для начала рекомендуется провести тест со всеми выключенными приложениями. Если проблем нет, то следует запустить ту программу (или требовательную игру), во время которой случались просадки. В случае, если проблема обнаружится и показатели будут выше 500 нс, то в скобках будет указан драйвер, вызвавший просадки. Чтобы проанализировать работу таймеров CPU, нажмите на CPU-Z. В этой вкладке будет подробно расписана вся информация о процессоре. Чтобы запустить таймер, перейдите в раздел Tools, а затем – Timers. В идеале все таймеры покажут одинаковое время.
Достоинства и недостатки
Итак, давайте же разберем позитивные и отрицательные стороны программы по сравнению с аналогичным софтом:
Похожие приложения
Рассмотрим еще несколько подобных программ, способных отслеживать задержки и выдавать отчеты о работе системы:
Системные требования
Скачать
Скачать программу можно ниже.
| Разработчик: | Resplendence Software Projects Sp. |
| Год выхода: | 2021 |
| Название: | LatencyMon |
| Платформа: | Windows Vista, 7, 8, 10 |
| Язык: | Русский |
| Лицензия: | Кряк в комплекте |
| Пароль к архиву: | bestsoft.club |
Видеообзор
В данном длинном видеообзоре ютубер подробно рассказывает о самой программе, этапах установки и о том, как оптимизировать Windows на примере 10 версии.
Как привести в норму показатели LatencyMon? (1 онлайн
Member
Наверное все сталкивались с выпадениями аудио сигнала, зависаниями, а некоторые до сих пор сталкиваются и не знают, что проблема в системе, а не в железе. Тот кто сталкивался с такими проблемами в работе DAW как задержка, хрипы, зависания наверное знают эту чудо программу. Поэтому объяснять здесь её смысл не буду.
Предлагаю тут делиться своими находками, твиками, которые привели к к более нормальным показателям или понизили эти показатели в LatencyMon.
То, что я нашёл в интернете:
1. Драйвер nVidia. Помогает замена в/к или использование встроенной. Понижает уровень Highest Execution Time
2. Драйвера от сетевой карты. Обычно проблемы вызывают ndis.sys, tcpip.sys. Те, у кого intel тем сюда. У кого realtek, то тем возможно поможет установка версии драйвера с сайта производителя. Почему-то на сайте производителя матплаты версия позднее.
3. Отключение в BIOS функций процессора EIST и C1E. В некоторых случаях помогает отключение Hyper-threading
4. Отключение всех энергосберегающих функции
Вспомню допишу.
Alf_Zetas
Инопланетянин
Active Member
Может подскажете? latency monitor говорит что:
— максимальная задержка от прерывания 50 000us (ругается )
— максимальное ISR 24 us (на ACPI.sys, иногда ATAPORT.sys)
— максимальное DPS 300us (tcpip.sys)
Aleksandr Oleynik
Well-Known Member
Active Member
У меня обычно трудности с интуитивно понятными интерфейсами
Вложения
Aleksandr Oleynik
Well-Known Member
Active Member
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 1862 MHz
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 40123,779283
Average measured interrupt to process latency (µs): 5,656684
Highest measured interrupt to DPC latency (µs): 304,113841
Average measured interrupt to DPC latency (µs): 1,304802
_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Total time spent in ISRs (%) 0,045752
ISR count (execution time =4000 µs): 0
_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Total time spent in DPCs (%) 0,242219
DPC count (execution time =4000 µs): 0
_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: svchost.exe
Total number of hard pagefaults 3264
Hard pagefault count of hardest hit process: 1867
Highest hard pagefault resolution time (µs): 748708,661654
Total time spent in hard pagefaults (%): 3,640463
Number of processes hit: 11
_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 2,485923
CPU 0 ISR highest execution time (µs): 303,244361
CPU 0 ISR total execution time (s): 0,262484
CPU 0 ISR count: 84720
CPU 0 DPC highest execution time (µs): 285,345865
CPU 0 DPC total execution time (s): 1,504135
CPU 0 DPC count: 371169
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 1,920909
CPU 1 ISR highest execution time (µs): 24,022556
CPU 1 ISR total execution time (s): 0,190380
CPU 1 ISR count: 34317
CPU 1 DPC highest execution time (µs): 129,349624
CPU 1 DPC total execution time (s): 0,893419
CPU 1 DPC count: 132622
_________________________________________________________________________________________________________
Aleksandr Oleynik
Well-Known Member
Не, просто отключить програмно сетефухи и посмотреть поможет ли.
Намасте_намасте
Well-Known Member
EUGEN27771
Well-Known Member
EUGEN27771
Well-Known Member
Active Member
Вложения
incubator
Well-Known Member
Active Member
CakeWorker
Друг киргиза-пришелец
Active Member
dimastar09
New Member
Active Member
Задержка от МИДИ клавиатуры
равна задержке от аудиовхода, а не 1/2 ))). Что бы там не писали люди знающие), ну или так о себе думающие
Aleksandr Oleynik
Well-Known Member
равна задержке от аудиовхода, а не 1/2 ))). Что бы там не писали люди знающие), ну или так о себе думающие
Zerocool
Jafaroff
Well-Known Member
Zerocool
Active Member
dimastar09
New Member
NielDeOne
New Member
В теме, который вы указали 60% флуда с оффтопом к сожалению
Вложения
Arkhipower
Well-Known Member
Появилось решение для acpi.sys? кроме как отключать acpi в устройствах? Latencymon беду показывает(
Aleksandr Oleynik
Well-Known Member
Появилось решение для acpi.sys? кроме как отключать acpi в устройствах? Latencymon беду показывает(
Оптимизация ПК и Reaper для максимальной стабильности и производительности
Active Member
Aleksandr Oleynik
Well-Known Member
Floxer
New Member
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 240 MHz
Measured CPU speed: 14 MHz (approx.)
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.
_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 1011,40
Average measured interrupt to process latency (µs): 9,758515
Highest measured interrupt to DPC latency (µs): 1000,30
Average measured interrupt to DPC latency (µs): 2,921356
_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Total time spent in ISRs (%) 0,026723
ISR count (execution time =4000 µs): 0
_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Total time spent in DPCs (%) 0,145446
DPC count (execution time =4000 µs): 0
_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
Process with highest pagefault count: none
Total number of hard pagefaults 0
Hard pagefault count of hardest hit process: 0
Highest hard pagefault resolution time (µs): 0,0
Total time spent in hard pagefaults (%): 0,0
Number of processes hit: 0
_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 5,047696
CPU 0 ISR highest execution time (µs): 112,190833
CPU 0 ISR total execution time (s): 0,572074
CPU 0 ISR count: 65413
CPU 0 DPC highest execution time (µs): 972,945833
CPU 0 DPC total execution time (s): 1,721058
CPU 0 DPC count: 200978
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 1,378506
CPU 1 ISR highest execution time (µs): 51,138333
CPU 1 ISR total execution time (s): 0,013673
CPU 1 ISR count: 1387
CPU 1 DPC highest execution time (µs): 447,155833
CPU 1 DPC total execution time (s): 0,084486
CPU 1 DPC count: 11780
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1,762406
CPU 2 ISR highest execution time (µs): 13,394167
CPU 2 ISR total execution time (s): 0,000044
CPU 2 ISR count: 6
CPU 2 DPC highest execution time (µs): 467,461667
CPU 2 DPC total execution time (s): 0,148341
CPU 2 DPC count: 24824
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 1,268843
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 484,05250
CPU 3 DPC total execution time (s): 0,109971
CPU 3 DPC count: 20091
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 4,262126
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 836,424167
CPU 4 DPC total execution time (s): 0,801610
CPU 4 DPC count: 200925
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 0,871132
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 306,734167
CPU 5 DPC total execution time (s): 0,067471
CPU 5 DPC count: 9365
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 1,271323
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 585,329167
CPU 6 DPC total execution time (s): 0,154413
CPU 6 DPC count: 28557
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 0,977558
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 472,361667
CPU 7 DPC total execution time (s): 0,101016
CPU 7 DPC count: 13999
_________________________________________________________________________________________________________