Если нужно читать в Overlapped, то WaitCommEvent все равно не нужен. Нужно сразу запускать ReadFile, и если она вернулась с ошибкой IO_STILL_PENDING (кажется так), запускать WaitForSingleObject на event'е из OVERLAPPED, а затем GetOverlappedResult. (А можно сразу GetOverlappedResult и поставить ему TRUE в последнем параметре)
Указывайте по максимуму. И timeout'ы не забудьте выставить
Принимается больше, но надо ждать   
'За один раз' - это за какой раз? UART не режет посылки на пакеты, единственный способ различить 'разы' это timeout'ы. Причем, если ДО вызова ReadFile уже пришло несколько пакетов, то их отличить друг от друга (на уровне ReadFile) уже невозможно

в режиме Overlapped получился такой поток чтения:

ReadFile стоит чуть больше секунды и возвращает ERROR_IO_PENDING всегда. Приняты данные или нет можно судить по bytes_read. Так поток и "крутится". В Overlapped режиме, в отличие от обычного, ReadFile не создает описанных ранее подвисаний.
Таймауты такие:


В первом посте я описывал, что принимается 14+1 байт при отправке 15-ти байт. В потоке чтения в цикле принималось сначала 14 байт (как сообщалось в comstat.cbInQue), на втором цикле принимался еще один байт (также сообщалось в comstat.cbInQue).

Делаю замер скорости на двух компьютерах. 
Настройки COM порта такие:
       
На 2х компьютерах запускаю написанную программу, на 2-ом устанавливаю флаг slave_mode (т.е. сразу после чтения он отправляет принятое назад).
Передаю циклически буфер из 20 байт, содержимое каждый раз меняю для контроля правильной передачи и приема.Время контролирую с помощью компонента Timer из стандартного набора Borland. Интервал таймера выставлен 55мс, т.к. меньшие интервалы, похоже, таймер не чувствует.
Делаю 15 циклов передачи, соответственно вижу, что на компьютере, с которого отправлял: отправлено 300 байт (15 раз по 20 байт) и принято 300 байт. Все без ошибок. Затраченное время 3740мс = 3,74с.
Подсчитываю скорость: 300 байт * 2 / 3,74 c ~ 160,43 байт/с =  1283 бит/с. Никак не 9600 бит/с
Учтем, что пересылка идет, наверное, по 8 информационных бит, к которым добавляется 1 старт и 1 стоп бит. Итого на 300 байт информационных издержек: 300*2 =600 бит = 75 байт. Т.к. в тесте пересылка идет туда и обратно: 75*2 = 150 байт. 
Итого передано всего (300+75)*2 байт / 3,74 с ~ 200,54 байт/с = 1604,3 бит/с. Опять далеко не 9600 бит/с

Не учитываю время затраченное компьютерами на запись информации в буфера, т.к. считаю его незначительным по сравнению со временем, затраченным на передачу данных.
В чем ошибка расчета скорости?  Может не по 8 информационных бит передается? 

Что то не так. Передается по 10 бит (минимум). Попробуй отправить большой пакет данных (все 300 байт за раз), и замерять время не таймером, а функцией замера времени (GetTickCount() например)

Сделал таким образом:

Запускается поток MainThread, который запоминает значение точного счетчика, запускает запись в порт, дожидается окончания чтения ответа и сравнивает текущее значение счетчика с запомненным ранее. В итоге, вроде как, точность - 10ки микросекунд.
Пересылаю буфер размером 300 байт.
Результат: время пересылки к slave и обратно = 628623 мкс (в среднем)
Скорость: 300 байт * 2 / 0,63 с = 952,5 байт/с = 7619 бит/с
Транспортных издержек (1 старт и 1 стоп бит):  300 * 2 = 600 бит = 75 байт
Итого: (300 +75)байт * 2 / 0,63 с = 1190,5 байт/с = 9523,8 бит/с
Это уже похоже на правду.
Почему же при пересылке маленькими пачками скорость так падает?

Переключение thread'ов отнимает много времени. Возможно еще где то есть лишние системные вызовы

Выяснил, что если в ReadFile ставить приемный буфер больше, чем реально пересылается байт, то возникает задержка.
Так при передаче 300 байт и с 300 байтным буфером приема пересылка туда и обратно происходила за 0,052сек. 
При передаче 17 байт с 300 байтным буфером приема такая пересылка занимает более 0,2сек.
Если же выставить 17 байтный буфер приема, то пересылка занимает 0,0037сек, что соответствует скорости 93176 Бит/с (при настройке порта на 115200 Бит/с).
Видимо на эту задержку в зафисимости от размера приемного буфера влияют таймауты.

Естественно
Влияют, причем вне зависимости от размера   
Если в процессе приема данных закончился буфер, то ReadFile немедленно прекращает чтение, остаток данных останется лежать в буфере системы (и timeout'ы на это не влияют). 
Если же в процессе приема закончился входной поток, то система будет как минимум ждать ReadIntervalTimeout ms после приема последнего байта (ну нету другого способа узнать, что поток прекратился), и только потом ReadFile прекратит чтение.

Имеется ввиду буфер системы, который устанавливается  SetupComm(COMport,2000,2000) ?
Правильно ли я понимаю, что на пути принятой информации всего два буфера: аппаратный FIFO буфер, который можно отключить или задать размер 1-14 байт на прием и 1-16 на запись и программный, устанавливаемый SetupComm?
Что будет если отключить FIFO буфер? Данные сразу будут писаться в программный буфер? Тогда для чего вообще нужен FIFO буфер, он как-то ускоряет обмен?

Да
Да
Да
Нет. Без него могут теряться байты на больших скоростях. UART будет посылать прерывания в CPU на каждый принятый байт, и если драйвер порта не прочтет этот байт до прихода следующего, то он потеряется (и установится ошибка приема)
Это было актуально на старых машинах, на современных машинах это может проявится только на мегабодных скоростях и 100% загрузке процессора   Хотя отключать его (FIFO) все же не стоит - надежности оно все таки добавляет

Спасибо большое за ответы. Поставил бы плюс, если б у меня было достаточно постов. 
Похоже, данная тема форума единственное место, где можно найти ответы на почти все возникающие вопросы при написании обмена по COM порту во всем инете. Все примеры, что раскиданы по инету (по большому счету их около 3х видов) не помогли мне, как помогли здесь.

xvr +1