поток и реальное время

как мне объяснить ОС, что задачи второго потока являются ПЕРВОСТЕПЕННЫМИ?

niceness?

как я могу быть уверенным в том, что данные не потеряются, что ОС всегда будет выделять процессорное время для этого потока?

Никак. Ванильный GNU/Linux не является ОСРВ.

подозреваю, что мне нужен режим реального времени, но это ведь линукс?

Есть форки линукса с режимом реального времени.

sched_getscheduler, SCHED_FIFO и 99-й приоритет

Есть форки линукса с режимом реального времени

разве ядро-rt не решает эту проблему

разве ядро-rt не решает эту проблему

Проблему «первостепенности», как это сформулировал ТС, решает и обычное, правильным образом сконфигурированное ядро.

pcap будет терять пакеты, если ты не будешь успевать их обрабатывать.

ну вот и хочу «застраховаться » от этого. спасибо за ответы и добавляя к вышеуказанным коментам: слышал что в версиях ядра выше 3.0 есть встроенная поддержка реального времени. кто сталкивался?

А ты уверен, что тебе нужно реальное время? Тебе нужно как-то очень быстро реагировать на входящие данные или просто их все обрабатывать, без жёстких рамок на время реакции?

и как можно использовать распарралеливание? даст ли это рез-т?

ну если я правильно понимаю термин РВ-то да. дело в том, что данные приходят по 5000 тысячам состояний прибора, т.е. в i-ый момент времени пришло 1-ое состояние, в i+1-ый пришло 2-ое состояние и тд. чтобы обработка была адекватной, важно не потерять часть данных. по идее сделал пробник на винде и он работает, мощи процессора пока хватает, но дело в том, что будут еще навороты по интерфейсу, визуализации (сотни объектов поверх сцены отрисовки). вот и думаю сижу. так то прямо жесткое РВ не требуется, интуитивно чувствую будет достаточно мягкого, встроенного в ядро линукса, но с ним дело не имел еще

по поводу «niceness?» это я понимаю утилита, а программно (в коде указать) можно подобное сделать? т.е. сказать ОС, чтобы она сосредоточила все внимание на определенном приложении.

чтобы обработка была адекватной, важно не потерять часть данных.

Они не потеряются благодаря буферизации. Реальное время тут не при чём.

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

понятно, а что порекомендуете насчет повышение приоритета приложения? чтобы ОС отдала максимум процессорного времени опредленному приложению?

Кстати, мне намедни наш программист говорил, что стоит мне одну хрень, которая с ПЗСки по USB читает данные, выставить в rt-приоритет. Я правда, по скромности тупости своей у него подробности не узнал, но к nice это отношения не имеет, там что-то напрямую связанное с планировщиком (т.е. эта задача делается невыгружаемой и высокоприоритетной, чтобы пока она не отдубасится, планировщик на ее ядро CPU ничего не вешал).

Может, кто в курсе, ЩЦТ?

как правильно конфигурировать ядро?

Товарищи программеры, не это?

static void
__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio)
{
        BUG_ON(p->se.on_rq);

        p->policy = policy;
        p->rt_priority = prio;
        p->normal_prio = normal_prio(p);
        /* we are holding p->pi_lock already */
        p->prio = rt_mutex_getprio(p);
        if (rt_prio(p->prio))
                p->sched_class = &rt_sched_class;
        else
                p->sched_class = &fair_sched_class;
        set_load_weight(p);
}

Переменную /proc/sys/kernel/sched_rt_runtime_us выставь в значение /proc/sys/kernel/sched_rt_period_us.

Настрой свою программу, как я написал в первом комменте.

И хорошо, когда ядро сконфигурировано с поддержкой Preemptible Kernel (Low-Latency Desktop).

понятно, а что порекомендуете насчет повышение приоритета приложения? чтобы ОС отдала максимум процессорного времени опредленному приложению?

Для начала нужно продумать и реализовать некую схему наблюдения за потерями пакетов и влиянием настроек на производительность. Т.е. хорошо бы без каких-либо настроек производительности зарегистрировать эти самые потери, чтобы ответить на вопрос, а нужно ли что-то менять? Кроме того, делать какие-либо настройки, не измеряя на практике, как они влияют на нужные тебе параметры можно только для поднятия своего ЧСВ. Далее, если нужно, я вижу 2 варианта:

1. Повысить приоритет нужному процессу. И снова проверить, как это влияет на параметры производительности (в том числе всей системы) и на потери.

2. Сделать Affinity всех процессов (кроме тех ядерных, которые не дадут это сделать) на одни процессорные ядра, а нужный тебе процесс на другие. Так чтобы никакой (почти, кроме ядерных) процесс не забирал CPU у твоей системы. Сделать обработку прерываний ядрами из первой группы. Снова провести измерения, как это повлияло на систему и при каких условиях остались потери.

Если это не поможет, ну тогда не знаю...

P.S. Повторю еще раз: делать какие-либо настройки без измерения того, как они влияют на нужные параметры системы - бесполезная трата времени.

посмотри как сделано ettercap
он у меня обрабатывал на дохленькой машинке весь трафик от 80 компов и успевал его весь разобрать, правда ему рут права нужны были

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

Что нибудь этакое:

int set_rt_sched( int prio )
{
  struct sched_param sp;
  if( prio == 0 )  return( -1 );

  sp.sched_priority = prio;
  
  if( sched_setscheduler( 0, SCHED_FIFO, &sp ) )
  {
    perror( «ошибка sched_setscheduler()» );
    return( -1 );
  }

  return( 0 );
}