https://m.opennet.dev/openforum/vsluhforumID3/83989.html После почти полутора лет разработки представлена (https://lkml.org/lkml/2012/4/6/39) четвёртая версия планировщика задач SCHED_DEADLINE (https://github.com/jlelli/sched-deadline), реализующего алгоритм EDF (Earliest Deadline First), основанный на идее повышения приоритета для задач с более ранним временем завершения. SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов. <br><br><br>Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мсек в интервале 100 мсек) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержа https://m.opennet.dev/openforum/vsluhforumID3/83989.html#52 Tue, 10 Apr 2012 16:41:34 GMT &gt; вранье - все зависит от того какая команда исполняется во время прерывания, <br><br>Хинт: можно еще и через поллинг работать, например. При этом мы можем _наверняка_ знать какой именно поток команд за сколько тактов выполняется. А в x86 так низзя - кеши и предсказатели ветвлений всяко джиттер внесут, независимо от прерываний и прочего.<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#51 Tue, 10 Apr 2012 16:38:16 GMT &gt; Откройте для себя значение термина "СПЕЦИФИКАЦИЯ" и многое в этом мире станет понятнее.<br><br>Открой мне плиз где можно скачать спецификации на обработчик SMI в award/ami/... и что именно эти господа мне изволят гарантировать относительно своего обработчика. Который я из моей системы ну совсем никак закруглить насильно не могу, даже если бы и захотел.<br><br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#50 Tue, 10 Apr 2012 16:35:15 GMT &gt; Тудыть, у меня такой пинг до мыла.ру с самым паршивым реалтеком <br><br>А у меня шлен 25 см. <br>Вот скриншот - http://i35.fastpic.ru/big/2012/0410/ac/f178f24b6e8b9c37c1fce53c63c82cac.png<br>Пришлось 2 минуты потратить, чтоб циферки поменять.<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#49 Tue, 10 Apr 2012 16:28:24 GMT &gt; меж двумя хостами, по инету не более 2 мс. (или 2000 мкс.) <br><br>Тудыть, у меня такой пинг до мыла.ру с самым паршивым реалтеком и какой-то нонейм витухой. Приколись, тебя кажется развели на золоченой витухе :)<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#48 Tue, 10 Apr 2012 10:51:41 GMT Откройте для себя значение термина "СПЕЦИФИКАЦИЯ" и многое в этом мире станет понятнее.<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#47 Tue, 10 Apr 2012 01:36:20 GMT &gt; У атмеги джиттер зачастую равен _нулю_ - все априори известно потактово<br><br>вранье - все зависит от того какая команда исполняется во время прерывания, они там не все за один такт выполняются, так что на avr это невозможно впринципе.<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#46 Tue, 10 Apr 2012 01:27:28 GMT &gt; И чё?! Считаешь нормально, пиковые в 20-30 раз больше средних?!<br><br>Ну так и есть - теоретик, это вообще никого кроме тебя не волнует :) тут главное что время отклика не превышает фиксированной величины, это как погрешность прибора - никого не волнует что он может измерить намного точней своего класса - стоит у него класс точности 2.0 и этим все сказано.<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#45 Mon, 09 Apr 2012 22:22:55 GMT &gt; Для SMI можно указать максимальное время выполнения обработчика,<br><br>Если фирмварез в SMI зажмет управление себе - фиг с два ты его получишь назад в ring0 до тех пор пока фирмварез не соизволит его вернуть. И если вопрос например в том чтобы ты лично своей головой ответил если юзер вылетит через стекло и об стену убьется - врядли ты захочешь надеяться на пряморукость и честность парней из авардов и ами. Хрен бы их там знает что они там в обработчик впихнут и какие там у этого кода могут быть worst cases.<br> https://m.opennet.dev/openforum/vsluhforumID3/83989.html#44 Mon, 09 Apr 2012 22:16:15 GMT &gt; Во первых, ровно то же самое известно и для чипов х86. <br><br>Оно никогда не известно с какой либо точностью, т.к. нет никаких _гарантий_ попадания в кеш, угадывания или не угадывания ветвления и прочая. И джиттер там нефиговый сам по себе.<br><br>&gt; И то что в атмеге декларируется 3-5 тактов на переход на обработку <br>&gt; прерывания, а в х86 это может оказаться цифра 5-100 (с потолка <br>&gt; взятые цифры) ничего не означает на практике - при пересчете в <br>&gt; реальное время - на те же микросекунды, <br><br>У атмеги ее такты - это с момента когда на лапке изменились условия и до момента когда ядро проца отдаст руль обработчику прерываний, который этим вопросом озадачится. Потому что контроллер GPIO вплотную к ядру, сразу его и дергает. А у x86 пока там что-то где-то по хрензнаеткаким шинам из своих дербеней отсигналит что тут у нас вообще прерывание прилетело - рак на горе свистнет. <br><br>Что x86 может "сам по себе" видно на примере программаторов на LPT/COM порт где x86 относительно "напрямую дергает IO-лапками". В современных реа