После почти полутора лет разработки представлена (https://lkml.org/lkml/2012/4/6/39) четвёртая версия планировщика задач SCHED_DEADLINE (https://github.com/jlelli/sched-deadline), реализующего алгоритм EDF (Earliest Deadline First), основанный на идее повышения приоритета для задач с более ранним временем завершения. SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов.
Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мсек в интервале 100 мсек) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.
Ключевым изменением нового выпуска SCHED_DEADLINE является обеспечение поддержки PREEMPT_RT (http://www.osadl.org/Realtime-Linux.projects-realtime-linux....) ветки ядра Linux (3.2.13-rt23) c реализацией жёсткого режима реального времени, которая используется в real-time редакциях промышленных Linux-дистрибутивов MontaVista, Red Hat и Novell. Несмотря на то, что патчи теперь базируются на ветке PREEMPT_RT, продолжается работа по продвижению разработки в состав основного ядра Linux. Параллельно поддерживается ветка SCHED_DEADLINE2 (https://github.com/insop/sched-deadline2) с патчами для основной ветки ядра Linux.
Кроме того, в новой версии SCHED_DEADLINE улучшен (http://retis.sssup.it/~jlelli/papers/Ospert11Lelli.pdf) алгоритм выбора очередей выполнения (runqueue) для обеспечения динамической миграции задач на многопроцессорных системах. В частности, реализован эквивалент cpupri для задач, для которых выбран метод планирования deadline (cpudl). Из планов на будущее отмечается реализация средств управления пропускной способностью на основе cgroup. Вместо планирования на основе приоритета и предельного времени (deadline) рассматривается возможность оперирования пропускной способностью.
<center><img src="http://www.opennet.me/opennews/pics_base/0_1333882237.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
Дополнительно можно отметить публикацию результатов (https://www.osadl.org/Single-View.111+M516dd7f7d5b.0.html) первого года работы тестовой инфраструктуры для оценки качества работы Linux при выполнении задач реального времени и для постоянного наблюдения за изменением характеристик RT-Linux при выполнении различных нагрузочных сценариев. Целью проекта является организация регулярных проверок новых Linux-ядер и RT-патчей в приближенных к реальным условиях и на широком спектре различных аппаратных платформ. В настоящее время тестовая инфраструктура включает в себя 50 различных аппаратных платформ. Работа тестовой фермы организована (http://www.opennet.me/opennews/art.shtml?num=28734) консорциумом OSADL (Open Source Automation Development Lab), развивающим решения на базе Linux для промышленной встраиваемой техники и курирующим разработку real-time патчей PREEMPT_RT к Linux ядру.
За год тестирования была накоплена информация о выполнении 73 миллиардов тестовых циклов. Все данные наглядно визуализированы в виде 3D-графиков. Использование логарифмической шкалы позволяет выделить в виде пика даже единичные изменения отзывчивости системы.<center><img src="http://www.opennet.me/opennews/pics_base/0_1333883152.jpeg&q... style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
URL: https://lkml.org/lkml/2012/4/6/39
Новость: http://www.opennet.me/opennews/art.shtml?num=33559
Новость не читал, скажите сразу - лучше BFS или нет?
BFS - уже говно, не, конечно если у тя Pentium II 433, то пойдёт.
Комменты не читал, но первые два понравились)
это не для чукчей, т.е. которые не читатели
А что сейчас тогда самое нормальное, на свежем железе?
Дефолтный - CFS.
>основанный на идее повышения приоритета для задач с более ранним временем завершениякак такое вообще возможно? кто может сказать сколько будет выполняться та или иная задача, это почти случайный процесс
По этому он и называется DEADLINE. И вообще, тут неправильно перевели,
не "задач с более ранним временем завершения", а с большим временем в очереди к процессору.
и ваще, там не время, а индексы, ну и как в жизни - у кого больше индекс тот и папа! :)
> кто может сказать сколько будет выполняться та или иная задача,
> это почти случайный процессНу да, щазззз. Собственно задача шедулера в том и состоит чтобы вовремя вклиниться, отобрать и поделить [время CPU, так как задумано приоритетами и прочими настройками].
Какие к черту случайности? Это вам не Win 3.0 с кооперативной многозадачностью.
Если время выполнения задачи "почти случайный процесс" - то реалтайм и рядом не стоял.
Можно чуток расстрою розовую новость!1. DEADLINE, как самостоятельный планировщик, туповат, надо руками выставлять приоритеты.
2. RT_PREEMPT ну ваще ни разу не HARD REALTIME
3. Редкие, но запоры в латентности, бывают до 2000-3000 us, при среднем показателе 50-80 us
4. Для полного реалтайм-кайфа, надо напрочь сносить всё управление питанием, от idle в процах до скринсейвера и DPMS монитора.
Да, но учти что с течением времени количество ядер/процессоров в системе и ее вычислительные способности только растут (если, конечно, этот прирост не убивать в нуль используя трэш навроде .net,mono, python, ... ).
> 2. RT_PREEMPT ну ваще ни разу не HARD REALTIMEHARD REALTIME это всего лишь жесткие гарантии того что на некое событие будет отреагировано не более чем за X и ни при каких условиях не более чем. Чему этот X равен - отдельный вопрос :)
> 3. Редкие, но запоры в латентности, бывают до 2000-3000 us, при среднем
> показателе 50-80 usНу загарантируй 4000us если ты уверен что за этот предел никогда не выскочит, получишь hard realtime хоть и слегонца эстонский :).
> 4. Для полного реалтайм-кайфа, надо напрочь сносить всё управление питанием, от idle
> в процах до скринсейвера и DPMS монитора.Если тебе надо предсказуемость до единиц микросекунд, x86 вообще бяка. Джиттер времени одной и той же операции на х86 будет мама не горюй, в зависимости от cache hit/cache miss, успеха предсказания бранчей и прочая. Оно такое ориентировано на "скорость молочения вообще" а не "предсказуемое время реакции". По второму параметру примитивное фирмваре на 1 кило в хилой 8-битной атмеге на ее скромных 10-20 МГц уделает x86 c диким отрывом.
> Ну загарантируй 4000us если ты уверен что за этот предел никогда не
> выскочит, получишь hard realtime хоть и слегонца эстонский :).Хардкорные реалтаймы дают погрешность 5% (как на резисторы с золотой полоской :))
А среднее 80 us и пики до 4000 - это не хардкор, это групповуха.Кстати, знаешь как они там тесты делают?! Запускают latency_test, cyclictest и курят 24 часа.
Попробуй запусти во время этого теста find / -exec md5sum {} \;
тут реалтайм и кончится :)> ... примитивное фирмваре на 1 кило в хилой 8-битной атмеге на ее скромных 10-20 МГц
> уделает x86 c диким отрывом.Апчём и речь.
> Кстати, знаешь как они там тесты делают?! Запускают latency_test, cyclictest и курят 24 часа.
> Попробуй запусти во время этого теста find / -exec md5sum {} \;
> тут реалтайм и кончится :)Сразу видно - теоретик, "не читал но осуждаю".
# uname -srvo
Linux 3.2.9-rt17 #33 PREEMPT RT Mon Apr 2 01:06:36 MSK 2012 GNU/Linux# cyclictest -t1 -p 99 -n -i 10000 &
# top
Mem: 8028K used, 52312K free, 0K shrd, 8K buff, 3616K cached
CPU: 1.5% usr 29.2% sys 0.0% nic 59.1% idle 0.0% io 0.0% irq 9.9% sirq
Load average: 0.00 0.00 0.00 1/55 473
T: 0 ( 472) P:99 I:10000 C: 8008 Min: 18 Act: 83 Avg: 33 Max: 116
# find / -exec md5sum {} \; > /dev/null &
#top
Mem: 8992K used, 51348K free, 0K shrd, 8K buff, 4228K cached
CPU: 4.6% usr 91.9% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 3.4% sirq
Load average: 1.16 0.41 0.15 2/56 592
T: 0 ( 588) P:99 I:10000 C: 3985 Min: 36 Act: 93 Avg: 69 Max: 125для тебя специально расшифрую - загрузка процессора 100% при этом worst case latency вырос всего на 9 мкс - со 116 до 125 мкс.
# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 199.06
Чёй-то говёненький рылтайм на ваши ARMах
# cyclictest -t4 -p 99 -n -i 10000policy: fifo: loadavg: 0.23 0.36 0.33 2/299 11743
T: 0 (30057) P:99 I:10000 C: 38569 Min: 4 Act: 14 Avg: 10 Max: 72
T: 1 (30058) P:98 I:10500 C: 36732 Min: 3 Act: 8 Avg: 13 Max: 62
T: 2 (30059) P:97 I:11000 C: 35063 Min: 4 Act: 9 Avg: 10 Max: 42
T: 3 (30060) P:96 I:11500 C: 33538 Min: 3 Act: 10 Avg: 9 Max: 60
А вот так, если запустить mplayer c AVIT: 0 (13929) P:99 I:10000 C: 9597 Min: 4 Act: 11 Avg: 10 Max: 198
T: 1 (13930) P:98 I:10500 C: 9140 Min: 4 Act: 12 Avg: 10 Max: 160
T: 2 (13931) P:97 I:11000 C: 8724 Min: 5 Act: 11 Avg: 10 Max: 50
T: 3 (13932) P:96 I:11500 C: 8345 Min: 5 Act: 8 Avg: 11 Max: 65Oil Rush + Mplayer
policy: fifo: loadavg: 1.00 0.88 0.60 4/253 19285
T: 0 (16116) P:99 I:10000 C: 70263 Min: 3 Act: 16 Avg: 9 Max: 298
T: 1 (16117) P:98 I:10500 C: 66917 Min: 3 Act: 22 Avg: 8 Max: 217
T: 2 (16118) P:97 I:11000 C: 63876 Min: 3 Act: 17 Avg: 9 Max: 282
T: 3 (16119) P:96 I:11500 C: 61098 Min: 3 Act: 23 Avg: 8 Max: 259
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 33
model name : Dual Core AMD Opteron(tm) Processor 285
...В процессах, такие монстры как conky, haveged,hald,dbus,rsyslogd, cron,console-kit-daemon,
весь XFC4, хромиум, тандырбёрд, find на 3-х терабайтах MD5 считает, тут пишу, ...И чё?! Считаешь нормально, пиковые в 20-30 раз больше средних?!
---
Вот так нормально. :D
T: 0 (13929) P:99 I:10000 C: 9597 Min: 4 Act: 10 Avg: 10 Max: 10
T: 1 (13930) P:98 I:10500 C: 9140 Min: 4 Act: 10 Avg: 10 Max: 10
T: 2 (13931) P:97 I:11000 C: 8724 Min: 5 Act: 10 Avg: 10 Max: 10
T: 3 (13932) P:96 I:11500 C: 8345 Min: 5 Act: 10 Avg: 10 Max: 10
root@megagamer:/home/prot# cyclictest -t4 -p99 -n -i10000
WARNING: Most functions require kernel 2.6
policy: fifo: loadavg: 0.02 0.09 0.07 1/142 26976T: 0 (26973) P:99 I:10000 C: 20588 Min: 1 Act: 3 Avg: 4 Max: 64
T: 1 (26974) P:98 I:10500 C: 19607 Min: 1 Act: 2 Avg: 4 Max: 27
T: 2 (26975) P:97 I:11000 C: 18716 Min: 1 Act: 3 Avg: 3 Max: 20
T: 3 (26976) P:96 I:11500 C: 17902 Min: 1 Act: 4 Avg: 4 Max: 54model name : AMD Phenom(tm) II X4 955 Processor
---
Не знаю нормально ли, но на серваке крутятся 3 игровых CS1.6 и 2 игровых CS Source.
И задроты ещё жалуются на "плохую стрельбу".. Я сам не играю, поэтому мне трудно понять что это значит %) но по показателям, я так понял, процессор успевает..
А ты вот такую сетевушку, за 400€, себе, задротам и провайдерам купи :)
http://www.prosoft.ru/products/brands/hilscher/374263.html
и коммутаторы тоже, минимум с фильтрацией TTL и IGMP, бродкасты запретить,
автосоглосования, сетевые буфера уменьшить, витую STP cat. 6e c позолотой всем.Не знаю, правда иль нет, но пишут, что народ добивался задержек,
меж двумя хостами, по инету не более 2 мс. (или 2000 мкс.)
> меж двумя хостами, по инету не более 2 мс. (или 2000 мкс.)Тудыть, у меня такой пинг до мыла.ру с самым паршивым реалтеком и какой-то нонейм витухой. Приколись, тебя кажется развели на золоченой витухе :)
> Тудыть, у меня такой пинг до мыла.ру с самым паршивым реалтекомА у меня шлен 25 см.
Вот скриншот - http://i35.fastpic.ru/big/2012/0410/ac/f178f24b6e8b9c37c1fce...
Пришлось 2 минуты потратить, чтоб циферки поменять.
> И задроты ещё жалуются на "плохую стрельбу"..Дядь, микросекунды на фоне даже 1 мс пинга не роялят. Пусть задроты проверяют свой трейсроут до сервака и вообще свое соединение :). А то поразвелось будаков чуть ли не на жпрс, которым все виноваты. Кроме их кривого интернета.
> И чё?! Считаешь нормально, пиковые в 20-30 раз больше средних?!Ну так и есть - теоретик, это вообще никого кроме тебя не волнует :) тут главное что время отклика не превышает фиксированной величины, это как погрешность прибора - никого не волнует что он может измерить намного точней своего класса - стоит у него класс точности 2.0 и этим все сказано.
> Хардкорные реалтаймы дают погрешность 5% (как на резисторы с золотой полоской :))Хардкорные реалтаймы могут быть и буквально по тактам проца вычислены для простых штук типа какойнить atmega. Точность во времени реакции может быть предсказана буквально до единиц тактов, при 20МГц тактовой это кусочки по 0.05 usec. Во всяком случае, один перец осилил смолотить low-speed usb через GPIO (а это, на секундочку, полтора миллиона битов в секунду, разрюханых без аппаратной поддержки интерфейса, как отдельные битики).
Слабо - полтора миллиона состояний в секунду разгрести? А там еще кодирование по типу NRZI. При тактовой частоте характерной для атмеги это всего несколько команд на получение значения бита и делания с ним чего либо. Вот это - да, реально крутой реалтайм, когда перец в софте захреначил то что обычно требует аппаратных подпорок. Если тормознуть - будет нарушение протокола.
> А среднее 80 us и пики до 4000 - это не хардкор, это групповуха.Я только 1 не понял: на воооон том графике вся шкала до 400 и пики только в начала... может ты что-то делаешь не так?
> тут реалтайм и кончится :)
А ты это делал на кернеле с preempt rt и прочими ништяками?
> Апчём и речь.
Ну так это на случаи когда очень крутой скорости реакции не надо, однако продолб программы ответить вовремя вызывает какие-то нехорошие последствия. Например принятие решения о объезде автоматически управляемым авто препятствия. Фонарный столб за 1 микросекунду на дорогу не выскакивает, однако продолб принять решение за определенное время приведет к нехрошим последствиям. И атмелке как-то слабо картинку с камеры распознавать и принимать такие "высокоуровневые" решения.
> Я только 1 не понял: на воооон том графике вся шкала до
> 400 и пики только в начала... может ты что-то делаешь не
> так?Железка корявая, Atom D425 и сетевуха Реалтык 8169 (c фирмварью),
как трафик начинает идти, все, суши ласты, реалтайм исчезает. :)> А ты это делал на кернеле с preempt rt и прочими ништяками?
Угу...
> Если тебе надо предсказуемость до единиц микросекунд, x86 вообще бяка. Джиттер времени
> одной и той же операции на х86 будет мама не горюй, в зависимости от cache hit/cache
> miss, успеха предсказания бранчей и прочая. Оно такое ориентировано на "скорость
> молочения вообще" а не "предсказуемое время реакции". По второму параметру примитивное
> фирмваре на 1 кило в хилой 8-битной атмеге на ее скромных 10-20 МГц уделает x86 c диким
> отрывом.ври, но не завирайся. сравни размер кэша с размером раб.памяти атмеги, переведи життер из процессорных тактов в реальное время с учетом частот, поставь в одинаковые условия (прерывания, чистый дос или даже без него в х86) и подумай. сравнивать атмегу с х86 вообще глупо, но говорить что атмега уделает х86 "по предсказуемому времени реакции" это вообще бред собачий. Чистый программный полл на х86 уделает атмегу на прерываниях так что ей и не снилось - стократная разница в частотах это не шутка.
> ври, но не завирайся.Мужики, давайте всё ж рассматривать RT как программно-аппаратную пару.
А то 4-ядерный Пень, в фоне играющий Mplayer, на втором мониторе Oil Rush,
куча народу в аське, в скайпе, фаерфокс иль гуглохром с 20 табами и флешем,
пишушейся на флешку дамп блюрея, торрент с 200 пирами, обеспечат вам полный
анитреалтайм по всем подсистемам.
Иль атмега с одним процессом, которая шлёт сигналы размером 1 байт,
раз в 10 миллисекунд на привод станка.
> ври, но не завирайся. сравни размер кэша с размером раб.памяти атмеги, переведи
> життер из процессорных тактов в реальное время с учетом частот,У атмеги джиттер зачастую равен _нулю_ - все априори известно потактово, так что можно предсказать все с точностью до долей микорсекунды. В том числе и за сколько тактов оно на событие на лапке среагирует. Этому x86 с его монстрильными контроллерами прерываний, суперсложными шинами и прочая такое и не снилось.
> поставь в одинаковые условия (прерывания, чистый дос или даже без него
А ща мы вас обломим. Вспоминаем про SMI и понимаем что на типовом писюшнике x86 вообще никому нифига не гарантирует, поскольку системное фирмваре может в любой момент хапнуть управление на _неопределенный_ срок. У линя например по этому поводу есть некий монитор основанный на TSC кажется, который паникует если системное фирмваре сперло слишком дофига времени. Но как вы понимаете, паника то - постфактум...
Вот вы будете кому-то что-то гарантировать заместо парней из Award/AMI? Особенно когда вопрос например в том что при таймауте автоуправляемый грузовик вхреначится в препятствие, например?
> в х86) и подумай. сравнивать атмегу с х86 вообще глупо,
Да, у x86 крайне тормозная реакция на внешние раздражители :)
> но говорить что атмега уделает х86 "по предсказуемому времени реакции" это вообще бред
> собачий. Чистый программный полл на х86 уделает атмегу на прерываниях так
> что ей и не снилось - стократная разница в частотах это не шутка.А по-фи-гу: у x86 контроллер прерываний вообще внешняя фигня, и не больно какая быстрая, а GPIO вообще толком нет, а пока там достучишься до периферии на шине.... Гигагерцы - есть, но они ориентированы на массовый обмолот а не скорость реакции. Чтобы на некое событие за пол-микросекунды гарантированно среагировать - не заточено вообще никак. Поэтому толку с этих гигагерцев - ноль. Подразумевается умная периферия с своими процами/прочей логикой и буферной памятью, рюхающая сильно критичные по времени сущности самостоятельно. Собственно такая железка может в общем случае жить своей жизнью и без х86-хоста вообще.
> У атмеги джиттер зачастую равен _нулю_ - все априори известно потактово, так что можно
> предсказать все с точностью до долей микорсекунды. В том числе и за сколько тактов оно
> на событие на лапке среагирует.Во первых, ровно то же самое известно и для чипов х86. И то что в атмеге декларируется 3-5 тактов на переход на обработку прерывания, а в х86 это может оказаться цифра 5-100 (с потолка взятые цифры) ничего не означает на практике - при пересчете в реальное время - на те же микросекунды, этот джиттер съедатся разницей частот. Во-вторых, джиттер надо учитывать не на переход на программу прерывания, а на реальный отклик - другими словами, надо добавлять сюда еще время обработки прерывания. Вот ты посчитай полное время отработки (в микросекундах, ага) на то чтобы считать данные из порта, посчитать от него скажем синус и выставить в другой порт, а мы вместе посмеемся, когда сравним время отклика на атмеге и на х86.
> А ща мы вас обломим. Вспоминаем про SMI и понимаем что на типовом писюшнике x86 вообще
> никому нифига не гарантирует,В исходном посте речь шла что атмега уделает х86, а не типовой писюшник. Это как бы две очень большие разницы. Как насчет распаянного эмбед х86, без каких либо биоса и прочих финтифлюшек?
> А по-фи-гу: у x86 контроллер прерываний вообще внешняя фигня, и не больно какая
> быстрая, а GPIO вообще толком нет, а пока там достучишься до периферии на шинеБоже мой, какая безграмотность. Никакой внешний контроллер прерываний не поможет, если нет прерываний в самом проце (INTR/NMI). Поставь нужные порты и задействуй INTR, если так уж хочется сравнивать сами архитектуры. Про скорость периферии улыбнуло - атмега сравнится разве что с лохматым 80386/ISA.
если не дошло, то объясню еще раз - х86 не используется для подобных задач не потому что он этого не умеет, а потому что overkill: дорого и неудобно.
Я, в принципе, к тому, что если не использовать навороты современных х86 и добавить периферию, тогда то, что получится, можно назвать аналогом 80х51, разогнанным до гигагерца. Если на равных частотах атмега и заруливает 8051, то тут разница на 2 порядка не в пользу атмеги.
> без каких либо биоса и прочих финтифлюшек?Сoreboot!
> Во первых, ровно то же самое известно и для чипов х86.Оно никогда не известно с какой либо точностью, т.к. нет никаких _гарантий_ попадания в кеш, угадывания или не угадывания ветвления и прочая. И джиттер там нефиговый сам по себе.
> И то что в атмеге декларируется 3-5 тактов на переход на обработку
> прерывания, а в х86 это может оказаться цифра 5-100 (с потолка
> взятые цифры) ничего не означает на практике - при пересчете в
> реальное время - на те же микросекунды,У атмеги ее такты - это с момента когда на лапке изменились условия и до момента когда ядро проца отдаст руль обработчику прерываний, который этим вопросом озадачится. Потому что контроллер GPIO вплотную к ядру, сразу его и дергает. А у x86 пока там что-то где-то по хрензнаеткаким шинам из своих дербеней отсигналит что тут у нас вообще прерывание прилетело - рак на горе свистнет.
Что x86 может "сам по себе" видно на примере программаторов на LPT/COM порт где x86 относительно "напрямую дергает IO-лапками". В современных реалиях правда оно вообще подохло т.к. в многозадачках выходит совсем жопно. А все быстрые программаторы как один юзают микроконтроллер который и разруливает скоростной дерг лапками из буфера почему-то.
> этот джиттер съедатся разницей частот.
Ну да, мечтайте. У x86 вообше нет GPIO по сути. А пока там от периферии доползет что вообще имело место прерывание... ну вон в PCI-E вообще прерываний нет. Там только сообщение :) о том что "а вот это типа прерывание" ("MSI" - message signaled interrupt). В юсб вообще тухляка - там хост опрашивает периферию - "есть чо? А если найду?" и не более 1000 раз в секунду всего (особо хардкорные геймеры и то плюются).
> Во-вторых, джиттер надо учитывать не на переход на программу прерывания,
> а на реальный откликПереход на программу прерывания позволяет вот прямо там и устроить реальный отклик на событие. А если ломовым polling'ом и дергом лапок покомандно - атмега без аппаратных костылей разрулит несколько мегагерцев маханий лапками. А x86 от сотен тыщ...миллионов IRQ в секунду вообще колом встанет. Ну не заточен он на такое. Поэтому вся периферия имеет некислые буфера, DMA и прочая и стараются накопить побольше данных на 1 дерг. Знаете как у UART 16550 появился буфер? Писюшники перестали успевать дергаться на прерывания от его безбуферных предков типа 8250 и пришлось срочно рожать накопительный буфер :)
> - другими словами, надо добавлять сюда еще время обработки прерывания.
У атмеги оно на порядок ниже как правило. И тасовки регистров меньше, т.к. набор регистров человеческий, и I/O оно может рюхать в пределах _ОДНОЙ_ команды при желании, за _ОДИН_ такт, если уж совсем хардкорный поллинг/дергинг делать.
> ага) на то чтобы считать данные из порта, посчитать от него скажем синус
А это нафига?
> и выставить в другой порт,
А на цифровой порт сложно выставить что-то кроме единиц или нолей. Посчитать синус с "точностью" в 1 бит можно как делать нефиг за считанные команды (тупо сравнение влобешник). Ах, вы про что-то типа DAC? Так у большинства (если не всех) atmega его нет. Если надо крутую обработку сигналов в реальном времени - этим DSP занимаются...
> а мы вместе посмеемся, когда сравним время отклика на атмеге и на х86.
Не, ну я понимаю что сферический конь в вакууме это круто. Но вот почему-то такие "тараканы" по жизни принимают ключевые решения вида "ой, а по мнению гироскопа мы тут во что-то основательно въе, так что выпускаем подушки безопасности".
>> А ща мы вас обломим. Вспоминаем про SMI и понимаем что на типовом писюшнике x86 вообще
>> никому нифига не гарантирует,
> В исходном посте речь шла что атмега уделает х86, а не типовой писюшник.
> Это как бы две очень большие разницы. Как насчет распаянного эмбед х86,
> без каких либо биоса и прочих финтифлюшек?Ну так сферический конь в вакууме никому не интересен. Сделайте и приходите. Для начала можете забабахать эквивалент ESC (electronic speed controller) для оборотистых BLDC моторов которые в почете у авиамоделистов например. Там оно влобовую ключи дергает переключая обмотки заместо коллектора. Да еще по росту тока детектирует попадание препятствий в пропеллер, мера чтобы юзвергу руку не порубало в капусту если в пропеллер попадет.
>> А по-фи-гу: у x86 контроллер прерываний вообще внешняя фигня, и не больно какая
>> быстрая, а GPIO вообще толком нет, а пока там достучишься до периферии на шине
> Боже мой, какая безграмотность. Никакой внешний контроллер прерываний не поможет, если
> нет прерываний в самом проце (INTR/NMI).Боже мой, какая безграмотность, нас волнует время прохождения всей этой этажерки. Практическое, а не сферические кони в вакууме.
> Поставь нужные порты и задействуй INTR, если так уж хочется сравнивать
> сами архитектуры. Про скорость периферии улыбнуло - атмега сравнится
> разве что с лохматым 80386/ISA.Именно лобовой дерг лапок у атмег очень быстрый, можно менять состояние порта чуть ли не каждый такт, что вообще-то является обалденным по эффективности результатом. Какой там нафиг 80386/isa? Вы им вообще сможете дернуть лапкой на 100 наносекунд? И как это по вашему будет выглядеть? :) А у современного x86 обычно вообще нет GPIO у проца, там только всякие шины ориентированные на ломовую пропускную способность но в ущерб латентности, в надежде что кеш и прочие предсказания ветвлений вытянут. Вытягивают, но очень уж негарантированно и джиттер нехилый. Как и вообще разница в скорости выполнения, в зависимости от. Если время выполнения отличается в разы - оно отличается в разы.
> если не дошло, то объясню еще раз - х86 не используется для
> подобных задач не потому что он этого не умеет, а потому
> что overkill: дорого и неудобно.Он не используется для этой цели потому что разгонять многотонный дорожный каток до скорости 200 км/ч довольно непростое начинание. Хотя если как следует постараться и пустить его с обрыва - говорят что можно, да :)
Для SMI можно указать максимальное время выполнения обработчика, в т.ч. равное "0". Только делать этого без нужды не рекомендуется.
> Для SMI можно указать максимальное время выполнения обработчика,Если фирмварез в SMI зажмет управление себе - фиг с два ты его получишь назад в ring0 до тех пор пока фирмварез не соизволит его вернуть. И если вопрос например в том чтобы ты лично своей головой ответил если юзер вылетит через стекло и об стену убьется - врядли ты захочешь надеяться на пряморукость и честность парней из авардов и ами. Хрен бы их там знает что они там в обработчик впихнут и какие там у этого кода могут быть worst cases.
Откройте для себя значение термина "СПЕЦИФИКАЦИЯ" и многое в этом мире станет понятнее.
> Откройте для себя значение термина "СПЕЦИФИКАЦИЯ" и многое в этом мире станет понятнее.Открой мне плиз где можно скачать спецификации на обработчик SMI в award/ami/... и что именно эти господа мне изволят гарантировать относительно своего обработчика. Который я из моей системы ну совсем никак закруглить насильно не могу, даже если бы и захотел.
> У атмеги джиттер зачастую равен _нулю_ - все априори известно потактововранье - все зависит от того какая команда исполняется во время прерывания, они там не все за один такт выполняются, так что на avr это невозможно впринципе.
> вранье - все зависит от того какая команда исполняется во время прерывания,Хинт: можно еще и через поллинг работать, например. При этом мы можем _наверняка_ знать какой именно поток команд за сколько тактов выполняется. А в x86 так низзя - кеши и предсказатели ветвлений всяко джиттер внесут, независимо от прерываний и прочего.
А ещё оперативку статическую и никакого свопа.. Кстати, на тестируемых системах своп включен?
Оффтопик, но всё же: в чём и как такие няшные графички строить?
> Оффтопик, но всё же: в чём и как такие няшные графички строить?Тут - http://www.gnuplot.info
НЯШКА - это сокращено от ГОВ... или ВКУС... ?
Это удлинненние слова "Ня", которое любят российские анимешники.
Gnuplot наверное. Тут список: http://en.wikipedia.org/wiki/List_of_graphing_software
Можно еще какими-то пакетами в LaTeX-е рисовать.Но ИМХО проще использовать бек-енды типа Gnuplot через Maxima или "R":
http://www.inp.nsk.su/~baldin/DataAnalysis/index.html
http://riotorto.users.sourceforge.net/gnuplot/index.html
http://maxima.sourceforge.net/ru/documentation.html (а именно http://maxima.sourceforge.net/ru/maxima-tarnavsky-5.html)Еще есть MathGL и UDAV:
http://udav.sourceforge.net/Если интересует конкретный инструмент, которым рисовали в этой статье -- это неплохие ссылки чтобы начать поиск
Спасибо!
> Gnuplot наверное. Тут список: http://en.wikipedia.org/wiki/List_of_graphing_software
> Можно еще какими-то пакетами в LaTeX-е рисовать.Пакеты называются tikz и pgf (это связка). Выдают великолепную графику - http://www.texample.net/tikz/examples/
Ну и к ним как-то привинчен ещё через какой-то пакет построитель графиков. Самое главное же - это родное встраивание в TeX.
Ну вот, опять - графики демонстрирующие зависимость непонятно чего от хз. Автор - если ты уж решил, что эти графики наглядно тебе чего-то продемонстрировали и ты решил их вставить в текст новости, будь добр, потрать еще десяток секунд - напиши к ним подпись, объясни и остальным. А то толку от графиков практически ноль.
Второй еще можно как-то понять (распределение времени отклика по прогонам), но первый прямо таки необходимо подписать.
Вот это deadline счедулер, а не BFS, как некоторые доказывают!!!
