Rst7

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

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

Изначально был вообще LPC1768. Зачем там напрягаться, если CPU Load получается примерно 25%? Да примерно такая же диаграмма и в TCP, ну чуть сложнее. Когда один раз сам написал TCP, то уже ничего не изобретаешь, делаешь примерно то же самое ;)

Не, изначально фраза про "это соответствует RFC ... ?", которую Вы процитировали - она в контексте поведения TCP. А то, что я потом на UDP перешел - то отдельная история. И да, протокол поверх UDP у меня получился как нечто напоминающее RDP/RUDP, но как бы любой протокол, в котором есть SEQ/ACK будет напоминать TCP и производные.

Лично я вообще именно про TCP говорил.

Он один раз вставляется при сборке, там патчкорд на внутренний свич или на Ethercon на передней панели, если прибор в виде отдельного блока. Конечный пользователь туда ничего не тыкает.

Именно так. Более того, все стеки на больших братьях (win/*nix и прочее) ведут себя именно так.

Так а какие там накладные расходы? ACK на каждый второй пакет с данными? Просто не надо ждать этого самого ACK, а посылать данные дальше, а по ACK'ам удалять данные из буфера и/или организовывать перепосылку утерянных пакетов (но надо, чтобы Ваш стек умел в Fast Retransmit/Selective ACK, иначе любая потеря пакета приведет к затыку). У меня изначально в девайсе, который на фотографии, был именно TCP. Правда потом я перешел на UDP из-за того, что появилась необходимость реализовать мультикаст и горячее подключение/отключение устройств в систему, но в своем протоколе поверх UDP я реализовал весь необходимый набор для перепосылки потерянных пакетов, примерно так же, как это сделано в TCP.

И по TCP можно. Не проблема.

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

На ноль целых хрен десятых процента? Ну и как бы 32000 никак не лезет в Ethernet, даже Jumbo, так что уже сразу фрагментация, без всяких роутеров на пути. А тот, кто посылает UDP-пакеты размером больше MTU - тот, повторюсь, сам себе злобный буратино.

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

Я вам про IP-фрагментацию вот что скажу. Сама по себе эта фрагментация - редкое зло. Требует ресурсы плюс главная неприятность - потеря одного из фрагментов приведет к потере целого пакета. Потом потребуется перепосылка протоколом более верхнего уровня всего огромного пакета, с разбиением, потом склейкой, в общем - так себе ситуация. Если же фрагментации IP-пакетов на маршруте нет, то тот же TCP (при реализации fast retransmit и/или selective ACK) отлично справляется с утерей любого сегмента, в случае быстрого раунд-трипа так вообще с минимальным провалом по пропускной способности. Кстати, что там lwip, научился это все поддерживать? В наши дни основное место, где удается встретить MTU меньшего размера, чем обычно - это разного рода туннели, VPN и прочее. Но все эти туннели умеют настраивать поле MSS в сегменте SYN для проходящего через них TCP-соединения (если SYN-сегмент проходит через роутер, у которого MTU меньше, чем необходимо для обеспечения прохода пакетов с нужным MSS, то поле MSS уменьшается настолько, насколько надо). Именно этот патч TCP-заголовка пакетов, проходящих через "узкое горлышко", и позволяет устранить проблему недостаточных MTU. Понятное дело, для UDP-пакетов такого штатного метода нет. Потому обмениваться UDP-пакетами длиннее 536 байт в большом интернете смысла нет. Если надо просунуть больше данных - добро пожаловать в TCP. В общем, по состоянию на 2020й год на фрагментацию IP-пакетов можно спокойно забить.

Причем тут "сбои связи"? Я про фрагментацию IP-пакетов. Я в большом интернете практически не встречал узлов с MTU меньше обычного,. А те, которые встречал - все поголовно исправляли MSS в SYN-сегменте. Ну а кто в большом интернете обменивается фрагментироваными UDP-пакетами - тот сам себе злобный буратино.

Можно все таки пример из жизни с бОльшими подробностями?

А нафига оно надо?

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

Чтобы Вам было о чем подумать с простой реальной схемой:

Естественно, напряжение на клеммах двухполюсника будет зависеть от внутреннего сопротивления источника (которым подается напряжение на черный ящик, не батарейка внутри черного ящика). Так это напряжение будет меняться что Rдвухполюсника>0, что <0, просто в разные стороны. Но будет какой-то установившийся режим (если нет реактивностей, с ними возможна генерация). Если Вас это смущает - возьмите источник с Rвых=0, и напряжение меняться не будет, а знак тока будет зависеть только от знака сопротивления.

Описаный Вами эффект (если i<i0) и есть отрицательное дифференциальное сопротивление. Упомянутые уже туннельные диоды такие. Или обычный стабилизированный импульсный источник питания со стороны подключения к питающей сети имеет отрицательное дифференциальное сопротивление (при увеличении питающего напряжения ток потребления падает). Создать двухполюсник, который будет ток гонять в обратную сторону даже если i>i0 и будет иметь эквивалентное отрицательное сопротивление - тоже можно, но он должен быть с собственным источником питания, чтобы быть совсем трушным двухполюсником - ну, например, с батарейкой.

Moderator: А может надо тему перенести, например, в раздел "Предлагаю работу", добавите там освещение финансовой стороны для тех, кто будет Вам помогать разбираться или делать за Вас расчеты? Либо задавайте конкретные вопросы.

И вот это они зря на откуп реализации отдали, да. Вот, например, я приводил пример кода, который дергает блок из списка, а добавить блок в этот список малость усложняется - сначала надо обычным чтением прочитать указатель на голову, заполнить им поле next в блоке, а затем уже после LDREX указателя на голову проверить, что он не изменился (и если изменился, то сделать CLREX и начинать сначала), и только после этого сохранить указатель на новый блок. Походу, и доставание блока из списка тоже должно выглядеть по другому. Сначала берем p, и p->next, а уже потом LDREX/STREX. Некрасиво, но действительно portable.

Ну? Про локальный сказано, что он может либо адрес отслеживать, либо только выполнение LDREX/STREX. Т.е. STR в произвольный адрес не приведет к сбросу монитора. В общем произвольный STR не в мониторящийся адрес безопасен между LDREX/STREX. А вот зачем этот идиотизм со сбросом монитора при эксепшне - мне нифига непонятно. От него только хуже.

С чего бы? Просто в C-M таки эксепшн сбрасывает монитор. Но только в -M Суть. Глобальный - он для многопроцессорной системы. Кроме того, все равно запись в тот же адрес нужна, а не произвольный STR.

В смысле?