Rst7
-
Постов
4 619 -
Зарегистрирован
-
Победитель дней
2
Сообщения, опубликованные Rst7
-
-
4 hours ago, Давид said:
Добрый вечер! А мысль самого первого модератора про какой-то Wi-Fi модуль, тоже нереально? Какая задержка подходит для нашего случая?
А вот пусть этот "самый первый модератор" попробует с WiFi пободаться именно с точки зрения low latency и получить хоть какую-то минимальную цифру. У меня с использованием моднейшего Linksys'а с технологией MU-MIMO в лучшем случае получилась задержка почти 6мс, но это только буферизация входа, а еще ввод-вывод, считайте, что все 7 набегает.
Spoiler
Это типа такой вот.
4 hours ago, Давид said:На сколько я понимаю, Вы хотите сказать, что Bluetooth интерфейс в моей проблема не поможет решить задачу, т.к. он имеет большую задержку даже с учетом лучших кодеков ( apt-x и т.д.)
Именно так.
-
3 hours ago, borodach said:
а откуда там 12мс? Наверняка труЪ аналоговый радиоканал.
Прошу прощения, похоже что конекретно этот девайс - это аналоговый радиоканал. Но все эти FM-передатчики/приемники - то еще барахло.
А я про те, которые в таком же формате, но в цифре носят. Вот например - https://aliexpress.ru/item/4000507198259.html
На самом деле она 2.4ГГц, а не 760, как написано. Но зато не обманули про латенси.
-
1 hour ago, borodach said:
кто-то почестнее указывает более скромный частотный диапазон, типа 65Гц-14кГц
А еще бы честно указывали, что там 12мс задержки, а не "менее 4мс", и все бы хорошо было.
-
Я вам вот что скажу. Даже aptX Low Latency не спасет. Там 32мс задержка, это очень много для игры на музыкальном инструменте.
Так что Ваши хотелки нереализуемы. Только в виде "свой стационарный передатчик + свой носимый приемник, в который включаются проводные наушники".
-
Не обязательно. Если собственный шум у локального генератора сильный - то улучшения, естественно, не будет.
-
10 hours ago, Nikkolaj said:
Какую скорость можно получить в каждом из этих вариантов?
В варианте с контроллером, у которого свой MAC внутри - легко получается wire speed. Т.е. чуть меньше чем, например, 100Мбит/с.
Со всякими визнетами сильно повезет, если получится перешагнуть 10М. Это Вам надо будет пробовать бодаться с его параллельной шиной, еще неизвестно, сколько там глюков, народ-то в основном его по последовательным портам гоняет (и то матерится). Вам сильно нужны эти эксперименты?
-
17 minutes ago, Nikkolaj said:
Рассматриваю вариант применения внешнего контроллера Ethernet, пока остановился на W5300.
Но зачем? Вы же не сможете ни шага влево, ни шага вправо ступить с ним. Да и обещанные 80М - скорее всего какой-то сферический конь в вакууме.
-
Та в общем вроде нет особых проблем с приемом.
Вот, например, 8 лет назад - там что-то под 500к пакетов в секунду с средней полосой за 4Гбит/с.
Проблем с записью тоже нет, если обеспечите дисковый массив с подходящей пропускной способностью. Если вдруг чего, то RIO и memory mapped files очень даже хорошо совмещаются, практически имеете полностью zerocopy.
-
Moderator: Господа, тему вынужден закрыть. Потому что офтопик.
-
Just now, _pv said:
Хватит, с детектором фронтов на XOR, и с задержкой на 1.5 такта на RC цепочке.
Ну так уже не 2 D-триггера ;)
Повторюсь, основная проблема заключается в том, что большинство камней сильно ограничены по максимальной частоте SCK в режиме Slave.
5 minutes ago, _pv said:так как он на приёме ничего кроме
while(1) *data++=SPIRXBUFF;
делать не успевал
Там же вроде 16МГц, что, все так печально? Вроде ж 6 тактов надо на саму пересылку, ну плюс еще тест и цикл. А всего есть 12.8 такта, вроде должно хватить.
-
25 minutes ago, jcxz said:
Объясните как SPI подключить к ПК?
Сэмулировать 10M Ethernet. Достаточно имитировать только Normal Link Pulse и все. Линк поднимется, дальше просто посылать UDP-пакеты. Главное, чтобы SPI без дырок между байтами мог данные посылать со скоростью 10М. Либо работать в слейв-режиме с такой скоростью. Из I2S, кстати, хорошо получится.
43 minutes ago, _pv said:И только на выход, на вход ещё пара D триггеров нужна для декодера.
Не хватит двух D-триггеров для декодирования манчестера. Да еще и не в каждом камне SPI умеет в слейв на 10М.
-
42 minutes ago, Nikkolaj said:
Правильно ли я понял, что у Вас на плате стоял контроллер LPC4078 с внутренним Ethernet и внешним PHY на 100Мбит.
И каждая такая плата обеспечивала поток чистых данных 50 Мбит/с.
Да. Именно так.
42 minutes ago, Nikkolaj said:Протокол передачи у Вас был ТСР?
Изначально был TCP, потом перешел на UDP, потому что понадобился мультикаст. В общем это непринципиально.
42 minutes ago, Nikkolaj said:Внешнюю память для организации буфера Вы применяли?
Нет. Буфер там у меня размером 32пакета*8семплов_в_пакете*8каналов_в_семпле*32бита=4килобайта. Таких буферов два, потому что в обе стороны.
42 minutes ago, Nikkolaj said:Объясните пожалуйста, что такое "характерные доп. буфера на 0,5мс" и где они находятся.
Характерные возможные задержки в Windows, если у Вас более-менее вменяемый компьютер по производительности и сделаны нужные оптимизации, - не более 0.5мс.
Оценить эти задержки в конкретно Вашей системе можно при помощи вот этой софтины - https://www.resplendence.com/latencymon
Вот мои буфера в самом сложном случае (при частоте дискретизации 192кГц) обеспечивают буферизацию на время порядка 1.3мс, это с приличным запасом.
-
10 minutes ago, blackfin said:
Это ж только модулятор. У него цифровые выходы.
-
6 minutes ago, AlexandrY said:
IP и TCP не уровни стека, а протоколы.
О, какие фантазии. Как раз IP и TCP - это как раз составляющие Protocol Stack, соответствующие уровням Network и Transport.
12 minutes ago, AlexandrY said:Ну а чем вы занимаетесь как не изобретением велосипеда?
Это называется Cross-layer optimization. Доступно только профессионалам, которые не используют lwip.
-
Just now, AlexandrY said:
Стек он и есть стек, т.е.программные интерфейсы между уровнями OSI. Два уровня - это не стек.
Три же. Или 4 - если по модели OSI.
Just now, AlexandrY said:сэкономить свое и процессорное время.
Что, в общем-то, и надо при решении любой задачи.
2 minutes ago, AlexandrY said:самопальщики
Главное, уважаемый, что Вы у нас - великий несамопальщик.
-
On 2/22/2020 at 5:28 PM, Xenia said:
Дано: Контроллер генерит своими двумя ЦАПами две гармоники - одну с частотой 153.0 КГц, другую с частотой 153.6 КГц, одинаковой амплитуды. Сами частоты могу сдвигать на 10-20% в любую сторону, но разность между ними в 600 Гц должна соблюдаться жестко и пересмотру не подлежит. Обе частоты суммируются на резисторном делителе и поступают в виде суммы на АЦП того же контроллера.
Вопрос: Как собрать фильтр, располагаемый перед входом на АЦП, чтобы задавить одну из частот в суммарном сигнале? Было было бы достаточно, если бы после фильтра амплитуды этих гармоник отличались не менее, чем в 20 раз. Или, другими словами подавленная гармоника не превышала 5% в суммарном сигнале.
А почему бы просто не вырезать лишнюю частоту цифровым фильтром прямо уже в цифровом потоке с АЦП? Из-за того, что все частоты (как для ЦАПов, так и для АЦП) Вы генерируете одним и тем же контроллером, можно организовать очень хорошее подавление.
-
Just now, blackfin said:
без которых формально TCP/IP вполне может работать..
Ну разве что в контексте Ethernet без ARP скучновато ;) Но да, кони-люди, мешаем в кучу все.
-
14 minutes ago, AlexandrY said:
А главное, стек ли это на самом деле? Т.е. реализованы ли там интефейсы стека, чтобы был ARP, DHCP, NAT, PPP, SNMP, DNS, HTTP, TELNET, FTP и т.д.
Just now, AlexandrY said:а у вас как понимаю не стек, а некая отправлялка TCP пакетов.
Мы же тут исключительно про транспортный уровень и ниже говорим. ТС'у, например, же явно не надо отправлять данные с АЦП в виде HTTP ;) Потому вполне можем говорить о производительности некой "отправлялки пакетов". Тем более, что все остальные потроха - это o(1) в контексте данной задачи.
-
4 minutes ago, AlexandrY said:
Архитектура тормозит в основном.
Так выбросьте свою архитектуру, если она тормозит
-
14 minutes ago, blackfin said:
Вах! Я свой стек под VDK написал шестью годами раньше..
Ну это ж уже версия под ARM у меня выложена. Изначально-то было вот так (еще более смешной тред):
Хотя, в общем-то, я не претендую на звание самого первого TCP-стека
-
13 minutes ago, dimka76 said:
А можно ссылку на этот пост.
Длинный и смешной тред. 9 лет назад, черт побери ))) С тех пор воды утекло прилично, цифры, кстати, улучшились.
-
1 minute ago, blackfin said:
В протоколе UDP CRC вообще не считается.. :)
Прошу прощения, конечно я про checksum.
-
2 minutes ago, blackfin said:
Протокол UDP не требует проверки контрольной суммы UDP пакета, если в поле контрольной суммы пакета поставить нуль.
Это тоже да. Но правильно написанный подсчет CRC занимает примерно 0.6 такта на байт. Итого на 100МГц можно считать со скоростью 1.3Гбит/с ;)
-
12 minutes ago, AlexandrY said:
25% на UDP?
Слишком оптимистично.
Какая-то химия с пакетами значит была.Никакой химии, просто стек - не lwip ;) Я когда-то выкладывал тут вместе с исходниками своего стека измерения скорости/нагрузки, причем TCP. При 100М (ну, точнее
98 с копейками95424836 бит в секунду, привет inter frame gap) в одну сторону на LPC1768 был где-то 40% CPU load, щас ситуация еще улучшилась, я кое-что подоптимизировал.
Помощь в поиске или разработке передающего устройства
в Предлагаю работу
Опубликовано · Пожаловаться
Причем тут 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 с полной документацией, я бы сделал вариант стека, который не переключался бы в режимы с малой скоростью и не занимался бы какими-то побочными делами. Но таковых нет, дизассемблировать существующие драйвера нет ни времени, ни желания.