- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
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);
}
}
bormand 19.03.2016 22:11 # −15
guest 19.03.2016 22:50 # −15
Может они проосто не хотят балк гонять ради двух байт?
bormand 19.03.2016 23:17 # −15
Проще выровнять на 62 ;)
3_14dar 19.03.2016 22:35 # −15
bormand 19.03.2016 22:36 # −15
guest 19.03.2016 22:38 # −15
3_14dar 19.03.2016 22:39 # −15
bormand 19.03.2016 22:44 # −15
Вот и пришлось добавлять байты до кратного 62, чтобы ответа не ждать целых 16мс.
guest 19.03.2016 22:57 # −14
видал я протоколы где надо было выравнивать запрос по 2^N байтов, но чтоб 62 это впервые
bormand 19.03.2016 23:00 # −14
bormand 19.03.2016 23:03 # −15
Благо число байт в её ответе можно легко предсказать и пустых команд на чтение накидать, которые 1 байт отправляют в ответ...
3_14dar 19.03.2016 23:28 # −15
bormand 19.03.2016 23:47 # −15
bormand 20.03.2016 00:03 # −15
control - для небольших команд (настройки и т.п.)
interrupt - мелкие, но критичные к задержкам пакеты от железки (клавы, мыши и т.п.)
isochronous - выделенная полоса для всяких видео и звуков
bulk - с гарантированной доставкой но без гарантий по таймингам (флешки, принтеры и т.п.)
3_14dar 20.03.2016 01:04 # −15
Если подключить винт и сетевуху через один хаб, может ли лагать сеть если канал заполнен диском и наоборот?
может ли лагать клава/мышь из-за перегрузки канала?
bormand 20.03.2016 07:57 # −13
Ты про запись же? Это вендопроблема, емнип. Венда пытается спасти долбоёбов, выдирающих флешки без размонтирования, вот и флашит всё на каждый чих. Попробуй галочку переключить (диспетчер устройств, свойства флешки, быстрое извлечение vs пирфоманс).
> может ли лагать сеть
Да, USB сетевухи тоже через bulk работают.
> может ли лагать клава/мышь
Нет. У interrupt высший приоритет.
1024-- 20.03.2016 12:47 # 0
Как грубо!
Кстати, Windows пытается спасти ещё и тех простофиль, которые посмели не перезагружая компьютера подключить мышь, какой позор, на костёр их срочно!
P. S. А ведь USB на аппаратном уровне штекера поддерживает быстрое вытыкание.
kegdan 20.03.2016 14:16 # +2
во-первых это слово выдуманное от вытыкать
во-вторых вытыкать - это выкалывать. Глаз выткнул
по этому не соглашусь - USB на аппаратном уровне штекера не поддерживает быстрое вытыкание.
Толи Jack 6.2...
bormand 20.03.2016 16:29 # −15
Ага. Устройство просто не сгорает от выдирания (хотя могло бы, если бы создатели USB этот момент не продумали).
1024-- 20.03.2016 17:28 # 0
Да, там неканон, здесь неканон, просто к остальному уже привыкли. Если делать всё правильно и по задумке природы, можно на всю жизнь остаться кучкой хаотично движущихся молекул.
kegdan 20.03.2016 17:45 # 0
guest 21.03.2016 23:45 # −15
Там единицей передачи является файл, должно лучше работать
3_14dar 20.03.2016 20:57 # −15
guest 22.03.2016 01:42 # −15
j123123 30.03.2017 09:07 # 0
guest 19.03.2016 22:49 # −15
а эта железка завязывается не на конфирмейшены, а на размер буфера или на время (почему-то)
Так что ты видимо хотел выпендриться своим знанием TCP, но потерпел крах
bormand 19.03.2016 22:53 # −15
Полосу USB экономить пытались. Но как-то криво, имхо. Лучше бы кидали NAK при пустом буфере да и всё.
guest 19.03.2016 22:58 # −15
bormand 19.03.2016 23:23 # −15
А в опенсурсной версии (видимо, отреверсили) я flush не заметил.
guest 21.03.2016 23:45 # −15
бери нормальное и будет все работать
это всё равно что взять самбу, и сказать "говно этот ваш Active Directory, ничерта не умеет"
bormand 22.03.2016 00:56 # −15
Ты думаешь, что официальная либа лучше работает? Да хуй там.
> бери нормальное
Да я сам уже написал. И тот читерский паддинг до 62 байт дал 4000 write-read транзакций за секунду против 60-500 у штатной.
3_14dar 19.03.2016 23:30 # −14
bormand 19.03.2016 23:45 # −14
А тут и первый пакет задерживается.
3_14dar 19.03.2016 23:58 # −14
Это ведь и есть твоя проблема?
Гость, ты уже понял что обосрался?
bormand 20.03.2016 00:08 # −14
А эту железку явно просят отдать данные, а она жмотится и делает вид, что нихуя нету, пока таймаут не пройдёт.
З.Ы. В усб принципы немного другие. Железка ничего не может отправить, пока хост не попросит. Ну и подтверждение идёт сразу за пакетом. Поэтому никаких наглов тут не замутишь ;)
bormand 20.03.2016 00:21 # −14
3_14dar 20.03.2016 01:02 # −15
bormand 20.03.2016 07:38 # −15
http://govnokod.ru/19660#comment317196
> таймаут
Ну нету у наглого таймаутов. Либо с того конца подтверждение придёт по предыдущему пакету, либо полный пакет наберётся.
Ты, наверное, про другую фичу - отложенное подтверждение пакетов (delayed tcp ack), когда другой конец не кидает ack сразу, а ждёт 500мс или какого-нибудь попутного пакета. Вот её сочетание с нейглом и write-write-read на сокете скатывает всё в ёбаный диалап.
3_14dar 20.03.2016 21:00 # −15
bormand 20.03.2016 22:09 # −15
А для неё надо:
1) write-write-read в программе
2) nagle на отправляющей стороне
3) delayed ack на принимающей
Вот тогда и получаются те самые "наберётся M байтов (и nagle пропустит ещё пакет) или пройдёт Nмс (и другой конец кинет ack, а nagle пропустит ещё пакет)".
3_14dar 20.03.2016 22:40 # −15
bormand 20.03.2016 22:48 # −15
3_14dar 20.03.2016 23:04 # −15
guest 21.03.2016 23:47 # −15
https://tools.ietf.org/html/rfc896
bormand 22.03.2016 00:51 # −15
Но тут же Нейгл пишет о говнорешении, которое в 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.
guest 22.03.2016 01:29 # −15
bormand 20.03.2016 00:39 # −14
- хост говорит IN (слышь, данные есть?)
- девайс отвечает NAK (пиздит, данные то есть)
- хост с неким интервалом говорит PING (а если найду?)
- девайс на них отвечает NAK (нету, заебал)
- и вдруг через 16мс на один из пингов отвечает ACK (ладно, ладно, есть у меня данные)
- хост кидает IN еще раз (ну давай их сюда)
- девайс кидает DATA
- хост отвечает ACK
bormand 20.03.2016 10:42 # −15
bormand 20.03.2016 10:57 # −15
guest 22.03.2016 01:21 # −15
bormand 22.03.2016 01:38 # −15
kegdan 22.03.2016 05:49 # +2