Победа над скоростью Wifi_K-line

Всем привет.
Довольно долго велись поиски проблемы низкой скорости при прошивке блоков управления при помощи адаптера Wifi_K-line . Если быть точнее, то пол года, не меньше. Не скажу, что занимался только этой задачей, но внимания уделялось ей много.
В поисках решений мне много помог Влад qwerty095, за что ему большое спасибо.

Собственно о чём речь…
Время чтения прошивки с блока Январь 7.2 составляло ~2 минуты. Пакеты с адаптера на ПК и обратно летели очень тухло. Было видно как "редко" моргает светодиод отправки данных. Но стоило просто запустить браузер "Chrome", пошевелить мышкой на форме и скорость в разы увеличивалась! Установка связи с блоком проходила за пару секунд! Более наглядно эффект можно посмотреть в видео:

Вот так появился вопрос: "Каким образом активность браузера так увеличивает скорость?!"

Поиски были долгими и с разных направлений. Одним из предположений было, что браузер меняет приоритет системы работы с сетью или режим работы служб QoS. Был скачан сниффер TCP и разобран протокол общения ОС с сетью. Были проверены временные задержки между отправкой пакетов на ПК и получением их на адаптере. Всё было красиво, пакеты доставлялись в пределах пинга, меньше 1 мс. Ясным стал лишь факт, что скорость зависела от задержки между отправкой пакетов. Предполагалось, что VSPD вносит свои задержки со стороны COM- моста, но это не подтвердилось.

В общем, много было предположений, но всё мимо, пока не наткнулся на интересную забугорную статью о проблемах работы библиотеки System.IO.Ports .NET. В статье очень "красиво" поливали грязью разработчиков этого чуда и были приведены факты, что ряд методов этой библиотеки работают неадекватно и их нельзя использовать при обработке данных. Многие глюки ранее я уже обнаружил и наставил "костылей", а некоторые не знал. Также было сказано, что в библиотеке используется стандартный системный таймер с разрешением 15 мс.

После прочтения и осмысливания данной статьи пришлось отказаться от этой библиотеки и разобраться в прямой работе с драйвером Win32 API. Попутно была изучена работа с видеотаймером, который позволяет получить разрешение меньше 1 мс.

Также было принято решение полностью переработать программу Wifi_tuner на основе новых знаний с созданием отдельных классов и их взаимодействия без нарушения принципов ООП.
В добавок был разработан свой протокол общения между программой на ПК и адаптером Wifi_k-line, который в себя включает заголовок, тип данных, длину и контрольную сумму. Теперь сводится на нет возможность пересечения служебных и полезных данных.
После проделанных изменений появилась программа Wifi-OBDII Dridge. По сути, это новая программа, написанная с чистого листа, но сохранившая интерфейс и фундаментальные принципы Wifi_tuner. Да, название решил сменить т.к., по факту, она ничего не настраивает и изначально название дал некорректное.

Внешний вид Wifi-OBDII Dridge:

Как видно, интерфейс остался почти без изменений. Добавлено два таймаута, поле с отображением количества пакетов в секунду и активация нового алгоритма связи.

Сравнение скорости прошивки Январь 7.2 наглядно можно увидеть в видео:

На старом алгоритме при установке связи скорость была 6 п/с, а на новом :

Разница в 5 раз! На мой взгляд, достойно!

Общее время чтения прошивки:
Было: 2 мин 5 с.
Стало: 27 с.

Время записи прошивки:
Было: 2 мин 17 с.
Стало: 37 с.

Скорость работы с прошивкой ТРС на новом алгоритме:

Разница незначительна. Количество пакетов увеличилось с 10 до 12.

Скорость работы с пакМАН на новом алгоритме:

Разницы совсем нет. Видимо на программном уровне реализована выдача диагностики раз в 100 мс. Положительный момент переработки в том, что теперь оболочка работает с типом адаптера USB-FTDI.

Вывод.

Таким образом получилось:
— снизить задержки между пакетами, что актуально для коротких посылок;
— более чем в 4,5 раза увеличить скорость чтения и записи прошивки на Январь;
— стабильно получать 12 п/с при работе с ТРС на длинной диагностике;
— заставить работать оболочку пакМАН с типом адаптера USB-FTDI.
— повысить стабильность связи за счёт применения своего протокола связи и отказа от библиотеки .NET.

Спасибо за внимание!