MMU

Срабатывание таймера некуда "завести" - потоков-то нет. Фактически, планировщик и потоки в некоторой степени эквивалентны системе прерываний. Если поток только один, то и система может работать только по полингу, со всеми вытекающими последствиями.

Действительно, увы. Есть несколько потоков, которые по традиции, в РВ системах называются задачами :-). Одна - "высокоприоритетная", перемалывает поток данных. Другая - "низкоприоритетная", устанавливает режимы работы для первой по заказу удалённого вышестоящего процессора. Просто присвоить им разные приоритеты нельзя (подерутся за разделяемые переменные), обложить локами тоже нельзя - уйдёт слишком много времени. Вот и приходится держать их на одном приоритете, превращая заложеную в ОС вытесняющую многозадачность в кооперативную.

Sat Mar 03 2007 00:16, Ivan Maximov wrote to Basil Burtakov:

IM> From: Ivan Maximov snipped-for-privacy@mtu-net.ru

IM> Basil Burtakov пишет:

IM> Осталось только объяснить окружающему миру, что пакеты должны приходить IM> "раз в секунду-минуту-час", по расписанию, утверждённому нашим IM> устройством.

Ну, сетевая задача она не такая уж ресурсоемкая, если конечно устройство не есть специализированный роутер, который только и сделан для того, чтобы молотить поток. Типично, устройство имеет основную задачу, а сеть используется для того, чтобы дистанционно настроить параметры/снять диагностику. Параметры настраивают не постоянно, а эпизодически.

Можно оценить загрузку контроллера со стороны сетевой задачи. Если сеть это езернет 100 мегабит, и приходят пакеты в 1Кбайт размером, то типовой современный риск контроллер с тактовой 50МГц за время прихода пакета (даже если пакеты идут подряд) успеет выполнить 5000 команд. Согласитесь, это достаточно много.

BB>> Раз в BB>> секунду-минуту-час приходит пакет, а все остальное время память может BB>> (и должна) использоваться другими задачами.

AM> Хм. А откуда у тебя приходящий пакет знает, что "вот сейчас можно AM> придти" или "а вот сейчас лучше не приходить, сейчас память в том AM> устройстве используется другими задачами, надо подождать пару минут тут в AM> проводах пока память не освободится."? :))

AM>>> Спорили с утверждением, что AM>>> без использования кучи нельзя сделать приемлемо функциональный AM>>> TCP/IP стек.

BB>> Можно, но тогда надо отдать всю память на сетевую задачу,

AM> И это неверно. Hе надо отдавать всю память. Hадо отдавать столько, AM> сколько требуется.

Нет, систему надо строить так, чтобы она само могла в рантайме перераспределять ресурсы (в том числе ресурсы памяти и быстродействия). При этом может быть, что низкоприоритетные некритичные задачи на какое-то время будут отказывать в обслуживании. Такая постановка вопроса позволяет проектировать оптимальную по ресурсам (то есть оптимальную по стоимости) систему.

AM> (не говоря уже о том, что при проектировании устройства в него обычно AM> память закладывают исходя из потребностей задач, а не абы сколько...)

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Мы не можем ждать почты от аплинка. Взять ее у него - наша задача.

AM>>>>> Спорили с утверждением, что AM>>>>> без использования кучи нельзя сделать приемлемо функциональный AM>>>>> TCP/IP стек.

BB>>>> Можно, но тогда надо отдать всю память на сетевую задачу,

AM>>> И это неверно. Hе надо отдавать всю память. Hадо отдавать AM>>> столько, сколько требуется.

BB>> Hет, систему надо строить так, чтобы она само могла в рантайме BB>> перераспределять ресурсы (в том числе ресурсы памяти и быстродействия).

AM> Если надо, что мешает это делать? Hе вижу, как их этого утверждения AM> следует, что под сетевую задачу надо выделить _всю_ память.

Из этого следует, что все ресурсы надо не жестко отдавать какой-то задаче, а гибко перекидывать в то место, где они сейчас нужнее. В применении к ресурсу памяти это значит, что память должна быть доступна из кучи, откуда по мере надобности задачи ее запрашивают и куда потом возвращают.

Таким образом получаем:

1. Можно отдать статически всю память (или значительную часть памяти) системы сетевой задаче. Тогда, в пределах выделенных ресурсов, стек TCP/IP будет реализован с максимальной полнотой.

