В процессе выполнения работы возникла серьезная проблема. Мне нужно запрограммировать ПЛИС так, чтобы она преобразовывала данные, пришедшие по каналу Ethernet в однобитный поток E1. Скорость передачи данных по Ethernet больше, чем по E1, поэтому использую следующую схему: компьютер посылает на ПЛИС N-ое количество пакетов, ПЛИС загоняет их в буфер и начинает передавать по каналу E1. Как только буфер освобождается до определенного уровня, ПЛИС посылает компьютеру запрос, мол я освобождаюсь, давай еще данные, и компьютер шлет еще. Важно чтобы буфер при этом не освобождался и не переполнялся, потому что данные в потоке Е1 должны идти непрерывно и последовательно. Так вот, проблема в том что буфер, скотина этакая, несмотря на размер в 100 Кб все же как-то умудряется освобождаться!!! То есть посылка данных на какое-то время прерывается и за это время буфер успевает освободиться. Парюсь с этим говном уже месяц. Люди если есть какие мысли, подскажите пожалуйста, с чем это может быть связано и как с этим бороться?
Конфигурация следующая: ПЛИС Xilinx XC4VLX20, скорость Ethernet около 10 Мбайт/с, скорость Е1 2 Мбайта/с, данные передаются по UDP, ОС на компе Windows XP, программа для передачи данных написана на C#, комп имеет на борту Core2Duo E8400 3ГГц, 4 Гига DDR2-800 и жесткий диск гигов на 200. Буфер представляет собой FIFO, сгенерированное при помощи Xilinx Core Generator.

Странный у Вас Е1. Раз в 8 быстрее, чем у всех остальных...


Как-то была история - притаскиваю (на другой конец области) программистам железку, подключаемую к компу через Езернет и тестовую программу, написанную на C Builder.
Включаем, запускаем прогу - всё работает.

Уезжаю.

Через 2 недели звонок - приезжай, не работает твоя железка.
Приезжаю (на другой конец области), показывают мне свою красивую программу, написанную на C#, запускают - не работает.
Достаю ноут, подключаю, запускаю свою тестовую программу - работает.

В общем, ихняя красивая программа на C# работала таааааааааак медленно, что поток информации просто не успевала принимать.

Я тоже как-то принимал большой поток данных по 1G Ethernet.
Даже использование С++ Builder'а с вызовом WinAPI Sokeтов не сильно помогало,
пока не применил библиотеку WinPCAP - потери пакетов сразу прекратились.

А в C# гемморой с массивами, т.к. Garbage Collector всё время чистит память, потому указатели на массивы применять нельзя - нужно каждый раз массив копировать целиком - получаются полные тормоза.

Нормальный, как у всех, если память не изменяет.
Зная потенциальную медлительность C#, спрашиваю: изучали латентность вашей программы? Т.е. время между получением (а еще лучше - посылкой )запроса и ответом на запрос.
Хотя, с другой стороны, не должно быть ТАКИХ больших задержек (100кБ - почти 100 мсек)...

На ПЛИС 8 потоков E1 мультиплексируется в один, отсюда и скорость 2 Мбайта/с


Насколько я понимаю, время от времени возникают задержки по 10-15 мс, они в принципе не велики, но регулярны, так что если такая задержка произойдет в то время, когда буфер опустошается и ПЛИС требует еще данных, может произойти полное опустошение буфера.
А windows может быть виноватым в этом безобразии?

А демультиплексор вы тоже делаете? почему бы не передавать IDLE пакет в E1, который будет заполнять паузы при передаче?

поглядите профайлером свой софт.

E1 - 2048 КБит/сек.

вам никто не сможет гарантировать, что буфер не опустошится. это нормальная ситуация, пусть себе по E1 идет поток нулей или последний бит в это время. главное, чтобы на приемном конце логика умела обрабатывать эту ситуацию

Ну почему же? При грамотном подборе размера буфера и порога опустошения снизить вероятность опустошения до приемлемого уровня вполне реально.


Это уже будет не совсем Е1.

А чему противоречит поток нулей по E1 (особенно при HDB3 ) ?

я неделю (любой достаточно большой промежуток времени) не буду слать пакеты и привет


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

Ну будет LOF на приемном конце .


Еще можно провод перерезать .


Ну будет прерывание разговора/трафика у людей.
Ну да, нестрашно. Но разработчика помянут словом матерным .

и что, по вашему это нереальная ситуация? а когда все люди спят/не качают? что, линии ломаются?

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

не могу понять чем GFP не устраивает

так и разбираться надо с задержками и буферами. я как-то и 1 кбайтным буфером обходился (MTU правда уменьшать пришлось)

Я бы отлаживал примерно в такой последовательности -
1. Отладочный пин на признак опустошения FIFO.
2. Отладочный пин на признак получения пакета по.
3. Осцилограф на отладочные пины.
Настраиваем осцилограф на событие - признак опустошения FIFO. Смотрим как в это время принимаются пакеты. Соответственно два возможных варианта -
1. Перебоев с принятием пакетов нет - ковыряем проект ПЛИС (отбраковка битых пакетов ?; косяки при перезаписи из, в FIFO; ...) .
2. Видны перебои с поступлением UDP пакетов ковыряем ПО (анализаторы трафика, временные задержки программы, ...).

Ага... знаем мы такое
Когда жалобы достигнут критического уровня - придется разгребать
все это и ох как быстро придется это делать...

К тому-же 8xE1 - аппаратура серьезная... еще и сертификацию пройти надо,
в том числе и по количеству ошибок и пр.
Что-то непродумано у топик стартера с идеологией. Делал карту PCI-4xE1,
ставил 2-х портовку с двойной буферизацией... накапливал 8 фреймов,
дергал прерывание, переключал банк памяти и т.д.