Rst7

Причем тут UDP? И, кстати, причем тут "самопальный стек"? Это, простите, в чем я "по ушам езжу"? Так все очень просто. Например: АЦП->Контроллер1->Ethernet->Wifi router1->радиоканал->Wifi router2->Ethernet->Контроллер2->ЦАП. Пусть будет 2канала*16бит*48кГц. Надо, чтобы в этой цепочке не было потерь пакетов. Пауза в приходе пакетов, которая вызывает щелчок на выходе - это тоже потеря. Вот основная проблема именно в паузах, причем неконтролируемых. Для борьбы с ними в контроллере2 делается буфер. Минимальный более-менее работоспособный размер его - где-то эквивалентен 5-6мс по времени. А лучше бы все 10, потому что с 5-6 иногда все таки опустошается буфер. Ну а общая latency в таком случае - это задержка от входа АЦП до выхода ЦАП. Со всеми внутренними буферами, понятное дело. Предупреждая всякое "не такой вайфай, не такой эзернет" и прочее: понятное дело, что если кусок Wifi router->радиоканал->Wifi router выбросить, то все становится хорошо. Даже если там включен какой-нибудь свич, ничего страшного не происходит, буферизация требуется, ну на сотню микросекунд, не более. А роутеры в этой цепи проверялись самые разные, в самых разных конфигурациях, в том числе и вместо куска Wifi router2->Ethernet->Контроллер2->ЦАП использовался iPhone (ну только там Ethernet'а нет внутри, но это неважно). Возможно, если бы у меня был голый WiFi MAC/PHY с полной документацией, я бы сделал вариант стека, который не переключался бы в режимы с малой скоростью и не занимался бы какими-то побочными делами. Но таковых нет, дизассемблировать существующие драйвера нет ни времени, ни желания.

А вот пусть этот "самый первый модератор" попробует с WiFi пободаться именно с точки зрения low latency и получить хоть какую-то минимальную цифру. У меня с использованием моднейшего Linksys'а с технологией MU-MIMO в лучшем случае получилась задержка почти 6мс, но это только буферизация входа, а еще ввод-вывод, считайте, что все 7 набегает. Именно так.

Прошу прощения, похоже что конекретно этот девайс - это аналоговый радиоканал. Но все эти FM-передатчики/приемники - то еще барахло. А я про те, которые в таком же формате, но в цифре носят. Вот например - https://aliexpress.ru/item/4000507198259.html На самом деле она 2.4ГГц, а не 760, как написано. Но зато не обманули про латенси.

А еще бы честно указывали, что там 12мс задержки, а не "менее 4мс", и все бы хорошо было.

Я вам вот что скажу. Даже aptX Low Latency не спасет. Там 32мс задержка, это очень много для игры на музыкальном инструменте. Так что Ваши хотелки нереализуемы. Только в виде "свой стационарный передатчик + свой носимый приемник, в который включаются проводные наушники".

Не обязательно. Если собственный шум у локального генератора сильный - то улучшения, естественно, не будет.

В варианте с контроллером, у которого свой MAC внутри - легко получается wire speed. Т.е. чуть меньше чем, например, 100Мбит/с. Со всякими визнетами сильно повезет, если получится перешагнуть 10М. Это Вам надо будет пробовать бодаться с его параллельной шиной, еще неизвестно, сколько там глюков, народ-то в основном его по последовательным портам гоняет (и то матерится). Вам сильно нужны эти эксперименты?

Но зачем? Вы же не сможете ни шага влево, ни шага вправо ступить с ним. Да и обещанные 80М - скорее всего какой-то сферический конь в вакууме.

Та в общем вроде нет особых проблем с приемом. Вот, например, 8 лет назад - там что-то под 500к пакетов в секунду с средней полосой за 4Гбит/с. http://www.serverframework.com/asynchronousevents/2012/08/winsock-registered-io-io-completion-port-performance.html Проблем с записью тоже нет, если обеспечите дисковый массив с подходящей пропускной способностью. Если вдруг чего, то RIO и memory mapped files очень даже хорошо совмещаются, практически имеете полностью zerocopy.

Moderator: Господа, тему вынужден закрыть. Потому что офтопик.

Ну так уже не 2 D-триггера ;) Повторюсь, основная проблема заключается в том, что большинство камней сильно ограничены по максимальной частоте SCK в режиме Slave. Там же вроде 16МГц, что, все так печально? Вроде ж 6 тактов надо на саму пересылку, ну плюс еще тест и цикл. А всего есть 12.8 такта, вроде должно хватить.

