The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлена четвёртая версия планировщика задач SCHED_DEADLINE для ядра Linux

08.04.2012 14:26

После почти полутора лет разработки представлена четвёртая версия планировщика задач SCHED_DEADLINE, реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времени (deadline). SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов.

Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мсек в интервале 100 мсек) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.

Ключевым изменением нового выпуска SCHED_DEADLINE является обеспечение поддержки PREEMPT_RT ветки ядра Linux (3.2.13-rt23) c реализацией режима реального времени, которая используется в real-time редакциях промышленных Linux-дистрибутивов MontaVista, Red Hat и Novell. Несмотря на то, что патчи теперь базируются на ветке PREEMPT_RT, продолжается работа по продвижению разработки в состав основного ядра Linux. Параллельно поддерживается ветка SCHED_DEADLINE2 с патчами для основной ветки ядра Linux.

Кроме того, в новой версии SCHED_DEADLINE улучшен алгоритм выбора очередей выполнения (runqueue) для обеспечения динамической миграции задач на многопроцессорных системах. В частности, реализован эквивалент cpupri для задач, для которых выбран метод планирования deadline (cpudl). Из планов на будущее отмечается реализация средств управления пропускной способностью на основе cgroup. Вместо планирования на основе приоритета и предельного времени (deadline) рассматривается возможность оперирования пропускной способностью.

Дополнительно можно отметить публикацию результатов первого года работы тестовой инфраструктуры для оценки качества работы Linux при выполнении задач реального времени и для постоянного наблюдения за изменением характеристик RT-Linux при выполнении различных нагрузочных сценариев. Целью проекта является организация регулярных проверок новых Linux-ядер и RT-патчей в приближенных к реальным условиях и на широком спектре различных аппаратных платформ. В настоящее время тестовая инфраструктура включает в себя 50 различных аппаратных платформ. Работа тестовой фермы организована консорциумом OSADL (Open Source Automation Development Lab), развивающим решения на базе Linux для промышленной встраиваемой техники и курирующим разработку real-time патчей PREEMPT_RT к Linux ядру.

