Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−49
void byteblaster_flush(byteblaster_t *ctx)
{
// Send dummy readback requests to round-up transmission FIFO
// to 62 bytes and suppress 16ms delay
if ((ctx->awaiting_from_ftdi % 62) != 0) {
char buf[62];
size_t padding = 62 - (ctx->awaiting_from_ftdi % 62);
memset(buf, BB_READBACK, padding);
byteblaster_send(ctx, buf, padding);
}
}
Я люблю FTDI!
FT245BL соглашается на bulk transfer либо если в буфере накопилось 62 байта, либо если прошло 16мс с последнего трансфера. В итоге, за секунду пролезает не больше 60 мелких пакетов (размером меньше 62 байт)... Даже сраные диалап модемы работали быстрее.
Запостил: 
bormand,
19 Марта 2016
Follow us!
Может они проосто не хотят балк гонять ради двух байт?
Проще выровнять на 62 ;)
Вот и пришлось добавлять байты до кратного 62, чтобы ответа не ждать целых 16мс.
видал я протоколы где надо было выравнивать запрос по 2^N байтов, но чтоб 62 это впервые
Благо число байт в её ответе можно легко предсказать и пустых команд на чтение накидать, которые 1 байт отправляют в ответ...
control - для небольших команд (настройки и т.п.)
interrupt - мелкие, но критичные к задержкам пакеты от железки (клавы, мыши и т.п.)
isochronous - выделенная полоса для всяких видео и звуков
bulk - с гарантированной доставкой но без гарантий по таймингам (флешки, принтеры и т.п.)
Если подключить винт и сетевуху через один хаб, может ли лагать сеть если канал заполнен диском и наоборот?
может ли лагать клава/мышь из-за перегрузки канала?
Ты про запись же? Это вендопроблема, емнип. Венда пытается спасти долбоёбов, выдирающих флешки без размонтирования, вот и флашит всё на каждый чих. Попробуй галочку переключить (диспетчер устройств, свойства флешки, быстрое извлечение vs пирфоманс).
> может ли лагать сеть
Да, USB сетевухи тоже через bulk работают.
> может ли лагать клава/мышь
Нет. У interrupt высший приоритет.
Как грубо!
Кстати, Windows пытается спасти ещё и тех простофиль, которые посмели не перезагружая компьютера подключить мышь, какой позор, на костёр их срочно!
P. S. А ведь USB на аппаратном уровне штекера поддерживает быстрое вытыкание.
во-первых это слово выдуманное от вытыкать
во-вторых вытыкать - это выкалывать. Глаз выткнул
по этому не соглашусь - USB на аппаратном уровне штекера не поддерживает быстрое вытыкание.
Толи Jack 6.2...
Ага. Устройство просто не сгорает от выдирания (хотя могло бы, если бы создатели USB этот момент не продумали).
Да, там неканон, здесь неканон, просто к остальному уже привыкли. Если делать всё правильно и по задумке природы, можно на всю жизнь остаться кучкой хаотично движущихся молекул.
Там единицей передачи является файл, должно лучше работать
а эта железка завязывается не на конфирмейшены, а на размер буфера или на время (почему-то)
Так что ты видимо хотел выпендриться своим знанием TCP, но потерпел крах
Полосу USB экономить пытались. Но как-то криво, имхо. Лучше бы кидали NAK при пустом буфере да и всё.
А в опенсурсной версии (видимо, отреверсили) я flush не заметил.
бери нормальное и будет все работать
это всё равно что взять самбу, и сказать "говно этот ваш Active Directory, ничерта не умеет"
Ты думаешь, что официальная либа лучше работает? Да хуй там.
> бери нормальное
Да я сам уже написал. И тот читерский паддинг до 62 байт дал 4000 write-read транзакций за секунду против 60-500 у штатной.
А тут и первый пакет задерживается.
Это ведь и есть твоя проблема?
Гость, ты уже понял что обосрался?
А эту железку явно просят отдать данные, а она жмотится и делает вид, что нихуя нету, пока таймаут не пройдёт.
З.Ы. В усб принципы немного другие. Железка ничего не может отправить, пока хост не попросит. Ну и подтверждение идёт сразу за пакетом. Поэтому никаких наглов тут не замутишь ;)
http://govnokod.ru/19660#comment317196
> таймаут
Ну нету у наглого таймаутов. Либо с того конца подтверждение придёт по предыдущему пакету, либо полный пакет наберётся.
Ты, наверное, про другую фичу - отложенное подтверждение пакетов (delayed tcp ack), когда другой конец не кидает ack сразу, а ждёт 500мс или какого-нибудь попутного пакета. Вот её сочетание с нейглом и write-write-read на сокете скатывает всё в ёбаный диалап.
А для неё надо:
1) write-write-read в программе
2) nagle на отправляющей стороне
3) delayed ack на принимающей
Вот тогда и получаются те самые "наберётся M байтов (и nagle пропустит ещё пакет) или пройдёт Nмс (и другой конец кинет ack, а nagle пропустит ещё пакет)".
https://tools.ietf.org/html/rfc896
Но тут же Нейгл пишет о говнорешении, которое в 60 году до него придумали... И предлагает его заменить как раз на алгоритм без таймаутов:
The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unacknowledged. This inhibition is to be unconditional; no timers, tests for size of data received, or other conditions are required.
- хост говорит IN (слышь, данные есть?)
- девайс отвечает NAK (пиздит, данные то есть)
- хост с неким интервалом говорит PING (а если найду?)
- девайс на них отвечает NAK (нету, заебал)
- и вдруг через 16мс на один из пингов отвечает ACK (ладно, ладно, есть у меня данные)
- хост кидает IN еще раз (ну давай их сюда)
- девайс кидает DATA
- хост отвечает ACK