Таймер

Internal structure and you change requests/suggestions
  • Ну, я не предлагаю потоки быстрее переключать, но раз уж нужно для таких приложений как видеоплеер.
  • Системное время крепко завязано на 100Гц.
    1кГц для десктопных приложений - слишком много, а для реалтайма - слишком мало.

    Имхо идеально было бы закрутить второй таймер для RT и критичных по времени задач, как предлагал VaStaNi,
    причем прерывание от этого таймера сделать нежестко фиксированным или даже вообще непериодическим (перезапускаемый интервальный таймер).

    А еще неплохо было бы обсудить "совсем другую" фичу - обработку прерывания без переключения задачи.
    Если по таймеру надо всего-то прибавлять к чему-нибудь единицу, или вывести чего-нибудь в порт, или обновить буфер - зачем перегружать весь контекст задачи?
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh: я сужу, исходя из опыта использования linux - 1кГц - идеален для десктопа с низкой задержкой гуя. А вот обработка прерывания без переключения задачи - это действительно интересная идея. Много ли таких прерываний?
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:13 pm, edited 1 time in total.
  • art_zh wrote: А еще неплохо было бы обсудить "совсем другую" фичу - обработку прерывания без переключения задачи.
    Если по таймеру надо всего-то прибавлять к чему-нибудь единицу, или вывести чего-нибудь в порт, или обновить буфер - зачем перегружать весь контекст задачи?
    Я как то всегда думал, что все обработчики прерывания не меняют контекст. Ведь все потоки в системе равноправны и коду в Ring0 без разницы. Он имеет доступ к любой области кода и данных ядра.
  • VaStaNi wrote:Про мобильный рынок устройств и наличие массу аппаратных таймеров ARM я бы советовал некоторым "покурить" и подумать.
    Имеющий уши - да услышит!
    Стас ты опять пытаешься объять необъятно и впихнуть невпихуемое. Ну, какой к черту ARM? У нас одна целевая платформа, ну может две (x86 и EM64T). Зачем опять создавать винегрет - не будем мы плодить второй Линукс.
  • Mario
    сейчас таймер переключает задачи.
    Смена контекста задачи занимает очень много времени причем "очень много" - это довольно точный количественных показатель. Порядка микросекунды только прямых задержек, плюс хз сколько непрямых (сломанный кэш и контекст CPU, новая адресная таблица, новая копия той же портовой карты, и т.п.).
    Для 100Гц это вполне приемлемо, десктопные приложения это совсем не замечают.

    Допустим, мы добавили в ядро новый таймер - только для время-критичных задач. И повесили на него одно "редкое, но толстое" приложение (например, видеопроигрыватель, запросивший РТ-прерывание с частотой смены кадров 15Гц), и один шустрый бездрайверный фреймграббер USB-камеры, которому всего-то нужно 87300 раз в секунду скопировать очередную строчку пикселей из кольцевого буфера в кадровый.

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

    // про вирусы и говнокод -- да, вижу. И что с ними делать при наличии такой дыры - не знаю.
  • Не-не-не! Я то подразумевал поднять частоту таймера, а скорость переключения задач оставить все те же 100 Гц. Насколько я понял проблемы то у видеоплеера совсем не от скорости переключения задач, а собственно нужен именно таймер позволяющий "тикать" быстрее чем 100 Гц.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:13 pm, edited 1 time in total.
  • Теоретические изыскания хороши тем, что красивы. Однако можно так вечно теоретизировать и ничего не сделать. Я практик и решаю проблемы по мере поступления. И потом я уже который раз говорю, что до некоторых идей надо дозреть. Вот занимается человек одним и тем же с десяток лет - ясен пень, что он в этом собаку съел, но ожидать то же самое от всех его читающих он не вправе. Лично когда я о чем-то пишу, я пишу со злым умыслом - сделать это в кратчайшие сроки и если тема не на все 146% мне известна (все ведь могут ошибаться? или бывают люди которые не ошибаются?) я прошу подсказать. Заниматься теоретическими изысканиями из чувства прекрасного мне не досуг.
  • Теоретические изыскания нужны,
    хотя бы чтоб не браться очертя голову за дурную работу, а прикинуть фифект для начала.

    Планировщик "в кратчайшие сроки", не имея четкой цели и плана, никак не напишешь.
  • Так-так... мы обсуждаем таймер или планировщик? Давайте определимся уже, а то каждый раз куда не сунься в винегрет все превращать любите.

    З.Ы. А потом придет Сан Саныч и в очередной раз скажет свое "Фи! Говно эта ваше Колибри! И главный пиздабол у вас тоже говно!" - меня это подзаебывает честное слово.
  • timer --> scheduler

    какой смысл в смене частоты, если ее обработка по факту останется той же самой, только треску от переключателя прибавится?
  • Who is online

    Users browsing this forum: No registered users and 2 guests