1. Можно сделать кучу и отдавать память стеку по мере поступления от него запросов на память. Этот подход позволяет делать еще какую-то полезную работу, кроме связи. При этом задача связи получает в каждый данный момент столько ресурсов, сколько система может ей выделить. Соответственно, качество обслуживания канала в точности соответствует суммарной производительности системы с учетом приоритетов, назначенных задачам.

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Крыскас. Потому что крыса вам доверяет.

BB> Таким образом получаем:

BB> 1. Можно отдать статически всю память (или значительную часть памяти) BB> системы сетевой задаче. Тогда, в пределах выделенных ресурсов, стек BB> TCP/IP будет реализован с максимальной полнотой.

Кстати, даже в этом случае куча все равно нужна. Так как все равно пакеты приходят побитые на куски и в разные моменты времени. А в статическом буфере на 1.5 килобайта их собирать тоже плохо. Так как есть такой вариант, что от пакета пришел только один кусок, а остальное потерялось. Но под этот кусок отведется 1.5 килобайта и эти 1.5 килобайта будут недоступны для других пакетов, пока не истечет таймаут пакета (то есть десятки минут). Если связь плохая, то таких пакетов может быть много и работа подсистемы связи может быть заблокирована, несмотря на то, что по факту свободной памяти предостаточно.

Если же память выделяется по фактическому размеру пакета (куска пакета), то такого не происходит.

BB>> есть такой вариант, что от пакета пришел только один кусок, а BB>> остальное потерялось. Hо под этот кусок отведется 1.5 килобайта и эти BB>> 1.5 килобайта будут недоступны для других пакетов, пока не истечет BB>> таймаут пакета (то есть десятки минут).

AM> Хм. Десятки минут? Таймаут пакета? Довольно странно...

В соответствии со спецификацией TCP/IP.

BB>> Если связь плохая, то таких BB>> пакетов может быть много и работа подсистемы связи может BB>> быть заблокирована, несмотря на то, что по факту свободной памяти BB>> предостаточно.

BB>> Если же память выделяется по фактическому размеру пакета (куска BB>> пакета), то такого не происходит.

AM> Что, никогда? Мне кажется, это зависит от объема памяти, скорости AM> прихода пакетов, TTL и т.п. то есть откучи самых разных факторов.

Естественно зависит. Речи идет о том, чтобы при данных ресурсах системы обеспечить максимальное возможное обслуживание.

AM> Посчитай-ка, сколько потребуется ОЗУ для хранения фрагментов по 100 байт AM> каждый, приходящих со скоростью (всего) 1000 пакетов в секунду и хранимых AM> по 250 секунд каждый (про десятки минут даже не заикаюсь).

Если памяти нет, то значит ее нет и ниоткуда ее не возьмешь, кроме как поставив систему помощнее (то есть подороже). Речь же о том, что часто бывает, что система построена так, что ресурсы в ней еще есть, но использовать их она не может из-за неправильного построения системы. Частный случай такого ошибочного проектирования - реализация TCP/IP без кучи.

AM> Hе там, не там ты экономию ищешь. Hакладыванием _разумных_ AM> ограничений на условия задачи добьешься гораздо большего.

"Разумных" ограничений не бывает. Бывает:

1. соответствие стандарту
2. несоответствие стандарту как следствие сознательного ограничения цены системы. Но даже и в этом случае из тех аппаратных ресурсов, которые все-таки выделены под решение задачи [задачи связи в обсуждаемом случае], можно и нужно выжимать максимум возможного. Я не знаю, как Вы смогли договориться с ICANN, чтобы Вам персонально присылали только нефрагментированные пакеты :-). Но в реальной жизни на это рассчитывать не приходится.

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Северо-Кавказская межрегиональная ассоциация анонимных соискателей.

Здравствуйте, Уважаемый Basil!

Tue Mar 06 2007 11:19, Basil Burtakov wrote to Alex Mogilnikov:

AM>> Посчитай-ка, сколько потребуется ОЗУ для хранения фрагментов по 100 байт AM>> каждый, приходящих со скоростью (всего) 1000 пакетов в секунду и AM>> хранимых по 250 секунд каждый (про десятки минут даже не заикаюсь).

