AlexandrY 3 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 8 minutes ago, mantech said: , но того, что удовлетворяет требованиям выше, или того, чтоб пол-года не портировать, не нашел... Подозрительно непонятные требования. Вместо того чтобы бы указать лимит RAM и Flash, частоту процессора, потребление, сколько Mbit нужно получить и какая медиасреда выставляется условие чтоб "стек не падал" или падал, но незаметно. И вы с такими требованиями рассчитываете на что-то кроме шуток? Стыдно должно быть после такого количества постов на форуме идти тролить в раздел для начинающих. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 1 час назад, AlexandrY сказал: Вместо того чтобы бы указать лимит RAM и Flash, частоту процессора, потребление, сколько Mbit нужно получить и какая медиасреда выставляется условие чтоб "стек не падал" или падал, но незаметно. Вот честно - какая разница? Указано условие, чтоб не использовалась динамическая память, нужна поддержка протокола TCP и одновременная работа нескольких клиентских и серверных подключений. Второе - надежность системы, в идеале - чтоб не падала, в реальности, если упадет, то быстрая переинициализация и работа далее... Все остальное - вторично. Какой МК, пусть будет STM32F407 и более навороченные, но стек - далеко не единственная задача для МК. По-моему - никаких тут шуток, все понятно и конкретно... 1 час назад, AlexandrY сказал: Стыдно должно быть после такого количества постов на форуме идти тролить в раздел для начинающих. Нет не стыдно и не смешно, я не могу быть профессионалом во всех областях, как например интернет протоколы, но похоже, скоро изучу и это, хоть и не хотел изначально... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 4 ноября, 2019 Опубликовано 4 ноября, 2019 (изменено) · Жалоба В 15.10.2019 в 21:54, mantech сказал: Приветствую. Вообщем, решил я полностью переделать все, что можно и сделать что-то свое. Причем оно даже заработало, что удивительно Но есть один вопрос: Пример, скачивание файла по FTP. Скорость очень низкая (10 Кбайт в сек), но самое интересное то, что закачка идет на скорости 500 и более Кбайт сек. Посмотрел вирешарком, показывает, что время, между тем, когда я отдаю пакет (1440байт) FTP клиенту (на компе под виндой) и приемом подтверждения около 0.2 сек. Почему так много, кто знает? Сразу скажу, время между приемом пакета эзернет-контроллером и передачу его в стек меньше миллисекунды, поэтому будем считать, что потерь там нет. Сеть - 100мбис\с просто контроллер и комп соединенные через свич. Изменено 4 ноября, 2019 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 224 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 17 минут назад, mantech сказал: Вообщем, решил я полностью переделать все, что можно и сделать что-то свое. Причем оно даже заработало, что удивительно Поздравляю! Нашего полку прибыло. Цитата Посмотрел вирешарком, показывает, что время, между тем, когда я отдаю пакет (1440байт) FTP клиенту (на компе под виндой) и приемом подтверждения около 0.2 сек. Почему так много, кто знает? Сразу скажу, время между приемом пакета эзернет-контроллером и передачу его в стек меньше миллисекунды, поэтому будем считать, что потерь там нет. Но видимо так работает ваш стек. Протрассируйте все шаги от обнаружения прихода пакета извне (внутри ISR Ethernet), до завершения отправки его наружу (опять-же - в ISR Ethernet). С метками времени. И размер окна для TCP вы правильно выставляете? А то может у Вас "синдром "глупого" окна"? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 5 минут назад, jcxz сказал: Протрассируйте все шаги от обнаружения прихода пакета извне (внутри ISR Ethernet), до завершения отправки его наружу (опять-же - в ISR Ethernet). С метками времени Проверял там все ок (в пределах разумного конечно) Потерю времени считал именно от момента отправки в сеть пакета с данными и до прихода из сети (не обработки его стеком, а именно из сети) пакета подтверждения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 20 minutes ago, mantech said: Посмотрел вирешарком, показывает, что время, между тем, когда я отдаю пакет (1440байт) FTP клиенту (на компе под виндой) и приемом подтверждения около 0.2 сек. Почему так много, кто знает? Потому что не принято засорять сеть ненужными подтверждениями. Гуглите "delayed ACK" и "Nagle's algorithm". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 7 минут назад, jcxz сказал: И размер окна для TCP вы правильно выставляете? А то может у Вас "синдром "глупого" окна"? А вот про это можно по-подробнее? Где что выставить и посмотреть... 2 минуты назад, aaarrr сказал: Потому что не принято засорять сеть ненужными подтверждениями. А если мне нужно получить подтверждение именно после 1 пакета, то что делать?? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 2 minutes ago, mantech said: А если мне нужно получить подтверждение именно после 1 пакета, то что делать?? Когда действительно нужно, алгоритм выключают. Но это не случай FTP. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 1 минуту назад, aaarrr сказал: Когда действительно нужно, алгоритм выключают. Но это не случай FTP. Т.е. я правильно понял, что если данные больше 1 MSS, то эти пакеты можно передавать без подтверждения до размера окна и только потом получаю ответ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба Да, нужно слать в пределах окна без подтверждения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 224 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 1 час назад, mantech сказал: Проверял там все ок (в пределах разумного конечно) Потерю времени считал именно от момента отправки в сеть пакета с данными и до прихода из сети (не обработки его стеком, а именно из сети) пакета подтверждения. Может я неправильно понял: Про какую задержку речь? Я понял что речь про задержку: приём пакета устройством от компа, обработка пакета устройством, отправка пакета устройством к компу. Т.е. - задержка приёма/обработки/ответов на пакеты от компа. Или наоборот? 1 час назад, mantech сказал: А вот про это можно по-подробнее? Где что выставить и посмотреть... Погуглите. В инете полно инфы на эту тему. Это касаемо алгоритма управления размером TCP-окна. 1 час назад, aaarrr сказал: Потому что не принято засорять сеть ненужными подтверждениями. Это конечно не хорошо, но не должно приводить к задержкам. Вроде.... 56 минут назад, mantech сказал: Т.е. я правильно понял, что если данные больше 1 MSS, то эти пакеты можно передавать без подтверждения до размера окна и только потом получаю ответ? ACK просто устанавливает новый размер окна в ту сторону, откуда он пришёл. Данные можно слать до размера окна. После достижения размера окна данные тоже нужно слать, но по одному байту и редко. Это как раз про "глупое окно". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 4 minutes ago, jcxz said: Это конечно не хорошо, но не должно приводить к задержкам. Вроде.... К задержкам подтверждения должно приводить - для того и придумано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 224 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 5 минут назад, aaarrr сказал: К задержкам подтверждения должно приводить - для того и придумано. Если как автор пишет: 1 час назад, mantech сказал: между тем, когда я отдаю пакет (1440байт) FTP клиенту (на компе под виндой) и приемом подтверждения около 0.2 сек то если бы его стек на устройстве слал ACK в комп на эти принятые данные сразу же, то это не могло бы приводить к такой ситуации задержки. Просто был бы лишний траффик из ACK-ов без которого можно обойтись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 10 минут назад, jcxz сказал: Я понял что речь про задержку: приём пакета устройством от компа, обработка пакета устройством, отправка пакета устройством к компу. Т.е. - задержка приёма/обработки/ответов на пакеты от компа. Или наоборот? Задержка между отправкой пакета с данными компу и ответом подтверждения от компа. Походу комп как-раз и ждет еще пакетов, т.к. скорее всего окно приема на компе гораздо больше 1.5Кбайта... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 4 ноября, 2019 Опубликовано 4 ноября, 2019 · Жалоба 3 minutes ago, mantech said: скорее всего окно приема на компе гораздо больше 1.5Кбайта... На win по умолчанию 32 было, если не путаю. 4 minutes ago, jcxz said: то если бы его стек на устройстве слал ACK в комп на эти принятые данные сразу же, то это не могло бы приводить к такой ситуации задержки. Автор передает, а не принимает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
