Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Dec 11, 2019 8:04 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 1 2 3 4 513 Next
Author Message
PostPosted: Fri Feb 06, 2009 3:00 pm 
Offline
Kernel Developer

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

Да не будет никаких проблем с курсором. Всё будет как обычно рисоваться в видеопамять и окошко будет, только мы его не увидим потому что в текстовом режиме. Кстати Радеоны рисуют графический курсор и в текстовом режиме. Получается довольно забавно.

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


Top
   
PostPosted: Fri Feb 06, 2009 3:21 pm 
Serge
Если ты реально запускал и можешь продемонстрировать - поверю, иначе нет.
Quote:
display_data это карта окон и размер сохранился ещё с допотопных времён.

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

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


Top
   
PostPosted: Fri Feb 06, 2009 6:51 pm 
Offline
Kernel Developer

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

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


Attachments:
File comment: Ядро с минимальными правками и лаунчер с клавиатурным вводом.
dos2009.7z [72.52 KiB]
Downloaded 237 times
Top
   
PostPosted: Fri Feb 06, 2009 8:40 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Ghost wrote:
tsdima
"скорее всего будут работать менее 0,02сек" - это и есть мягкое реальное время, и то только если мы знаем меру этого "скорее всего" и она нас устраивает.

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

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

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

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

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

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

А :D :?:


Top
   
PostPosted: Sat Feb 07, 2009 12:24 am 
Serge
Хорошо, заценю. Спасибо.

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


Top
   
PostPosted: Sat Feb 07, 2009 12:57 am 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5067
Mario
Читаешь мысли, тот писал в такой же манере.

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

_________________
Через тернии к звездам


Top
   
PostPosted: Sat Feb 07, 2009 2:34 am 
Offline

Joined: Wed Feb 04, 2009 9:47 pm
Posts: 13
Для начала - поблагодарю всех за высказанные мнения.

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

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

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

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

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

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

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

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


Top
   
PostPosted: Sat Feb 07, 2009 6:28 am 
Offline
Kernel Developer

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

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


Top
   
PostPosted: Sat Feb 07, 2009 12:04 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Ну вот, простой и понятный ответ на вопрос из сабжа :D

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


Top
   
PostPosted: Sat Feb 07, 2009 1:43 pm 
Offline

Joined: Wed Sep 19, 2007 1:49 pm
Posts: 45
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.


Last edited by forart.eu on Sat Feb 07, 2009 1:51 pm, edited 1 time in total.

Top
   
PostPosted: Sat Feb 07, 2009 1:44 pm 
Offline

Joined: Wed Feb 04, 2009 9:47 pm
Posts: 13
Serge, спасибо. Ситуация, в принципе, ясна.


Top
   
PostPosted: Sat Feb 07, 2009 11:58 pm 
Offline
User avatar

Joined: Thu Mar 29, 2007 3:02 am
Posts: 249
Вообще мы выбросили из системы все приложения, кроме тех, что реально необходимы, и получили достаточную вероятность отклика за 1 сек, чего с головой для наших задач хватило...:) но, для коротких промежутков времени, надо что-то придумать...:)

_________________
*****:
;дух машины, мой бубен сильнее твоей тупости

*****:


Top
   
PostPosted: Sun Feb 08, 2009 12:57 am 
Offline
Kernel Developer
User avatar

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

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


Top
   
PostPosted: Sun Feb 08, 2009 2:53 am 
Offline

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

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

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

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


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


Top
   
PostPosted: Sun Feb 08, 2009 10:18 am 
Offline
Kernel Developer

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 1 2 3 4 513 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