BB> Если памяти нет, то значит ее нет и ниоткуда ее не возьмешь, кроме как BB> поставив систему помощнее (то есть подороже). Речь же о том, что часто BB> бывает, что система построена так, что ресурсы в ней еще есть, но BB> использовать их она не может из-за неправильного построения системы. BB> Частный случай такого ошибочного проектирования - реализация TCP/IP без BB> кучи.

Я оцениваю Ваши слова с позициий прикладника, который встраивает в аппаратуру http-сервер для управления этой аппаратурой дистанционно. Естественно, что излишне усложнять хардваре не хочется. Как Вы относитесь к такому варианту,- не дожидаться полного накопления данных, а обрабатывать фрагментированные пакеты по мере их прихода, тем самым постоянно держа буфер приема свободным? Для задач embedded server запросы обычно невелики по размеру, а уж с ответами сервера клиент пусть разбирается сам. Я вижу проблему здесь только в перепутанной последовательности поступления пакетов. Hо, опять же, для сервера выходом может быть просто отправка пакетов, пришедших вне очереди, обратно в сеть. Отправлять самому себе, они потом придут, но уже в правильном порядке.

Всего Вам Хорошего Ольга

AM>>> Посчитай-ка, сколько потребуется ОЗУ для хранения фрагментов по 100 AM>>> байт каждый, приходящих со скоростью (всего) 1000 пакетов в секунду и AM>>> хранимых по 250 секунд каждый (про десятки минут даже не заикаюсь).

BB>> Если памяти нет, то значит ее нет и ниоткуда ее не возьмешь, кроме как BB>> поставив систему помощнее (то есть подороже). Речь же о том, что часто BB>> бывает, что система построена так, что ресурсы в ней еще есть, но BB>> использовать их она не может из-за неправильного построения системы. BB>> Частный случай такого ошибочного проектирования - реализация TCP/IP без BB>> кучи.

ON> Я оцениваю Ваши слова с позициий прикладника, который встраивает в ON> аппаратуру http-сервер для управления этой аппаратурой дистанционно. ON> Естественно, что излишне усложнять хардваре не хочется. ON> Как Вы относитесь к такому варианту,- не дожидаться полного накопления ON> данных, а обрабатывать фрагментированные пакеты по мере их прихода, тем ON> самым постоянно держа буфер приема свободным? Для задач embedded server ON> запросы обычно невелики по размеру, а уж с ответами сервера клиент пусть ON> разбирается сам. Я вижу проблему здесь только в перепутанной ON> последовательности поступления пакетов. Hо, опять же, для сервера выходом ON> может быть просто отправка пакетов, пришедших вне очереди, обратно в ON> сеть. Отправлять самому себе, они потом придут, но уже в правильном ON> порядке.

Честно говоря такого коварного решения проблемы фрагментации как отправлять самому себе пакеты с надеждой, что они задержаться в сети я даже в самых смелых своих фантазиях не мог представить. :-) Не думаю, что это хороший выход. Прежде всего потому, что сеть может не понять пакеты со своим же обратным адресом. Как это будут обрабатывать другие узлы? И не прибьют ли они такие пакеты как ошибочные. А если не прибьют, то не отфутболит ли ближайший роутер такой пакет обратно и задержка будет минимальной. Опять же время на передачу тратится, а передатчик может быть нужен для дела. Ну и кроме того это просто некрасиво - дудеть своей информацией засоряя каналы. А если задерженный фрагмент не придет никогда? Так и будете до исчерпания таймаута гонять остальные фрагменты пакета по интернету?

ON> Всего Вам Хорошего ON> Ольга

Здравствуйте, Уважаемый Basil!

Tue Mar 06 2007 14:36, Basil Burtakov wrote to Olga Nonova:

ON>> .... Я вижу проблему здесь только в перепутанной ON>> последовательности поступления пакетов. Hо, опять же, для сервера ON>> выходом может быть просто отправка пакетов, пришедших вне очереди, ON>> обратно в сеть. Отправлять самому себе, они потом придут, но уже в ON>> правильном порядке.

BB> Честно говоря такого коварного решения проблемы фрагментации как BB> отправлять самому себе пакеты с надеждой, что они задержаться в сети я BB> даже в самых смелых своих фантазиях не мог представить. :-) Hе думаю, что BB> это хороший выход. Прежде всего потому, что сеть может не понять пакеты BB> со своим же обратным адресом. Как это будут обрабатывать другие узлы?

Это их дело.

