Board.KolibriOS.org

Serge
Если ты реально запускал и можешь продемонстрировать - поверю, иначе нет.

display_data это карта окон и размер сохранился ещё с допотопных времён.

Ну, дык вот еще одно направление для оптимизации!

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

Mario

Вот Фома неверующий...

Ghost wrote:tsdima
"скорее всего будут работать менее 0,02сек" - это и есть мягкое реальное время, и то только если мы знаем меру этого "скорее всего" и она нас устраивает.

Вот переварил я немножечко Вами всеми сказанное....
И вот какие мысли возникли в результате:

1) Готов согласиться, что сделать супер-универсальный планировщик, вытаскивающий ресурсы компа по полной программе - не самая простая задача. И эта "полная программа" вряд ли вдохновит Kernel Developers, для которых таковая потребность несколько абстрактна

2) Но я вернусь к "одной точке опоры", которая должна оказаться проще в исполнении, чем "железобетонный фундамент". НО!!! Позволит мне (вообще-то - профессиональному разработчику) сотворять корректное проектирование оборудования.
Пусть задача упрощена до предела: мы позволяем только один такой поток в системе. Если некий второй обратится к ядру с таким запросом для себя, то получит наш революционный отлуп, типа: "ресурс уже занят"
И ведь даже такое уже позволит решать целый спектр задач реального времени. Например, вышеприведенную мной выше - позволит.

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

4) Ну хорошо (это я на будущее уже рассуждаю), пусть у нас 5 таких потоков, и каждый заказал срабатывание через 10 тиков
В чем проблема?
В том, что они могут скоррелировать, и все одновременно запросить один и тот же квант времени. Который мы конечно отдадим только кому-то одному... И так далее еще 4 раза
Что получается... ДА, мы НЕ имеем гараний в 100 мсек
НО!!! Разве мы не имеем при этом гарантий в 150 мсек
Пока мне кажется, что имеем, и что это настоящие гарантии, никаких 160 и больше мсек -- уже не будет
Какое же это мягкое RT... Очень даже жесткое, мне кажется....
Может я еще не все понял... Поправьте меня пожалуйста, если что...

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

А

Serge
Хорошо, заценю. Спасибо.

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

Mario
Читаешь мысли, тот писал в такой же манере.

Galkov
Я думаю, ради тебя и твои прогрессивных идей никто систему переписывать не будет. Если я не прав, пусть кто-то возразит мне!

Для начала - поблагодарю всех за высказанные мнения.

Теперь некоторые мысли по поводу:

1. Относительно реального времени. Есть задача, требующая реакции системы за время до 15мсек (это наиболее жесткий случай, - обработка сигналов с АЦП, выдача сигналов на выходные порты). Точнее, в течение этих 15мсек информация из буферов АЦП должна быть обработана, решения приняты, сигналы должны быть гарантированно выданы; процесс цикличный, жестко синхронизирован с частотой сети 50Гц с точностью до фазы, данные уникальные, то есть повторить из-за опоздания нет возможности. Периодически данные должны архивироваться на HDD с метками времени. Частота цикла может плавать в некоторых пределах из-за нестабильности частоты сети.

В другой задачке (система аналого-цифрового синтеза звука реального времени), - время реакции на асинхронное событие требуется порядка 30-40мсек, лучше-меньше. Заикания звука, тормоза при опросе переменных резисторов (более 100шт) мне здесь не нужны совершенно.

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

1а) Таймер. Как я понял, в КоОС таймер настраивается на 100Гц и эта частота фиксирована, то есть юзерский код не имеет права и привилегий ее дергать?

2. Относительно текстового режима, - меня это интересовало исключительно в плане удобства кодинга. Ради этого "огород городить" и шаманить над обманом функций ядра - большого смысла нет, ибо проще уж тогда под ДОСом или виндой кодировать.

3. Напрягает неудобство ковыряния системы по одной простой причине: все файлы забиты в дискеточный образ.

4. Возможно, действительно имеет смысл сделать однозадачный вариант системы для реалтайм- приложений.

Anton, Galkov

Колибри - десктопная система. Если ваши задачи требуют систем реального времени то их огромное количество - платных и бесплатных на С и ассемблере, на все случаи жизни.

Ну вот, простой и понятный ответ на вопрос из сабжа

Остались неясности насчет целевого пользователя, но это уже не самое принципиальное
Just for fun ведь всю жизнь продолжаться не может

Google-RUSSIAN:
Ну, я считаю, что АНМ-операционках такого Kolibri должны быть направлены ДКПКы...

Как уже отмечалось в других должностей / форумы Было бы замечательно использовать АНМ мощность для тяжелых вычислительных задач, таких, как декодирования / кодирования: Я считаю, что это не невозможно достичь реального BD резервного Дирака или Theora (к примеру) на встроенный Фанменее системы, пмсм.

