Jump to content

    

Rst7

Модераторы
  • Content Count

    4485
  • Joined

  • Last visited

Everything posted by Rst7


  1. Не обязательно. Если собственный шум у локального генератора сильный - то улучшения, естественно, не будет.
  2. В варианте с контроллером, у которого свой MAC внутри - легко получается wire speed. Т.е. чуть меньше чем, например, 100Мбит/с. Со всякими визнетами сильно повезет, если получится перешагнуть 10М. Это Вам надо будет пробовать бодаться с его параллельной шиной, еще неизвестно, сколько там глюков, народ-то в основном его по последовательным портам гоняет (и то матерится). Вам сильно нужны эти эксперименты?
  3. Но зачем? Вы же не сможете ни шага влево, ни шага вправо ступить с ним. Да и обещанные 80М - скорее всего какой-то сферический конь в вакууме.
  4. Та в общем вроде нет особых проблем с приемом. Вот, например, 8 лет назад - там что-то под 500к пакетов в секунду с средней полосой за 4Гбит/с. http://www.serverframework.com/asynchronousevents/2012/08/winsock-registered-io-io-completion-port-performance.html Проблем с записью тоже нет, если обеспечите дисковый массив с подходящей пропускной способностью. Если вдруг чего, то RIO и memory mapped files очень даже хорошо совмещаются, практически имеете полностью zerocopy.
  5. Moderator: Господа, тему вынужден закрыть. Потому что офтопик.
  6. Ну так уже не 2 D-триггера ;) Повторюсь, основная проблема заключается в том, что большинство камней сильно ограничены по максимальной частоте SCK в режиме Slave. Там же вроде 16МГц, что, все так печально? Вроде ж 6 тактов надо на саму пересылку, ну плюс еще тест и цикл. А всего есть 12.8 такта, вроде должно хватить.
  7. Сэмулировать 10M Ethernet. Достаточно имитировать только Normal Link Pulse и все. Линк поднимется, дальше просто посылать UDP-пакеты. Главное, чтобы SPI без дырок между байтами мог данные посылать со скоростью 10М. Либо работать в слейв-режиме с такой скоростью. Из I2S, кстати, хорошо получится. Не хватит двух D-триггеров для декодирования манчестера. Да еще и не в каждом камне SPI умеет в слейв на 10М.
  8. Да. Именно так. Изначально был TCP, потом перешел на UDP, потому что понадобился мультикаст. В общем это непринципиально. Нет. Буфер там у меня размером 32пакета*8семплов_в_пакете*8каналов_в_семпле*32бита=4килобайта. Таких буферов два, потому что в обе стороны. Характерные возможные задержки в Windows, если у Вас более-менее вменяемый компьютер по производительности и сделаны нужные оптимизации, - не более 0.5мс. Оценить эти задержки в конкретно Вашей системе можно при помощи вот этой софтины - https://www.resplendence.com/latencymon Вот мои буфера в самом сложном случае (при частоте дискретизации 192кГц) обеспечивают буферизацию на время порядка 1.3мс, это с приличным запасом.
  9. Тут для целей контроля аудио-АЦП понадобился генератор 1кГц с малыми искажениями. Малыми - это, скажем, хотелось бы порядка -140dBc в полосе 20Гц-20кГц при уровне выхода, ну, скажем, 2В RMS. В принципе в гугле вроде не забанили, и кое-что попадается на глаза, но все это вокруг обильно полито и сдобрено аудиофильскими угарами, потому хочется консультаций у настоящих профессионалов. Посоветуйте - или как построить такой генератор, или где купить за вменяемые деньги. И если строить самому - то как объективно оценить его параметры. Бумаг с печатями по метрологии не нужно, нужна собственная чистая совесть ;) И да, желаемые -140dBc - это вполне нормальная ситуация. Шум самого АЦП порядка -120дБ в полосе 20кГц (а A-weighted еще лучше), но еще хотелось бы адекватно оценить уровень второй и третьей гармоники.
  10. Это ж только модулятор. У него цифровые выходы.
  11. О, какие фантазии. Как раз IP и TCP - это как раз составляющие Protocol Stack, соответствующие уровням Network и Transport. Это называется Cross-layer optimization. Доступно только профессионалам, которые не используют lwip.
  12. Три же. Или 4 - если по модели OSI. Что, в общем-то, и надо при решении любой задачи. Главное, уважаемый, что Вы у нас - великий несамопальщик.
  13. А почему бы просто не вырезать лишнюю частоту цифровым фильтром прямо уже в цифровом потоке с АЦП? Из-за того, что все частоты (как для ЦАПов, так и для АЦП) Вы генерируете одним и тем же контроллером, можно организовать очень хорошее подавление.
  14. Ну разве что в контексте Ethernet без ARP скучновато ;) Но да, кони-люди, мешаем в кучу все.
  15. Мы же тут исключительно про транспортный уровень и ниже говорим. ТС'у, например, же явно не надо отправлять данные с АЦП в виде HTTP ;) Потому вполне можем говорить о производительности некой "отправлялки пакетов". Тем более, что все остальные потроха - это o(1) в контексте данной задачи.
  16. Так выбросьте свою архитектуру, если она тормозит
  17. Ну это ж уже версия под ARM у меня выложена. Изначально-то было вот так (еще более смешной тред): Хотя, в общем-то, я не претендую на звание самого первого TCP-стека
  18. Длинный и смешной тред. 9 лет назад, черт побери ))) С тех пор воды утекло прилично, цифры, кстати, улучшились.
  19. Прошу прощения, конечно я про checksum.
  20. Это тоже да. Но правильно написанный подсчет CRC занимает примерно 0.6 такта на байт. Итого на 100МГц можно считать со скоростью 1.3Гбит/с ;)
  21. Никакой химии, просто стек - не lwip ;) Я когда-то выкладывал тут вместе с исходниками своего стека измерения скорости/нагрузки, причем TCP. При 100М (ну, точнее 98 с копейками 95424836 бит в секунду, привет inter frame gap) в одну сторону на LPC1768 был где-то 40% CPU load, щас ситуация еще улучшилась, я кое-что подоптимизировал.
  22. Вы ошибаетесь. Ник ТС'а - Nikkolaj Ник в Вашей цитате - dimka76
  23. Ну Вы же меня цитируете, а не ТС, я и отвечаю :))) Если говорить конкретно про задачу ТС'а, то ответы на вопросы 1 и 3 я ему дал (ладно, уговорили, в формате самопиара ;) ). К сожалению, раз ТС задает вопрос 2, то он не в курсе дела от слова вообще, и боюсь, что неважно, какую платформу он возьмет, все равно за три дня не реализует.
  24. Изначально был вообще LPC1768. Зачем там напрягаться, если CPU Load получается примерно 25%? Да примерно такая же диаграмма и в TCP, ну чуть сложнее. Когда один раз сам написал TCP, то уже ничего не изобретаешь, делаешь примерно то же самое ;)
  25. Не, изначально фраза про "это соответствует RFC ... ?", которую Вы процитировали - она в контексте поведения TCP. А то, что я потом на UDP перешел - то отдельная история. И да, протокол поверх UDP у меня получился как нечто напоминающее RDP/RUDP, но как бы любой протокол, в котором есть SEQ/ACK будет напоминать TCP и производные.