1. Си / Говнокод #19660

    −49

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 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);
        }
    }

    Я люблю FTDI!

    FT245BL соглашается на bulk transfer либо если в буфере накопилось 62 байта, либо если прошло 16мс с последнего трансфера. В итоге, за секунду пролезает не больше 60 мелких пакетов (размером меньше 62 байт)... Даже сраные диалап модемы работали быстрее.

    Запостил: bormand, 19 Марта 2016

    Комментарии (52) RSS

    • показать все, что скрытоЗ.Ы. Можно уломать её на таймаут в 1мс, но это не особо помогает. Получается 1 мегабит вместо теоретических (и практических, если гнать сплошной поток) 8.
      Ответить
      • показать все, что скрытоа нельзя собрать МНОГО пакетов и сделать балк?

        Может они проосто не хотят балк гонять ради двух байт?
        Ответить
        • показать все, что скрытоДа можно, но это усложнит интерфейс... Вместо простого и понятного jtag_shift_dr, который сразу отдаёт ответ, будет какая-нибудь асинхронная хуета с коллбеками или очередями... Брр...

          Проще выровнять на 62 ;)
          Ответить
    • показать все, что скрытоАлгоритм Нагла? Что не так-то? Алсо, магическая константа.
      Ответить
      • показать все, что скрытоНе так, что у чипа нету команды чтобы принудительно зафлушить буфер.
        Ответить
        • показать все, что скрытотак то не код говно а FTDI говно
          Ответить
        • показать все, что скрытоА зачем его флушить-то? Сри побольше - он сам зафлушится.
          Ответить
          • показать все, что скрытоНу не могу я срать побольше. Мне интерактивный протокол надо сделать поверх этого транспорта... Кинул запрос, подождал ответ.

            Вот и пришлось добавлять байты до кратного 62, чтобы ответа не ждать целых 16мс.
            Ответить
            • показать все, что скрытом-да

              видал я протоколы где надо было выравнивать запрос по 2^N байтов, но чтоб 62 это впервые
              Ответить
              • показать все, что скрытоА всё просто - трансферы идут по 64 байта. Но джва первых заняты под флажки со статусом. Вот и остаётся 62 под данные.
                Ответить
              • показать все, что скрытоСамая жопа в том, что этот буфер с той стороны кабеля. Не со стороны компа. Т.е. надо уломать железку за ftdi (в данном случае cpld байтбластера) высрать в буфер что-то кратное 62...

                Благо число байт в её ответе можно легко предсказать и пустых команд на чтение накидать, которые 1 байт отправляют в ответ...
                Ответить
            • показать все, что скрытоАх, так тебе интерактивный надо... А не bulk transfer есть?
              Ответить
              • показать все, что скрытоНу вроде как этот чип ещё умеет изохронный трансфер (грубо говоря поток с равномерной скоростью и гарантией на тайминги). Но там гарантии доставки не будет, что совсем не айс.
                Ответить
              • показать все, что скрытоА вообще в усб их 4 типа:
                control - для небольших команд (настройки и т.п.)
                interrupt - мелкие, но критичные к задержкам пакеты от железки (клавы, мыши и т.п.)
                isochronous - выделенная полоса для всяких видео и звуков
                bulk - с гарантированной доставкой но без гарантий по таймингам (флешки, принтеры и т.п.)
                Ответить
                • показать все, что скрытоКстати, почему через usb работа с кучей мелких файлов такая медленная?

                  Если подключить винт и сетевуху через один хаб, может ли лагать сеть если канал заполнен диском и наоборот?

                  может ли лагать клава/мышь из-за перегрузки канала?
                  Ответить
                  • показать все, что скрыто> работа с кучей мелких файлов такая медленная
                    Ты про запись же? Это вендопроблема, емнип. Венда пытается спасти долбоёбов, выдирающих флешки без размонтирования, вот и флашит всё на каждый чих. Попробуй галочку переключить (диспетчер устройств, свойства флешки, быстрое извлечение vs пирфоманс).

                    > может ли лагать сеть
                    Да, USB сетевухи тоже через bulk работают.

                    > может ли лагать клава/мышь
                    Нет. У interrupt высший приоритет.
                    Ответить
                    • > долбоёбов, выдирающих флешки без размонтирования
                      Как грубо!

                      Кстати, Windows пытается спасти ещё и тех простофиль, которые посмели не перезагружая компьютера подключить мышь, какой позор, на костёр их срочно!
                      P. S. А ведь USB на аппаратном уровне штекера поддерживает быстрое вытыкание.
                      Ответить
                      • >> вытыкание

                        во-первых это слово выдуманное от вытыкать
                        во-вторых вытыкать - это выкалывать. Глаз выткнул

                        по этому не соглашусь - USB на аппаратном уровне штекера не поддерживает быстрое вытыкание.
                        Толи Jack 6.2...
                        Ответить
                      • показать все, что скрыто> на аппаратном уровне
                        Ага. Устройство просто не сгорает от выдирания (хотя могло бы, если бы создатели USB этот момент не продумали).
                        Ответить
                        • Но ведь продумали же! И самолёты продумали.
                          Да, там неканон, здесь неканон, просто к остальному уже привыкли. Если делать всё правильно и по задумке природы, можно на всю жизнь остаться кучкой хаотично движущихся молекул.
                          Ответить
                          • ЭээЧЕЛОВЕК МАЛЕКУЛА!!!! Я не смог побороть искушение, простите
                            Ответить
                      • показать все, что скрытоиспользуй Media Transfer Protocol

                        Там единицей передачи является файл, должно лучше работать
                        Ответить
                    • показать все, что скрытоЯ не про ту галочку. Она медленнее чем для встроенного (ide/sata) даже для винта.
                      Ответить
            • То ли дело LPT порт, где такой хуйни нет
              Ответить
      • показать все, что скрытоАлгоритм Нагла позволяет не слать сегмент TCP если не получено подвтерждение для кучи уже отосланных сегментов

        а эта железка завязывается не на конфирмейшены, а на размер буфера или на время (почему-то)

        Так что ты видимо хотел выпендриться своим знанием TCP, но потерпел крах
        Ответить
        • показать все, что скрыто> почему-то
          Полосу USB экономить пытались. Но как-то криво, имхо. Лучше бы кидали NAK при пустом буфере да и всё.
          Ответить
          • показать все, что скрытоа еще лучше сделали бы интерфейс для flush или commit или sync, как это лучше назвать не знаю
            Ответить
            • показать все, что скрытоДа она может и есть... Просто эти пидоры из FTDI спеку на протокол не хотят давать без NDA... Типа вот вам дллка с закрытым кодом, жрите что дают.

              А в опенсурсной версии (видимо, отреверсили) я flush не заметил.
              Ответить
              • показать все, что скрытону так ты сам виноват что реверс инженерную дрянь взял
                бери нормальное и будет все работать

                это всё равно что взять самбу, и сказать "говно этот ваш Active Directory, ничерта не умеет"
                Ответить
                • показать все, что скрыто> реверс инженерную дрянь
                  Ты думаешь, что официальная либа лучше работает? Да хуй там.

                  > бери нормальное
                  Да я сам уже написал. И тот читерский паддинг до 62 байт дал 4000 write-read транзакций за секунду против 60-500 у штатной.
                  Ответить
        • показать все, что скрытоАлгоритм нагла делает то что делает железка. Гость, снова ты перданул в лужу. Сколько уже можно?
          Ответить
          • показать все, что скрытоНе совсем. Наглый пропускает первый пакет, задерживая второй, пока не придёт подтверждение или не накопится достаточно байтов.

            А тут и первый пакет задерживается.
            Ответить
            • показать все, что скрыто>не накопится достаточно байтов
              Это ведь и есть твоя проблема?

              Гость, ты уже понял что обосрался?
              Ответить
              • показать все, что скрытоДа нет же. Наглый вполне так пропускает первый пакет, даже если он 1 байт. А остальные держит.

                А эту железку явно просят отдать данные, а она жмотится и делает вид, что нихуя нету, пока таймаут не пройдёт.

                З.Ы. В усб принципы немного другие. Железка ничего не может отправить, пока хост не попросит. Ну и подтверждение идёт сразу за пакетом. Поэтому никаких наглов тут не замутишь ;)
                Ответить
                • показать все, что скрытоИ при этом хост один хуй пингует железку весь этот таймаут, пытаясь выпросить данные... Там по-моему на эти пинги больше полосы ушло, чем на передачу этого сраного байта...
                  Ответить
                • показать все, что скрытоЧто значит "просят отдать данные"? Нэйгл не отдает пакет, пока не наберется х байт или не пройдет таймаут. У тебя же то же самое.
                  Ответить
                  • показать все, что скрыто> Что значит "просят отдать данные"?
                    http://govnokod.ru/19660#comment317196

                    > таймаут
                    Ну нету у наглого таймаутов. Либо с того конца подтверждение придёт по предыдущему пакету, либо полный пакет наберётся.

                    Ты, наверное, про другую фичу - отложенное подтверждение пакетов (delayed tcp ack), когда другой конец не кидает ack сразу, а ждёт 500мс или какого-нибудь попутного пакета. Вот её сочетание с нейглом и write-write-read на сокете скатывает всё в ёбаный диалап.
                    Ответить
                    • показать все, что скрытоДа нет, я где-то читал именно про слияние при отправке, когда (на винде) отправляется когда или наберется x байтов, или по прошествии 300 мс.
                      Ответить
                      • показать все, что скрытоТы, наверное, читал как раз про проблему в целом. А потом подробности забыл и приписал всё это наглому...

                        А для неё надо:
                        1) write-write-read в программе
                        2) nagle на отправляющей стороне
                        3) delayed ack на принимающей

                        Вот тогда и получаются те самые "наберётся M байтов (и nagle пропустит ещё пакет) или пройдёт Nмс (и другой конец кинет ack, а nagle пропустит ещё пакет)".
                        Ответить
                        • показать все, что скрытоТам был именно четко таймаут прописан.
                          Ответить
                          • показать все, что скрытоНу кидай ссылку, чо. Мне такие описания нэйгла не попадались.
                            Ответить
                            • показать все, что скрытоЕсли б она у меня была. Я это читал когда вышел sc2 который юзал tcp
                              Ответить
                            • показать все, что скрытоА вот и ссылка
                              https://tools.ietf.org/html/rfc896
                              Ответить
                              • показать все, что скрытоТы вот про это? This classic problem is well-known and was first addressed in the Tymnet network in the late 1960s. The solution used there was to impose a limit on the count of datagrams generated per unit time. This limit was enforced by delaying transmission of small packets until a short (200-500ms) time had elapsed, in hope that another character or two would become available for addition to the same packet before the timer ran out.

                                Но тут же Нейгл пишет о говнорешении, которое в 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.
                                Ответить
              • показать все, что скрытоС tcp тут вообще мало общего. Как-то так, если спуститься на самые нижние уровни усб:
                - хост говорит IN (слышь, данные есть?)
                - девайс отвечает NAK (пиздит, данные то есть)
                - хост с неким интервалом говорит PING (а если найду?)
                - девайс на них отвечает NAK (нету, заебал)
                - и вдруг через 16мс на один из пингов отвечает ACK (ладно, ладно, есть у меня данные)
                - хост кидает IN еще раз (ну давай их сюда)
                - девайс кидает DATA
                - хост отвечает ACK
                Ответить

    Добавить комментарий