Сэмулировать 10M Ethernet. Достаточно имитировать только Normal Link Pulse и все. Линк поднимется, дальше просто посылать UDP-пакеты. Главное, чтобы SPI без дырок между байтами мог данные посылать со скоростью 10М. Либо работать в слейв-режиме с такой скоростью. Из I2S, кстати, хорошо получится. Не хватит двух D-триггеров для декодирования манчестера. Да еще и не в каждом камне SPI умеет в слейв на 10М.

Да. Именно так. Изначально был TCP, потом перешел на UDP, потому что понадобился мультикаст. В общем это непринципиально. Нет. Буфер там у меня размером 32пакета*8семплов_в_пакете*8каналов_в_семпле*32бита=4килобайта. Таких буферов два, потому что в обе стороны. Характерные возможные задержки в Windows, если у Вас более-менее вменяемый компьютер по производительности и сделаны нужные оптимизации, - не более 0.5мс. Оценить эти задержки в конкретно Вашей системе можно при помощи вот этой софтины - https://www.resplendence.com/latencymon Вот мои буфера в самом сложном случае (при частоте дискретизации 192кГц) обеспечивают буферизацию на время порядка 1.3мс, это с приличным запасом.

Это ж только модулятор. У него цифровые выходы.

О, какие фантазии. Как раз IP и TCP - это как раз составляющие Protocol Stack, соответствующие уровням Network и Transport. Это называется Cross-layer optimization. Доступно только профессионалам, которые не используют lwip.

Три же. Или 4 - если по модели OSI. Что, в общем-то, и надо при решении любой задачи. Главное, уважаемый, что Вы у нас - великий несамопальщик.

А почему бы просто не вырезать лишнюю частоту цифровым фильтром прямо уже в цифровом потоке с АЦП? Из-за того, что все частоты (как для ЦАПов, так и для АЦП) Вы генерируете одним и тем же контроллером, можно организовать очень хорошее подавление.

Ну разве что в контексте Ethernet без ARP скучновато ;) Но да, кони-люди, мешаем в кучу все.

Мы же тут исключительно про транспортный уровень и ниже говорим. ТС'у, например, же явно не надо отправлять данные с АЦП в виде HTTP ;) Потому вполне можем говорить о производительности некой "отправлялки пакетов". Тем более, что все остальные потроха - это o(1) в контексте данной задачи.

Так выбросьте свою архитектуру, если она тормозит

Ну это ж уже версия под ARM у меня выложена. Изначально-то было вот так (еще более смешной тред): Хотя, в общем-то, я не претендую на звание самого первого TCP-стека

Длинный и смешной тред. 9 лет назад, черт побери ))) С тех пор воды утекло прилично, цифры, кстати, улучшились.

Прошу прощения, конечно я про checksum.

Это тоже да. Но правильно написанный подсчет CRC занимает примерно 0.6 такта на байт. Итого на 100МГц можно считать со скоростью 1.3Гбит/с ;)

Никакой химии, просто стек - не lwip ;) Я когда-то выкладывал тут вместе с исходниками своего стека измерения скорости/нагрузки, причем TCP. При 100М (ну, точнее 98 с копейками 95424836 бит в секунду, привет inter frame gap) в одну сторону на LPC1768 был где-то 40% CPU load, щас ситуация еще улучшилась, я кое-что подоптимизировал.