ENGLISH:
Well, I believe that ASM-OSes such Kolibri should target HTPCs...

As already suggested in other posts/forums It would be great to use the ASM power for heavy computing tasks, such as decoding/encoding: I believe that it's not impossible to achieve realtime BD backup to Dirac or Theora (for example) on a embedded fanless system, IMHO.

Serge, спасибо. Ситуация, в принципе, ясна.

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

Если требуемая точность идёт на микросекунды, то будут большие проблемы при любом раскладе. Само переключение потоков (с переключением таблиц страниц => сбросом TLB-буферов, скажем) занимает какое-то время. Платформа PC вообще плохо подходит под системы реального времени. Одна из причин, например, - неблокируемое SMI в моменты времени, которые могут быть совершенно неподходящими (http://www.wasm.ru/forum/viewtopic.php?id=28456&p=1).
Serge прав - Колибри унаследована от системы, которая изначально задумывалась как десктопная, и продолжает развиваться, как десктопная.

diamond, мне кажется, Вы путаете твердое с холодным...
Никто не ставит вопрос о конкретных микросекундах
Мне, к примеру, давно понятно, что 16-МГц-вый 8-битный камень легко справляется с 16КГц-вым управлением, а на 2ГГц-вом проце об этом даже и мечтать не приходится
Так ведь никто и не мечтает
Нет смысла даже говорить про времена, не квантованные нашими 10 мсекундами, мне кажется

Ровно в тот момент, как речь зашла применении KoOS в embeded - мы будем иметь дело с реальным временем.
Нравится это кому-то или нет, а просто все реальные задачи, это задачи реального времени, по большому счету-то
Просто потому, что это жизнь уже реальная
Если в системе произошло событие, то на него надо реагировать за какое-то разумное время.
Сегодня ситуация такая: типовая реактивность - 10-20 мсекунд с вероятностью 99%. А оставшийся процент - вплоть до 2.5 секунд (про винды я уже и не говорю).
Это возможно допустимо только в виртуальной жизни, где заикание плэера является также допустимым
А в реальной - это совсем не так

Да, особенности архитектуры софта, железа - не позволят делать микросекунды и единицы милисекунд
Да ну и фиг с ними.
Важно отсутствие вероятностного хвоста в "бесконечность" (которая конкретно на KoOS равна 2.56 сек).

diamond, вот привели Вы ссылку...
Даже не буду вспоминать, что на одну милисекунду никто и не претендует
Ибо главное в том, что даже самое глючное железо не дает этих "хвостов", а просто немного ухудшит реактивность, на которую может рассчитывать разработчик некой реальной системы
Т.е., разработчик получает инструмент, и исходя из его характеристик разрабатывает систему
Не реально замкнуть ОС в компе -- значит я делаю по своему контроллеру на каждую координату...
И т.д., возможно вплоть до разработки своего компьютера и оси, коль скоро на это хватит денег и здоровья
И возможности (и выбор) разработчика будут разные при реактивности 2.56 сек, и (например) 100 мсек
И все - нет микросекундных претензий.


Конечно, я не могу исключать (не хватает пока образования), что магическое слово "десктопность" ставит крест на возможной реактивности в 50 мсек (при кванте 10).
Так обяснить этот факт было бы гораздо приличней, ехидных воспоминаний про неких незнакомых мне людей.
Или это у Вас не очень принято???
Ну можно и не объяснять конечно, закройте тему и продолжайте наслаждаться своей псевдокрутостью
Периодически ударяясь в поиски наиболее адекватных областей применения...

Galkov

Не надо принимать нас за личных врагов и противников RTOS на основе Колибри. Мы совсем не против. Но нельзя назвать систему RTOS просто так, без серьёзной проверки кода и испытаний в различных конфигурациях.
Термин "RTOS" предъявляет к ядру определённые требования и подразумевает что эти требования выполняются. Так вот я не могу гарантировать что максимальная латентность обработчика irq будет не больше 50 миллисекунд или 5 секунд, а может 50 секунд.
Если кто-то хочет сделать RTOS на основе Колибри - замечательно, дерзайте. Но современные RTOS не случайно пишутся на микроядрах. Колибри монолит. Значительная часть кода ядра и драйверов выполняется с маскированными прерываниями. Это и есть "десктопность". Плюс особенности железа. Например usb мышь и клавиатура эмулируются биос как ps/2 при помощи SMM. Или чтение из видеопамяти с маскированными прерываниями. Максимальная скорость чтения 10Мб/с. У меня 5.6 Мб/с. Теперь посчитайте разброс по времени при чтении битмапа с маскированными прерываниями 64*64*24bpp и 1280*1024*32bpp. Слишком много факторов и особенностей ядра и железа надо учесть чтобы можно было дать хоть какие-то честные гарантии.

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