BB> не прибьют ли они такие пакеты как ошибочные. А если не прибьют, то не BB> отфутболит ли ближайший роутер такой пакет обратно и задержка будет BB> минимальной. Опять же время на передачу тратится, а передатчик может быть BB> нужен для дела. Hу и кроме того это просто некрасиво - дудеть своей BB> информацией засоряя каналы. BB> А если задерженный фрагмент не придет BB> никогда? Так и будете до исчерпания таймаута гонять остальные фрагменты BB> пакета по интернету?

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

Всего Вам Хорошего Ольга

ON>>> .... Я вижу проблему здесь только в перепутанной ON>>> последовательности поступления пакетов. Hо, опять же, для сервера ON>>> выходом может быть просто отправка пакетов, пришедших вне очереди, ON>>> обратно в сеть. Отправлять самому себе, они потом придут, но уже в ON>>> правильном порядке.

BB>> Честно говоря такого коварного решения проблемы фрагментации как BB>> отправлять самому себе пакеты с надеждой, что они задержаться в сети я BB>> даже в самых смелых своих фантазиях не мог представить. :-) Hе думаю, BB>> что это хороший выход. Прежде всего потому, что сеть может не понять BB>> пакеты со своим же обратным адресом. Как это будут обрабатывать другие BB>> узлы?

ON> Это их дело.

Гм... :-)

BB>> не прибьют ли они такие пакеты как ошибочные. А если не прибьют, то не BB>> отфутболит ли ближайший роутер такой пакет обратно и задержка будет BB>> минимальной. Опять же время на передачу тратится, а передатчик может BB>> быть нужен для дела. Hу и кроме того это просто некрасиво - дудеть BB>> своей информацией засоряя каналы. BB>> А если задерженный фрагмент не придет BB>> никогда? Так и будете до исчерпания таймаута гонять остальные фрагменты BB>> пакета по интернету?

ON> А нефига было перепутывать порядок следования пакетов. Перепутал- ON> получай.

Так это же в спецификации записано. Пакеты в общем случае могут быть побиты на фрагменты и фрагменты перепутаны и продублированы.

ON> Hу, а кроме шуток, в интранет, где собственно и кучкуются обычно ON> ембеддеры, таких ужасностей, как перепутывание порядка следования ON> пакетов, на практике не наблюдается.

Да, обычно самопальные устройства стоят в локалке, где нет даже фрагментирования пакетов. Но это сильно необщий случай. Вообще вопрос был "обоснованность применения кучи во встроенных системах". TCP/IP был приведен как пример алгоритма, который невозможно полноценно реализовать без кучи. Такая реализация "без кучи" сопровождается столь большим количеством ограничений, что говорить, что получившееся есть TCP/IP как-то неловко.

ON> А управлять чем-то на другом конце ON> земного шара- это экзотика

Роутер Циско это экзотика? Мониторится и настраивается с любого конца Земного шара.

ON> и, наверное, действительно ужиматься с памятью ON> не следует.

В принципе есть (были?) микросхемы, которые обеспечивали четыре одновременных соединений TCP/IP. Сам я не применял, только слышал. Производитель чуть ли не Casio. Надо искать в гугле на слова "аппаратный стек TCP/IP". Ставьте такую и будет счастье.

Здравствуйте, Уважаемый Basil!

Tue Mar 06 2007 17:01, Basil Burtakov wrote to Olga Nonova:

ON>> Hу, а кроме шуток, в интранет, где собственно и кучкуются обычно ON>> ембеддеры, таких ужасностей, как перепутывание порядка следования ON>> пакетов, на практике не наблюдается.

BB> Да, обычно самопальные устройства стоят в локалке, где нет даже BB> фрагментирования пакетов. Hо это сильно необщий случай.

Подозреваю, что для ембеддера = это единственно,стоящее внимания дело. Тут и home-automation (см. web-server на восьминожковом PIC), тут и различные реализции АСУТП, тут и корпоративные бизнесс-системы....-очень много чего делается на Ethernet в локалке, без выхода во внешний мир. И ситуация с передачей пакетов здесь значительно более благоприятная, нежели прописано в стандартах RFC. Этим можно воспользоваться, чтобы не излишне не усложнять хардваре.

BB> Вообще вопрос был BB> "обоснованность применения кучи во встроенных системах". TCP/IP был BB> приведен как пример алгоритма, который невозможно полноценно реализовать BB> без кучи.

