[blackfin 14]

1 minute ago, Rst7 said:

И да, протокол поверх UDP у меня получился как нечто напоминающее RDP/RUDP, но как бы любой протокол, в котором есть SEQ/ACK будет напоминать TCP и производные.

Тут, КМК, важно то, что в RFC908 приведена диаграмма состояний КА. Это чтобы не изобретать велосипед..

[AlexandrY 2]

57 minutes ago, Rst7 said:

8 каналов по 32 бита с частотой дискретизации 192кГц. Поток чуть меньше, чем у Вас (примерно 50Мбит/с чистых данных, брутто - повыше, чуть больше 60). Причем, в обе стороны. Сделано на LPC4078 со стомегабитным подключением. Несколько таких плат включено в тупой дешевый 1G свич, и уже он гигабитным линком включен в комп.

Напряглись небось изо всех сил. 
Явно LPC4078 был тут неуместен.
Надо было брать процессор мегагерц хотя бы на 300.
 

[Rst7 5]

Just now, AlexandrY said:

Напряглись небось изо всех сил. 
Явно LPC4078 был тут неуместен.

Изначально был вообще LPC1768. Зачем там напрягаться, если CPU Load получается примерно 25%?

Just now, blackfin said:

Тут, КМК, важно то, что в RFC908 приведена диаграмма состояний КА. Это чтобы не изобретать велосипед..

Да примерно такая же диаграмма и в TCP, ну чуть сложнее. Когда один раз сам написал TCP, то уже ничего не изобретаешь, делаешь примерно то же самое ;)

[blackfin 14]

1 minute ago, Rst7 said:

Когда один раз сам написал TCP, то уже ничего не изобретаешь, делаешь примерно то же самое ;)

Речь же не про вас, а про задачу ТС.. Если, конечно, есть желание ему помочь, а не просто попиариться.. :)

[Rst7 5]

5 minutes ago, blackfin said:

Речь же не про вас, а про задачу ТС..

Ну Вы же меня цитируете, а не ТС, я и отвечаю :)))

Если говорить конкретно про задачу ТС'а, то ответы на вопросы 1 и 3 я ему дал (ладно, уговорили, в формате самопиара ;) ). К сожалению, раз ТС задает вопрос 2, то он не в курсе дела от слова вообще, и боюсь, что неважно, какую платформу он возьмет, все равно за три дня не реализует.

[blackfin 14]

4 minutes ago, Rst7 said:

Ну Вы же меня цитируете, а не ТС, я и отвечаю

Жульничаете!.. :)

Я цитировал именно ТС: link

[dimka76 42]

1 minute ago, blackfin said:

Я цитировал именно ТС: link

Ваша ссылка на мое сообщение ))

А я не ТС )))

[Rst7 5]

Just now, blackfin said:

Я цитировал именно ТС: link

Вы ошибаетесь. Ник ТС'а - Nikkolaj

Ник в Вашей цитате - dimka76

 

[blackfin 14]

1 minute ago, Rst7 said:

Вы ошибаетесь. Ник ТС'а - Nikkolaj

Ник в Вашей цитате - dimka76

 

OK.

[AlexandrY 2]

19 minutes ago, Rst7 said:

Изначально был вообще LPC1768. Зачем там напрягаться, если CPU Load получается примерно 25%?

Да примерно такая же диаграмма и в TCP, ну чуть сложнее. Когда один раз сам написал TCP, то уже ничего не изобретаешь, делаешь примерно то же самое ;)

25% на UDP? 
Слишком оптимистично.
Какая-то химия с пакетами  значит была.   

[blackfin 14]

2 minutes ago, AlexandrY said:

25% на UDP? 
Слишком оптимистично.
Какая-то химия с пакетами  значит была.   

Протокол UDP не требует проверки контрольной суммы UDP пакета, если в поле контрольной суммы пакета поставить нуль.. А раз так, то там вообще будет тривиальная обработка.

[Rst7 5]

12 minutes ago, AlexandrY said:

25% на UDP? 
Слишком оптимистично.
Какая-то химия с пакетами  значит была.   

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

[dimka76 42]

1 minute ago, Rst7 said:

Я когда-то выкладывал тут вместе с исходниками своего стека измерения скорости/нагрузки, причем TCP. 

А можно ссылку на этот пост.

Или еще раз выложить ;)

[Rst7 5]

2 minutes ago, blackfin said:

Протокол UDP не требует проверки контрольной суммы UDP пакета, если в поле контрольной суммы пакета поставить нуль.

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

[blackfin 14]

2 minutes ago, Rst7 said:

Но правильно написанный подсчет CRC занимает чуть больше, чем 0.5 такта на байт.

В протоколе UDP CRC вообще не считается.. :)

CRC считается в пакете ethernet.. И то, этим обычно занимается MAC..