Борьба с Windows 10, скорость передачи пакетов

Программирование
#1

Здравствуйте. Есть прибор на базе STM32. На нем реализовано устройство которое передает на комп данные с частотой не менее 200 пакетов в сек. по протоколу HID. По сути все просто пара датчиков. Размер пакета 32 байта. Частота рассчитана на уровне железа, длина пакета 32 байта и отправка каждые 5 мс итого 200 фпс. Сбор пакета занимает максимум 1мс.
На компе есть программа которая эти данные принимает и выводит частоту получения.

Прием данных организовал через стандартные функции WinApi

        public static bool ReadReport(IntPtr HidDeviceObject, byte[] InputReport, HIDP_CAPS Capabilities, ref uint NumberOfBytesRead)
        {
            bool result = false;
            if (HidDeviceObject != IntPtr.Zero)
            {
                CancelIo(HidDeviceObject);
                result = ReadFile(HidDeviceObject, InputReport, Capabilities.InputReportByteLength, ref NumberOfBytesRead, 0);
            }
            return result;
        }

Но наблюдается какое то странное поведение. На стационарном компе Windows 7 программа показывает нормальную скорость в 200 фпс. Ту же самую прогу и устрйоство ставим на 10 и скорость падает до 60 фпс. Еще отмечу что это ноутбучная система.

Кто может подсказать что не так с этйо десяткой?? В плане ппроизводительности ноутбук достаточно матерый. 6 ядер. 16 гигов. План производительности выставлен максимальный.
Может у семерки еще где нибудь настройка для скорости?

#2

А это именно фпс, то есть что-то рисуется, или просто пакеты/сек?

Если первое, то наверно стоит отвязать скорость рисования от приема пакетов — рисовать реже, новые пакеты полученные за это время.
Монитор же все равно вряд ли 200 Гц.

#3

Под фпс понимается скорость передачи пакета. В пакете 32 байта.
на отрисовку не влияет потому что это данные акселерометра, гироскопа и тд. Но требуется именно 200 раз в секунду определять положение.
Причем проблема как я понял только с Windows 10. На младших версиях стабильно 200 выдает.

#4

А ReadReport откуда вызывается?

#5

в смысле откуда?? поток работает в цикле и вызывает.

#6

Там просто цикл?

while (true)
{
    ReadReport();
}

а не какой-нибудь таймер и т.д.

#7

ну про таймер то я в курсе. Точно while/ К тому же если бы таймер был то результат был бы везде одинаковый. А тот конкретно на десятке.

#8

Ну так это 200 мс на сборку всех пакетов, итого 1,2 секунды на все. Может в этом все дело?
И еще, предположительно. Защитник оси может вносить задержки. Ведь устройство общается с ПК по USB. Точнее ПК опрашивает устройство, но не в этом суть.

P. S.
Пиплы в сети жалуются на пакет обновление KB4515384
USB HID device issue after September 10, 2019—KB4515384 (OS Build 18362.356) windows update
Решали вопрос кто-как.
Кто откатом обновления, а кто обновлением самого драйвера устройства в “диспетчере устройств”.

#9

Это что за математика??

Так ведь дескрипторами прописана жесткая работа с железом. USB ведь достаточно жесткий протокол. Шаг влево - расстрел и отказ в обслуживании. Причем поковыряли в биосе, отключили Power Control и чудом стало 200. Но основная причина так и не понятна.

код приема:

 while (!StopProces)
{
Thread.Sleep(2);
if (WinApi.ReadReport(device, data, DevCapatibylity, ref readed))
{
// конвертация и вывод в поля .. 
}
}
#10

это 0.2 секунды :slight_smile:

#11

Верно, это только сборка. А еще опрос устройства каждые 5 мс, и так 200 раз = 1 с.
1 с + 0.2 с = 1.2 с. Такая вот математика.
Но это все фигня по сравнению с тем что люди написали относительно обновления, ссылка предыдущего поста.
Там один пользователь жаловался на серьезные тормоза в работе клавиатуры и мышки после установки пакета. Это видимо и есть истинная причина. С новой фичей новый баг от Microsoft.

#12

ОС Windows не является системой реального времени. Поэтому ждать от неё адекватных задержек при работе с железом - это просто вера в лучшее и светлое :wink: Может повезти, а может - нет.
для доказательства этого раньше очень просто поступали - запускали в отдельном окошке форматирование дискеты и всё, всё подвисало - винда занималась только этим.

#13

Никто от нее жесткого временного интервала не требует. От нее требуется просто укладываться в определенные рамки хотя бы примерно.

Решение нашлось в правке дескрипторов устройства. Теперь все работает стабильнее. Подробности тут