Я бы сперва занялась обоснованием TCP/IP во встроенных системах. Hафига это вообще нужно в локалке? Hе достаточно ли UDP? Тут сперва неплохо все-таки определиться с потребностями- где нужна куча, а где -нет.

BB> Такая реализация "без кучи" сопровождается столь большим количеством BB> ограничений, что говорить, что получившееся есть TCP/IP как-то неловко.

А если это все-таки работает без проблем, то какая разница? "Вам шашечки, или ехать? (с)-анекдот.

ON>> А управлять чем-то на другом конце ON>> земного шара- это экзотика BB> Роутер Циско это экзотика? Мониторится и настраивается с любого конца BB> Земного шара.

Я не в курсе столь длинных дистанций.

ON>> и, наверное, действительно ужиматься с памятью ON>> не следует.

BB> В принципе есть (были?) микросхемы, которые обеспечивали четыре BB> одновременных соединений TCP/IP. Сам я не применял, только слышал. BB> Производитель чуть ли не Casio. Hадо искать в гугле на слова "аппаратный BB> стек TCP/IP". Ставьте такую и будет счастье.

Спасибо за инфу.

Всего Вам Хорошего Ольга

ON>>> Hу, а кроме шуток, в интранет, где собственно и кучкуются обычно ON>>> ембеддеры, таких ужасностей, как перепутывание порядка следования ON>>> пакетов, на практике не наблюдается.

BB>> Да, обычно самопальные устройства стоят в локалке, где нет даже BB>> фрагментирования пакетов. Hо это сильно необщий случай.

ON> Подозреваю, что для ембеддера = это единственно,стоящее внимания дело. ON> Тут и home-automation (см. web-server на восьминожковом PIC), тут и ON> различные реализции АСУТП, тут и корпоративные бизнесс-системы....-очень ON> много чего делается на Ethernet в локалке, без выхода во внешний мир. И ON> ситуация с передачей пакетов здесь значительно более благоприятная, ON> нежели прописано в стандартах RFC. Этим можно воспользоваться, чтобы не ON> излишне не усложнять хардваре.

Ну, в такой постановке вопрос тоже имеет место быть. Это как-бы такой СОМ порт, но по езернету. Когда ничего не теряется, ничего не фрагментируется плюс бонус в виде маршрутизации, зашитой в формат протокола.

BB>> Вообще вопрос был BB>> "обоснованность применения кучи во встроенных системах". TCP/IP был BB>> приведен как пример алгоритма, который невозможно полноценно реализовать BB>> без кучи.

ON> Я бы сперва занялась обоснованием TCP/IP во встроенных системах. Hафига ON> это вообще нужно в локалке? Hе достаточно ли UDP? Тут сперва неплохо ON> все-таки определиться с потребностями- где нужна куча, а где -нет.

В локалке обычно хватает UDP. Да и не в локалке для встроенных систем обычно ограничиваются UDP, бо TCP это достаточно обязывающая задача.

BB>> Такая реализация "без кучи" сопровождается столь большим количеством BB>> ограничений, что говорить, что получившееся есть TCP/IP как-то неловко.

ON> А если это все-таки работает без проблем, то какая разница? "Вам шашечки, ON> или ехать? (с)-анекдот.

ON>>> А управлять чем-то на другом конце ON>>> земного шара- это экзотика BB>> Роутер Циско это экзотика? Мониторится и настраивается с любого конца BB>> Земного шара.

ON> Я не в курсе столь длинных дистанций.

Тем не менее они существуют и востребованы. Часто заказчики требуют, чтобы девайс мониторился каким-то стандартным протоколом, коих несть числа. Вернее, конкуренты предоставляют заказчикам такую возможность, поэтому приходится реализовывать. И, как назло, большинство из этих протоколов базируются на TCP.

ON>>> и, наверное, действительно ужиматься с памятью ON>>> не следует.

BB>> В принципе есть (были?) микросхемы, которые обеспечивали четыре BB>> одновременных соединений TCP/IP. Сам я не применял, только слышал. BB>> Производитель чуть ли не Casio. Hадо искать в гугле на слова "аппаратный BB>> стек TCP/IP". Ставьте такую и будет счастье.

ON> Спасибо за инфу.

Служу Советскому Союзу :-) Привет Фитону и фитонщикам. :-) Кстати, мужики, поздравляю вас с Международным Женским днем. :-)

ON> Всего Вам Хорошего ON> Ольга