За год тестирования была накоплена информация о выполнении 73 миллиардов тестовых циклов. Все данные наглядно визуализированы в виде 3D-графиков. Использование логарифмической шкалы позволяет выделить в виде пика даже единичные изменения отзывчивости системы.



  1. Главная ссылка к новости (https://lkml.org/lkml/2012/4/6...)
  2. OpenNews: В ядро Linux может быть включен планировщик реального времени
  3. OpenNews: Третья версия планировщика задач SCHED_DEADLINE для ядра Linux
  4. OpenNews: Для Linux представлен планировщик задач BLD (Barbershop Load Distribution)
  5. OpenNews: Консорциум OSADL представил ферму для тестирования RT-Linux на различном оборудовании
  6. OpenNews: Представлен первый тестовый набор RT-патчей для ядра Linux 3.0
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/33559-sched_deadline
Ключевые слова: sched_deadline, sheduler, linux, realtime
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 16:20, 08/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Новость не читал, скажите сразу - лучше BFS или нет?
     
     
  • 2.2, pavlinux (ok), 16:23, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –7 +/
    BFS - уже говно, не, конечно если у тя Pentium II 433, то пойдёт.
     
     
  • 3.31, loper (ok), 22:43, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Комменты не читал, но первые два понравились)
     
  • 2.16, Аноним (-), 18:01, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    это не для чукчей, т.е. которые не читатели
     

  • 1.3, Аноним (-), 16:25, 08/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что сейчас тогда самое нормальное, на свежем железе?
     
     
  • 2.6, pavlinux (ok), 16:37, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дефолтный - CFS.
     

  • 1.4, fufufuu (?), 16:33, 08/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >основанный на идее повышения приоритета для задач с более ранним временем завершения

    как такое вообще возможно? кто может сказать сколько будет выполняться та или иная задача, это почти случайный процесс

     
     
  • 2.9, pavlinux (ok), 17:09, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По этому он и называется DEADLINE. И вообще, тут неправильно перевели,
    не "задач с более ранним временем завершения", а с большим временем в очереди к процессору.
    и ваще, там не время, а индексы, ну и как в жизни - у кого больше индекс тот и папа! :)

      

     
  • 2.11, Аноним (-), 17:16, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >  кто может сказать сколько будет выполняться та или иная задача,
    > это почти случайный процесс

    Ну да, щазззз. Собственно задача шедулера в том и состоит чтобы вовремя вклиниться, отобрать и поделить [время CPU, так как задумано приоритетами и прочими настройками].

    Какие к черту случайности? Это вам не Win 3.0 с кооперативной многозадачностью.

     
  • 2.24, umbr (ok), 19:19, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если время выполнения задачи "почти случайный процесс" - то реалтайм и рядом не стоял.
     

  • 1.5, pavlinux (ok), 16:36, 08/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Можно чуток расстрою розовую новость!

    1. DEADLINE, как самостоятельный планировщик, туповат, надо руками выставлять приоритеты.  
    2. RT_PREEMPT ну ваще ни разу не HARD REALTIME
    3. Редкие, но запоры в латентности, бывают до 2000-3000 us, при среднем показателе 50-80 us
    4. Для полного реалтайм-кайфа, надо напрочь сносить всё управление питанием, от idle в процах до скринсейвера и DPMS монитора.

     
     
  • 2.7, Аноним (-), 17:00, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, но учти что с течением времени количество ядер/процессоров в системе и ее вычислительные способности только растут (если, конечно, этот прирост не убивать в нуль используя трэш навроде .net,mono, python, ... ).
     
  • 2.12, Аноним (-), 17:25, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > 2. RT_PREEMPT ну ваще ни разу не HARD REALTIME

    HARD 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 диким отрывом.

     
     
  • 3.13, pavlinux (ok), 17:40, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Ну загарантируй 4000us если ты уверен что за этот предел никогда не
    > выскочит, получишь hard realtime хоть и слегонца эстонский :).

    Хардкорные реалтаймы дают погрешность 5% (как на резисторы с золотой полоской :))
    А среднее 80 us и пики до 4000 - это не хардкор, это групповуха.

    Кстати, знаешь как они там тесты делают?! Запускают latency_test, cyclictest и курят 24 часа.
    Попробуй запусти во время этого теста find / -exec md5sum {} \;
    тут реалтайм и кончится :)  

    > ... примитивное фирмваре на 1 кило в хилой 8-битной атмеге на ее скромных 10-20 МГц
    > уделает x86 c диким отрывом.

    Апчём и речь.

     
     
  • 4.28, sasa (??), 21:03, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кстати, знаешь как они там тесты делают?! Запускают 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

     
     
  • 5.29, pavlinux (ok), 21:34, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Чёй-то говёненький рылтайм на ваши ARMах code cyclictest -t4 -p 99 -n -i 10... большой текст свёрнут, показать
     
     
  • 6.32, EuPhobos (ok), 00:34, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    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 26976          

    T: 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:      54

    model name      : AMD Phenom(tm) II X4 955 Processor
    ---
    Не знаю нормально ли, но на серваке крутятся 3 игровых CS1.6 и 2 игровых CS Source.
    И задроты ещё жалуются на "плохую стрельбу".. Я сам не играю, поэтому мне трудно понять что это значит %) но по показателям, я так понял, процессор успевает..

     
     
  • 7.33, pavlinux (ok), 03:17, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А ты вот такую сетевушку, за 400€, себе, задротам и провайдерам купи :)
    http://www.prosoft.ru/products/brands/hilscher/374263.html
    и коммутаторы тоже, минимум с фильтрацией TTL и IGMP, бродкасты запретить,
    автосоглосования, сетевые буфера уменьшить, витую STP cat. 6e c позолотой всем.  

    Не знаю, правда иль нет, но пишут, что народ добивался задержек,
    меж двумя хостами, по инету не более 2 мс. (или 2000 мкс.)


     
     
  • 8.49, Аноним (-), 20:28, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Тудыть, у меня такой пинг до мыла ру с самым паршивым реалтеком и какой-то ноней... текст свёрнут, показать
     
     
  • 9.50, pavlinux (ok), 20:35, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А у меня шлен 25 см Вот скриншот - http i35 fastpic ru big 2012 0410 ac f178... текст свёрнут, показать
     
  • 7.43, Аноним (-), 23:50, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И задроты ещё жалуются на "плохую стрельбу"..

    Дядь, микросекунды на фоне даже 1 мс пинга не роялят. Пусть задроты проверяют свой трейсроут до сервака и вообще свое соединение :). А то поразвелось будаков чуть ли не на жпрс, которым все виноваты. Кроме их кривого интернета.

     
  • 6.46, sasa (??), 05:27, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И чё?! Считаешь нормально, пиковые в 20-30 раз больше средних?!

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

     
  • 4.34, Аноним (-), 04:19, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хардкорные реалтаймы могут быть и буквально по тактам проца вычислены для просты... большой текст свёрнут, показать
     
     
  • 5.41, pavlinux (ok), 16:06, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Я только 1 не понял: на воооон том графике вся шкала до
    > 400 и пики только в начала... может ты что-то делаешь не
    > так?

    Железка корявая, Atom D425 и сетевуха Реалтык 8169 (c фирмварью),
    как трафик начинает идти, все, суши ласты, реалтайм исчезает. :)    

    > А ты это делал на кернеле с preempt rt и прочими ништяками?

    Угу...

     
  • 3.17, антоним (?), 18:07, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Если тебе надо предсказуемость до единиц микросекунд, x86 вообще бяка. Джиттер времени
    > одной и той же операции на х86 будет мама не горюй, в зависимости от cache hit/cache
    > miss, успеха предсказания бранчей и прочая. Оно такое ориентировано на "скорость
    > молочения вообще" а не "предсказуемое время реакции". По второму параметру примитивное
    > фирмваре на 1 кило в хилой 8-битной атмеге на ее скромных 10-20 МГц уделает x86 c диким
    > отрывом.

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

     
     
  • 4.22, pavlinux (ok), 19:17, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > ври, но не завирайся.

    Мужики, давайте всё ж рассматривать RT как программно-аппаратную пару.
    А то 4-ядерный Пень, в фоне играющий Mplayer, на втором мониторе Oil Rush,
    куча народу в аське, в скайпе, фаерфокс иль гуглохром с 20 табами и флешем,
    пишушейся на флешку дамп блюрея, торрент с 200 пирами, обеспечат вам полный
    анитреалтайм по всем подсистемам.
      Иль атмега с одним процессом, которая шлёт сигналы размером 1 байт,
    раз в 10 миллисекунд на привод станка.

     
  • 4.35, Аноним (-), 04:45, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У атмеги джиттер зачастую равен _нулю_ - все априори известно потактово, так что... большой текст свёрнут, показать
     
     
  • 5.36, антоним (?), 13:05, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > У атмеги джиттер зачастую равен _нулю_ - все априори известно потактово, так что можно
    > предсказать все с точностью до долей микорсекунды. В том числе и за сколько тактов оно
    > на событие на лапке среагирует.

    Во первых, ровно то же самое известно и для чипов х86. И то что в атмеге декларируется 3-5 тактов на переход на обработку прерывания, а в х86 это может оказаться цифра 5-100 (с потолка взятые цифры) ничего не означает на практике - при пересчете в реальное время - на те же микросекунды, этот джиттер съедатся разницей частот. Во-вторых, джиттер надо учитывать не на переход на программу прерывания, а на реальный отклик - другими словами, надо добавлять сюда еще время обработки прерывания. Вот ты посчитай полное время отработки (в микросекундах, ага) на то чтобы считать данные из порта, посчитать от него скажем синус и выставить в другой порт, а мы вместе посмеемся, когда сравним время отклика на атмеге и на х86.

    > А ща мы вас обломим. Вспоминаем про SMI и понимаем что на типовом писюшнике x86 вообще
    > никому нифига не гарантирует,

    В исходном посте речь шла что атмега уделает х86, а не типовой писюшник. Это как бы две очень большие разницы. Как насчет распаянного эмбед х86, без каких либо биоса и прочих финтифлюшек?

    > А по-фи-гу: у x86 контроллер прерываний вообще внешняя фигня, и не больно какая
    > быстрая, а GPIO вообще толком нет, а пока там достучишься до периферии на шине

    Боже мой, какая безграмотность. Никакой внешний контроллер прерываний не поможет, если нет прерываний в самом проце (INTR/NMI). Поставь нужные порты и задействуй INTR, если так уж хочется сравнивать сами архитектуры. Про скорость периферии улыбнуло - атмега сравнится разве что с лохматым 80386/ISA.

    если не дошло, то объясню еще раз - х86 не используется для подобных задач не потому что он этого не умеет, а потому что overkill: дорого и неудобно.

     
     
  • 6.39, антоним (?), 15:41, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я, в принципе, к тому, что если не использовать навороты современных х86 и добавить периферию, тогда то, что получится, можно назвать аналогом 80х51, разогнанным до гигагерца. Если на равных частотах атмега и заруливает 8051, то тут разница на 2 порядка не в пользу атмеги.
     
  • 6.40, pavlinux (ok), 15:58, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > без каких либо биоса и прочих финтифлюшек?

    Сoreboot!

     
  • 6.44, Аноним (-), 02:16, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Оно никогда не известно с какой либо точностью, т к нет никаких _гарантий_ попа... большой текст свёрнут, показать
     
  • 5.38, Ваня (??), 13:43, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для SMI можно указать максимальное время выполнения обработчика, в т.ч. равное "0". Только делать этого без нужды не рекомендуется.
     
     
  • 6.45, Аноним (-), 02:22, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Для SMI можно указать максимальное время выполнения обработчика,

    Если фирмварез в SMI зажмет управление себе - фиг с два ты его получишь назад в ring0 до тех пор пока фирмварез не соизволит его вернуть. И если вопрос например в том чтобы ты лично своей головой ответил если юзер вылетит через стекло и об стену убьется - врядли ты захочешь надеяться на пряморукость и честность парней из авардов и ами. Хрен бы их там знает что они там в обработчик впихнут и какие там у этого кода могут быть worst cases.

     
     
  • 7.48, Ваня (??), 14:51, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Откройте для себя значение термина "СПЕЦИФИКАЦИЯ" и многое в этом мире станет понятнее.
     
     
  • 8.51, Аноним (-), 20:38, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Открой мне плиз где можно скачать спецификации на обработчик SMI в award ami ... текст свёрнут, показать
     
  • 5.47, sasa (??), 05:36, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > У атмеги джиттер зачастую равен _нулю_ - все априори известно потактово

    вранье - все зависит от того какая команда исполняется во время прерывания, они там не все за один такт выполняются, так что на avr это невозможно впринципе.

     
     
  • 6.52, Аноним (-), 20:41, 10/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > вранье - все зависит от того какая команда исполняется во время прерывания,

    Хинт: можно еще и через поллинг работать, например. При этом мы можем _наверняка_ знать какой именно поток команд за сколько тактов выполняется. А в x86 так низзя - кеши и предсказатели ветвлений всяко джиттер внесут, независимо от прерываний и прочего.

     
  • 2.21, umbr (ok), 19:17, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А ещё оперативку статическую и никакого свопа.. Кстати, на тестируемых системах своп включен?
     

  • 1.8, Ivan (??), 17:01, 08/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Оффтопик, но всё же: в чём и как такие няшные графички строить?
     
     
  • 2.10, pavlinux (ok), 17:10, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Оффтопик, но всё же: в чём и как такие няшные графички строить?

    Тут -  http://www.gnuplot.info

    НЯШКА - это сокращено от ГОВ... или ВКУС... ?

     
     
  • 3.25, Зенитар (?), 19:34, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это удлинненние слова "Ня", которое любят российские анимешники.
     
  • 2.20, skb7 (ok), 19:07, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    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/

    Если интересует конкретный инструмент, которым рисовали в этой статье -- это неплохие ссылки чтобы начать поиск

     
     
  • 3.26, Ivan (??), 19:37, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо!
     
  • 3.30, Vkni (ok), 21:55, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Gnuplot наверное. Тут список: http://en.wikipedia.org/wiki/List_of_graphing_software
    > Можно еще какими-то пакетами в LaTeX-е рисовать.

    Пакеты называются tikz и pgf (это связка). Выдают великолепную графику - http://www.texample.net/tikz/examples/

    Ну и к ним как-то привинчен ещё через какой-то пакет построитель графиков. Самое главное же - это родное встраивание в TeX.

     

  • 1.14, антоним (?), 17:48, 08/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну вот, опять - графики демонстрирующие зависимость непонятно чего от хз. Автор - если ты уж решил, что эти графики наглядно тебе чего-то продемонстрировали и ты решил их вставить в текст новости, будь добр, потрать еще десяток секунд - напиши к ним подпись, объясни и остальным. А то толку от графиков практически ноль.
     
     
  • 2.15, антоним (?), 17:53, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Второй еще можно как-то понять (распределение времени отклика по прогонам), но первый прямо таки необходимо подписать.
     

  • 1.37, Аноним (-), 13:08, 09/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот это deadline счедулер, а не BFS, как некоторые доказывают!!!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру