Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Dec 13, 2019 11:47 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 1 2 3 4 5 613 Next
Author Message
PostPosted: Sun Feb 08, 2009 12:02 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Serge, diamond согласен с вами, тема превращается в помойку, человек просто не хочет понимать то что еу объясняют.
Причем таких грамотеев полно, тот же Вилли называет Menuet - системой реального времени.
Не могу понять откуда взялись 2.56 секунды?
Вы используете WinXP, её планировщик можт работать таким образом, что вы не получить отклика и за 10 секунд, бесконечный или просто долгий цикл в паре процессов и "здравствуйте девочки"... Колибри в такой ситуации визуально не теряет реакции отклика, а программно мы просто получаем худший вариант (процесс использует свой квант полностью) и все.


Top
   
PostPosted: Sun Feb 08, 2009 12:50 pm 
Offline

Joined: Wed Feb 04, 2009 9:47 pm
Posts: 13
У меня лично вопросов больше нет, - в принципе, все достаточно ясно.


Top
   
PostPosted: Sun Feb 08, 2009 1:07 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
http://qnxclub.net/files/articles/Remar ... rgins.html


Top
   
PostPosted: Sun Feb 08, 2009 2:03 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
2Ghost Что еще следует сказать некому граматею, чтобы до столь продвинутого developer-а доехало, что именно понимание того, что KoOS не является RTOS и не позволяют согласиться с коллегой "Ты попал абсолютно по адресу.. перед тобой простая, надёжная, гибкая система, с поддержкой всего, чего тебе надо"
И ведь что удивительно, все почему-то с этим были согласны.
А не согласные - грамотеи оказываются.
Наоборот все, как мне представляется. И это у Вас проблемы с пониманием, а не у меня
А про объясняют: реальные объяснение проблем дал Serge (за что и спасибо), хоть и по второму разу
Ваши объяснения про необходимость планировщика мне совершенно понятны (с чего Вы решили обратное - не возьму в толк), но НЕ показались (пока) принципиальной проблемой.
Про XP объяснять не было необходимости - это отличие KoOS от винды и есть основная причина моей заинтересованности.
Ну не хотим, так не хотим - нет проблем.
Только способность мою понимать оставьте в покое... Если есть такая возможность. Не нуждается она ни в чьей оценке.



2Serge Ну хорошо, давайте не будем никого ни за кого принимать

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

1) Если коды оси могут закрыть прерывания на 5-50 секунд, это вообще-то называть не десктопом надо, а обыкновенным беспределом в кодинге.
Вопрос: эдакая бесконтрольность будет существовать всегда, или все-таки стратегией команды является постепенное внесение ясности в этот вопрос
Нет, вопрос не стоит в каких-то микросекундах, или в том что это нужно к завтра. А вот какова стратегия у команды - знать таки следует.

2) Соответственно, и при дальнейшем развитии, наверное, должен существовать же какой-то критерий по соблюдению "определённых требований"
Будет он выполняться или нет - откуда я знаю...
Скажем, введение системы приоритетов аля в винде, уведет сегодняшние 2.56 сек в реальную бесконечность... Возможно такое или нет в последствии ???
Про общение с видео ОЗУ - был такой топик. И логичный вариант буферизации Вами (кажется) и был предложен. А вот по какому пути будет развиваться ось, извините, увидеть крайне затруднительно.
Неужели требования "отсутствия временного хвоста не контролируемой длины" - настолько рушат всю концепцию.
Ну если рушат - так прямо и скажите: "не, не для нас это". Это же опять прямо не сказано ведь....

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

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

Как бы это еще понятнее........
Поймите, для разработчика системы с реальным железом, существование "временных хвостов в бесконечность", это примерно то же самое что для Кодера: Существует не нулевая (хотя и очень маленькая) вероятность, что "первый jmp не сработает"
Можно ли после этого написать коды, которые будут работать всегда :?:


Top
   
PostPosted: Sun Feb 08, 2009 2:43 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Galkov wrote:
Если коды оси могут закрыть прерывания на 5-50 секунд, это вообще-то называть не десктопом надо, а обыкновенным беспределом в кодинге

Это не беспредел, а недостаток системы на данный момент. И этот недостаток необходимо устранить, т.к. допустимое время запрета прерываний, на мой взгляд, должно измеряться (принимая во внимание производительность существующих на данный момент компьютеров) микросекундами. Вопрос, как всегда, кто будет делать?

Если ОС не должна допускать использования процессора одним процессом более 10мс, то это должно выполняться всегда, не зависимо от того, какой это код: пользовательский или системный. Ясно, что прервать выполнение мы можем только если это пользовательский код. А системный код должен сам контролировать объём выполняемых им работ для текущего процесса. Так вот, этот контроль - это дополнительные трудозатараты системного программиста, которые никто (по разным причинам) не хочет на себя брать. И с этим приходится мириться. Либо делать самому. Если можешь.


Top
   
PostPosted: Sun Feb 08, 2009 3:33 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
tsdima, блин, ты тоже считаешь, что у меня проблемы с пониманием ???
Так я тебя поправлю немного:
1) Беспредел он и в Африке беспредел. И является обычно реализацией знакомой тебе идеологии: "пока это допустимо"
2) Пока я не прочитал о конкретном наличии таких неустранимых недостатков, НО прочитал о том, что никто не даст гарантии об отсутствии таковых. Не одно и то же, между прочим.

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

Ну что, очень сложные вопросы для понимания что ли :?:


Top
   
PostPosted: Sun Feb 08, 2009 3:40 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Galkov wrote:
Только про применимость для embeded - не вспоминайте лучше.

Да мы, в общем, и не вспоминаем, более осуществимых, но не сделанных вещей хватает.
Galkov wrote:
Комп в таком случае будет не более, чем отражающей, информативной системой, но уж никак не управляющей.

Всё правильно, про то и речь идёт.
P.S. "Ты попал абсолютно по адресу" - это слова не ядерщиков, между прочим.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Sun Feb 08, 2009 4:11 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
А не спорю, не ядерщиками
Но они и не думали возражать этому, до появления неких грамотеев, неспособных понять банальные объяснения

Так вопрос-то в чем: противоречат ли "более осуществимые, но не сделанные вещи" постепенному и не торопливому удалению кодов с "не контролируемым временем исполнения" из ядра ???
Или наоборот: таковые коды будут только появляться ???
Ну не может это быть безразличным (например, для экспериментов с неким планировщиком), как можно не понимать таковое....

Вот, конкретно, Serge вспоминал про чтение из видео-памяти. И был топик, в котором сие было признано как зло. И не сделано. Может просто руки не дошли, а может потому, что "нам и так хорошо". Разве введение двойной буферизации, это напряги ради RT ???
А мне так кажется, что устранение блымания курсора (да и остального - тоже), обмен с железом только по инвалидным областям - это просто хороший код, и рациональное функционирование для любой оси...

Ответа-то нет, а вместо этого - воспоминание про некого Вилле, и про грамотеев.
Впрочем, отсутствие ответа, есть тоже ответ... Если подумать :wink:


Top
   
PostPosted: Sun Feb 08, 2009 4:25 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
1,2. Могут закрыть, а могут и не закрыть. Цифры взяты с потолка. Я не знаю точно и потому не могу гарантировать что не закроют. Речь ведь шла о гарантиях "вообще". А гарантировать можно только после тестов в кокретной конфигурации и на конкретной машине. Как например сделал Дедок. Настроили, проверили - устроило.

Стратегия развития это отдельная тема. У меня, и не только, есть желание постепенно превратить ядро в микроядро. Желание это успешно компенсируется сложностью задачи. Вообще история Колибри показывает что все изменения в ядре происходят когда находится человек готовый их сделать. Так было с драйверами, vfs и ntfs, чтением СD и вообще всем остальным. Если у Вас есть желание сделать для Колибри планировщик - делайте, все будут рады. Ждать что сделает кто-то ещё можно очень долго.
В конце концов стратегию развития определяет тот кто пишет код.

3. и всё остальное
Никто не даст таких гарантий потому что система до сих пор развивалась и развивается как десктопная. Если хочется сделать RTOS то придётся самому контролировать код потому что сейчас все проверки идут по принципу работает - не работает.

P.S. 118 cli в ядре и драйверах


Top
   
PostPosted: Sun Feb 08, 2009 5:00 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Galkov

С чего всё началось...

Quote:
Ищу ОС для реализации нескольких встроенных систем, как коммерческих, так и не очень. Основные требования - удобство кодинга на асме (критично, так как я сам, кроме асма, ни на чем толком не кодирую), прямая быстрая работа юзерского софта с железом (необходимо в случае втыкания карт расширения собственной разработки); поддержка файловой системы (FAT достаточно); поддержка работы в текстовом и графическом режиме (1024*768 достаточно); поддержка RS232, и, желательно USB; работа с большими массивами данных в памяти (десятки Мб), поддержка SB16, AC97. Быть может, возникнут и еще некие потребности, но это пока основное.
В общем случае нужна "дубовая" система, из которой легко вырезать все ненужное, оставить только то, что необходимо.

Об RTOS речь вообще не шла. Всё остальное вполне применимо к Колибри. Я делал драйвера для АС97 на ICH/nForce, SIS и AMD Geode. Курсоры, 2D и kms на Радеонах. Сейчас тестирую PCI/PCIE GART чтобы свободно работать с текстурами из системной памяти. Ещё время от времени занимаюсь uhci.
Всё это к тому что у меня достаточный опыт работы с железом в Колибри на асме и в последнее время на С. И Колибри действительно прекрасно для этой работы подходит. О чём и написал Дедок. Так что Антон действительно попал по адресу.


Top
   
PostPosted: Sun Feb 08, 2009 6:31 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Galkov
Под грамотеем с Вилли видимо имелся в виду я.
Собственно я и вопроса не вижу, про то что с текущим планировщиком можно все адекватно обсчитать я говорил. Но откуда познания про 2,56 секунды и некие большие хвосты в системе мне не понятно. Да в ядре есть сотня cli, но половина из них содержит по 10 команд без переходов до sti, остальные тоже можно оценить в явном виде.
Также профессиональный разработчик выдвигает требывания детерминизма и полной верификации всего ядра (иначе тяжко железки продавать...). Защишался я учась по теме неклассических логик, используемые мной алгоритмы предназначались для верификации программ, по опыту скажу что удовольствие это очень дорогое, помнится какая то контора (QNX Software Systems ?) пару лет назад обещала представить математически безошибочную систему, ждемс...
Это я к тому что аппетит конечно приходит во время еды, но я уже просил сформулировать требования, ничего внятного так и не увидел, кроме "2,56 - это зло!"


Top
   
PostPosted: Sun Feb 08, 2009 6:47 pm 
Offline

Joined: Wed Feb 04, 2009 9:47 pm
Posts: 13
Дело в том, что у меня имеется несколько задач, - как реалтаймовых (о них я тоже здесь писал), так и не особо критичных к скорости реакции системы (сохранение и отображение статистики по данным, - например, графиков температур/расходов и тд.) Не критичные ко времени задачи - и под виндой вполне осуществимы.

Относительно реалтайм-задач вопрос снят, с этим все ясно, - там многозадачка по большому счету и не требуется. Опорный вариант кода, грузящийся из голого ДОСа, уже есть. Примитивную графику под VESA/LFB сделать вполне можно, как и запись на HD. Более того, часть рутинных задач уже решено перенести на локальные контроллеры, те же atmega или msp430.


Top
   
PostPosted: Sun Feb 08, 2009 6:53 pm 
Offline

Joined: Sun Feb 04, 2007 2:07 pm
Posts: 178
Ghost wrote:
Но откуда познания про 2,56 секунды...

Видимо Galkov имеет в виду, что при 256 активно работающих процессах в системе и при 100 Гц таймере, переключение на конкретный процесс будет занимать не менее 2,56 секунд.


Top
   
PostPosted: Sun Feb 08, 2009 7:26 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Maxis вот теперь понял. Но процессов может быть только 255, но даже если 256, получать управление каждый процесс будет с задержкой в 2,55 секунды, но повторюсь это худщий сценарий - если процесс полностью использует свой квант времени, если нет - то время уменьшится, кроме того это как никак та самая точка опоры, худше её небудет, кроме того запускать в жестком реальном времени 255 процессов - не самая лучшая идея.

Anton ИМХО для случая с реакцие в 15мсек (я так понимаю даже меньше, так как в это время входит и время считывания данных), ещё и синхронизация с промышленной сетью (не T10 устройства случаем?) лучше реализовывать аппаратно/программно (пиков и атмелов сейчас на любой вкус), хотя бы в виде буфера (а потом забирать данные например по Ethernet пусть большими объемами но медленнее), должно получится надежнее и дешевле.
Или например (фантазии на тему...) использовать какие нибудь miniITX платы на Geode, там есть куча GPIO входов, по крайней мере реакция на эти входы встроена в архитектуру камней, а вот на этих платах пускать перепиленную колибри )
На самом деле не ясно каким образом доставляются сигналы? Прерывания? RS422? Свой разработки? Если прерывания то ускорить реакцию на них можно, если опрос портов - то сложнее, но в любом случае 15мсек - ИМХО не для мультизадачной системы на PC.


Top
   
PostPosted: Sun Feb 08, 2009 7:28 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Serge wrote:
Если у Вас есть желание сделать для Колибри планировщик - делайте, все будут рады

Я надеюсь, не надо повторять, что при наличии вероятности запрета прерываний на 5-50сек никакой планировщик не поможет? По-моему, достаточно свести эту вероятность к нулю, переделав соответсвенно критические участки в ядре, может тогда и планировщик не понадобится.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 1 2 3 4 5 613 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited