Benchmark для транспорта/бэкэнда x11

Хочется проверить

но что-то мешает? О_о

Разрешения, видимо, не хватает.

Ну что ж, я разрешаю.

лэйтенси меньше чем среднестатистический интернет
удалённый доступ к нему

не знаю протокола который поддерживает сжатие пространственно-временного континуума =)

Я думаю что он хотел, для начала спросить, может кто ещё подобное делал. Или выскажет свой личный опыт.

Да и тестировать не надо, самый быстрый(в указанном смысле) вариант - X сервер на реальной карте. Ну и доступ через x11vnc например.

Зачем вредить себе, выслушивая «опыт» случайных шизиков?

Хотелось бы готовый бенчмарк, типа phoronix, ибо наживую - долго.

не знаю

Ещё, походу, и читать не умею.

Пруфца бы или аргументации хоть...

Аргументация: никакие запросы программы к X серверу не ходят через сеть, отрисовка кое-где ускорена аппаратно, последнее почти недостижимо при использовании «виртуальных» X серверов(Xvnc и т.п.).

Будет ли это наилучший в целом, приятный в пользовании вариант - это отдельный вопрос, зависит от некоторого количества нюансов.

Я активно пользуюсь сетевой прозрачностью, в основном через форвардинг. X синхронный протокол, и даже самые незначительные задержки могут очень замедлить отрисовку или отзывчивость.

читать умею.

к времени разморозки UI добавится RTT канала. так что ты не получишь «лэйтенси меньше чем среднестатистический интернет»

Ну, с тем же ffmpeg - получу, хоть и рид-онли например. Или ты думаешь, что все идиоты и никто не придумал троттлинг для той же отрисовки? С вводом выводом по идее ещё проще - сотней миллисекунд раньше/позже никто не должен заметить.

Мне не нужен лэйтенси для «действие на ui-> бизнесс логика»(как в игрушках) мне нужен лэйтенси на «бизнесс логика -> локальная сеть».

Меня интересует не отзывчивость ui, а отзывчивость бизнес логики, которая блокируется на отрисовках. Т.е. отрисовки должны быть либо асинхронные либо троттлиться.

отзывчивость бизнес логики, которая блокируется на отрисовках.

ты все перепутал. UI работает в главном потоке, если из этого потока делается синхронный вызов кода БЛ, то блокируется UI на БЛ. а не БЛ на UI как ты описал.

Есть X11 приложение, где плохо развязана бизнес логика и блокировки на ui

это ни каким ремоут протоколом не исправишь.

Главный поток наше всё.

Если у кого-то Qt головного мозга, то это не исправить.

GTK работает как-то иначе?

Тут скорее вопрос в том, кто чаще говорит про главные потоки и главные циклы обработки событий. В Qt порог вхождения ниже, соответственно - знатоков больше.

На самом деле - сказать, что ты прям не прав, тоже будет неверно.

Но понятие «главного» потока становится слегка размытым когда в приложении запущенны 2 и более цикла обработки событий от разных источников.

По сути, в текущей поделке например есть поток гоняющий пользовательский luajit код в коллбэках от событий сети(с rtt < 1ms). И «главный» - скорее он:) Соль в том, что при удалённом доступе задержка во времени доставки сообщений в этот код вырастает до сотен миллисекунд, чего хотелось бы избежать. Не исключено, что приложение написано действительно супер криво, и сетевой код крутится в одной очереди с ui(как всякие QTcpServer по умолчанию). Тогда - действительно ничего не поделать.

Оно не размыто. Главным потоком именуется поток выполняющий отрисовку интерфейса, в него же идут сообщения от устройств ввода - клава, мышь, тачскрин. Ладно, фик с ними, с определениями)

Мне вот что не понятно: vnc и rdp же тупо скриншоты экрана отсылают клиенту, каким образом это сказывается на потоке с луаскриптами. Пусть даже они выполняются в одном треде с отрисовкой, иксы же рисуют там где приложение, а не в сеть.

Я пока пробовал только x11 forward и это привнесло нехилые издержки. Вот я и спросил что-бы всё подряд не пробовать ибо пиковая нагрузка, когда заметна разница случается редко и нет дешёвого способа её воссоздать.