LINUX.ORG.RU

Линукс и реальное время или почему время идёт назад ?


0

0

Что такое ОС реального времени ? Вопрос сложный и недонозначный. Говорят о "жёстком" и "мягком" реальном времени, спорят и терминологии и определениях. ОК, пусть будет так. Но, надеюсь, никто не будет спорить с тем, что в ОС, претендующей называться ОС реального времени, время назад идти не может. А вот линуксе может. Сейчас расскажу, как это проявлется.

Нужно синхронизировать время. Получаем с источника точного времени время, которое, допустим, меньше локального. Надо потихоньку отвести время назад. Для этого говорим tickadj 9000, к примеру. Согласно всей документации после этого время должно идти медленнее, каждое прерывание должно прибавлять меньше времени к счётчику. Итого за определённое количество времени мы плавно и прорачно для приложений синхронизируемся. Какбы не так. Линукс вместо этого потихоньку маленькими шажочками отводит часы назад. Как это проверяется - есть программа, которая постоянно печатает показания времени и на этой рапечатке очень хорошо видно, как Линукс двигает время назад. Исходный код приведу ниже. Как проверить ? Говорим tickadj 9000, говорим что-то типа my_prog > log.log. Ждём несколько секунд, ^C, смотрим log.log, ищем там знак минус ("-"). Находим, пытаемся понять, почему время идёт назад.

Что же это получается, дорогие товарищи ? Как же оценивать маленькие задержки прикажите ? Счётчик uptime слишком грубый, нужно до сотни микросекунд точнось. Всё больше и больше убеждаюсь, что никто никогда Линукс для серьёзных примениний использовать даже не пробовал, честное слово.


# include <sys/timeb.h>
# include <stdio.h>
# include <time.h>
# include <sys/time.h>


__inline__ unsigned long long int rdtsc()
{
	unsigned long long int x;
	__asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
	return x;
}

unsigned long long GetCurrentTime(void)
{
	static struct timeb tt;
	unsigned long long result;
	
	static struct timeval ttt;
	struct timezone tz;
	unsigned long long int r;
	
	ftime(&tt);
	
	int rv;
	
	rv = gettimeofday(&ttt, &tz);
	
	
	r = rdtsc();
	
	printf ("++%d %d %d %d %d %1.0f \n", rv, ttt.tv_sec, ttt.tv_usec, tt.time, tt.millitm, (double)r);
	
	result=(unsigned long long)((unsigned long long)ttt.tv_sec/*time(&unused)*/ * (unsigned long long)1000000)+(unsigned long long)ttt.tv_usec;
	
	return result;
}


void usleep_my (unsigned int ms)
{
	struct timespec req;
	
	
	if (!ms) return;
	
	req.tv_sec=ms/1000;
	req.tv_nsec=(ms-req.tv_sec*1000)*1000000;
	
	nanosleep(&req, NULL);
}

int main (void)
{
	
	unsigned long long t1, t2;	
	
	
	t1 = GetCurrentTime();
	
	while (1)
	{
		//usleep_my (1);
		t2 = GetCurrentTime();
		//if ((t2-t1) <= 0)
		printf ("%2.1f \n", (double)(t2-t1));
		printf ("%d \n", (t2-t1));
		
		t1 = t2;
	}
}

lenin
() автор топика

The tickadj program reads, and optionally modifies, several timekeeping-related variables in older kernels that do not have support for precision ttimekeeping, including HP-UX, SunOS, Ultrix, SGI and probably others. Those machines provide means to patch the kernel /dev/kmem. Newer machines with precision time support, including Solaris, Tru64, FreeBSD and Linux (with PPSkit patch) should NOT use the program.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

А что же тогда юзать, когда нужно плавно и прозрачно отвести время назад ? Точнее, не отвести время назад, а замедлить ход времени ? Кстати, это сообщение на англицком вырезано из другого tickadj, линуксовый даже ключи от этого хелпа не понимает.

lenin
() автор топика
Ответ на: комментарий от lenin

lenin:

> А что же тогда юзать...

Я не специалист в этом вопросе. Наверное, руками adjtimex дергать (там же тики в 9000 поставить можно, опция-t), посмотри на опции, их там масса -- тебе, наверное, надо полями статуса поиграть, опция -s, чтобы запретить синхронизацию.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> руками adjtimex дергать

Действует абсолютно аналогично. Я, вообще-то, его и юзаю, про tickadj рассказал для того, чтобы было проще описать проблему. Получилось наоборот.

lenin
() автор топика
Ответ на: комментарий от lenin

Вышла новая OPERA

Попробуй расширение rtai. Но я с ним не работал. По отзывал example не стабильные. В инете пишут, о реальных единичных industrial реализациях.

binr ★★
()
Ответ на: комментарий от anonymous

Вышла новая OPERA

Не знаю, о чём идёт речь.

binr ★★
()

А то! В бирюльки играемся...
Ленин, когда же ты осчастливишь нас своим отсутствием?

Zulu ★★☆☆
()
Ответ на: комментарий от lenin

lenin:

> Действует абсолютно аналогично.

Что? Чему?

"абсолютно аналогично" -- опция -t. Я ж про -s говорил, вроде...

Но, еще раз повторюсь, я сам с этим никогда не возился.

Die-Hard ★★★★★
()

страаааное у тебя понятие о real time системах и о их применении... о каждом обработанном прерывании ты тоже в лог писать будешь?

Pi ★★★★★
()

Кстати, да, Pi прав -- поднятый тобой вопрос никакого отношения к системам реального времени не имеет.

Но сам по себе вопрос (если проигнорировать эмоции) вполне содержателен и интересен. Я на него ответить не могу. Думаю, погуглив часок - другой, ты без труда найдешь ответ.

Только учти, что Линукс обычно, в отличие от Венды, не выключают, уходя на обед, так что проблема с синхронизацией всех системных часов актуальна -- думаю, отсюда и все твои проблемы (просто в Венде по умолчанию, видимо, нету никаких синхронизаций в силу неактуальности).

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

network time protocol

Сам доки не читал, FreeBSD-ник утверждает, что его машина синхронизируется через inet с точностоью до 6-го знака после запятой. Сам я в этот бред не верю, т.к. немного секу в этой теме. Но возможно софт действителдьно там чё нить притормаживает и прочее, т.е. както влияет на системное время?

В общем надо читать доки, смотреть исходники. Успехов!

binr ★★
()
Ответ на: комментарий от binr

> network time protocol

Cоздатели этого говна могут убить себя c абсолютно чистой совестью. Я могу написать целый трактат о том, какое NTP гавно, как сам протокол, так реализация его в ntpd, но сейчас я этого делать не хочу, потом может быть.

> Но возможно софт действителдьно там чё нить притормаживает и прочее, т.е. както влияет на системное время?

Согласно докам, оно работает через аналогично tickadj. Но в линуксовые доки я давно не верю. Можно, конечно, поэксперементипровать, но я эже стока говна с эти ntpd наелся, что возвращаться к этому меня вряд-ли что заставит.

lenin
() автор топика
Ответ на: комментарий от Die-Hard

> Думаю, погуглив часок - другой, ты без труда найдешь ответ.

Я а уверен, что не найду ответ ни погуглив ни момучав тутошную публику, ни каким либо иным способом. Совесть типа очищаю на тему, что сделал всё, что мог.

lenin
() автор топика
Ответ на: комментарий от Die-Hard

> "абсолютно аналогично" -- опция -t. Я ж про -s говорил, вроде...

Как же любят линуксоиды говорить, сами никогда не делав то, что советуют. Segmentation fault выдаёт adjtimex с ключём -s.

lenin
() автор топика
Ответ на: комментарий от Pi

А это к чему сказано ? Мне нужно мрять время между двумя событиями всего лишь. Время маленькое, 100мкс - 1 мс. Периодически линуксовые функции мне выдают такое время, что время между событиями у меня получается отрицательное. Как это воспринимать и что делать ?

lenin
() автор топика
Ответ на: комментарий от lenin

2lenin:

> Я а уверен, что не найду ответ ни погуглив ни момучав тутошную публику, ни каким либо иным способом. Совесть типа очищаю ...

Собственно, я не удивлен такой реплике с твоей стороны...

Может, кто подскажет решение, так что топик прикрывать пока не будем -- надеюсь, в этот форум ходят (по большей мере) личности адекватные.

Die-Hard ★★★★★
()
Ответ на: комментарий от Zulu

> А то! В бирюльки играемся...

Ну а во что же ещё можно играться на "ОС", которая время назад считает.

lenin
() автор топика
Ответ на: комментарий от lenin

> ты серьёзно считаешь, что я не гуглил перед тем, как сюда написать ?

Ну, значит, больше ничего уже не поможет. Завязывай с этим делом...

Die-Hard ★★★★★
()
Ответ на: комментарий от lenin

не путай веник с метлой: задача рил-тайм ОС - отреагировать на прерывание в течение жёстких временых рамок. всё: больше требований нет. есть не малое количество рил-тайм систем, где времени нет как такового вообще. там просто нет системного времени, скажем системы на одной AVR - они мгновенно реагируют на прерывания и имеют полноценное preemtive ядро. так по твойму там время не идёт вперёд? ужас, и в логи нечего писать;) нет, сударь, мы все стареем. А время которым ты пытаешься оперировать служит для ушастых юзеров - не более чем трее висеть или в логах апача светиться.

как реализовано замедление времени - другой вопрос, не имеющий общего с RTOS

Pi ★★★★★
()
Ответ на: комментарий от lenin

Если вы напишите трактат на эту тему, то будет здорово, нужно и полезно. Напишите пожалуйста в этой ветке проблему, которую генерит ntp для пользователя или программёра. Чтоб в будущем не особенно с ним епасса.

binr ★★
()
Ответ на: комментарий от binr

binr:

Угу, по воробьям палить, пушка -- лучший инструмент. Можно еще вручную Линух подправить под свои нужды...

Легче, все же, разобраться с /etc/adjtime

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Привет всем

> Легче, все же, разобраться с /etc/adjtime

Между прочим, не попсовая вещь ни фига... Главное не допускать к бивису другие програмульки.

Lego_12239 ★★
()
Ответ на: комментарий от lenin

> Мне нужно мрять время между двумя событиями всего лишь. Время маленькое, 100мкс - 1 мс. Периодически линуксовые функции мне выдают такое время, что время между событиями у меня получается отрицательное. Как это воспринимать и что делать ?

для непатченных ядер <2.6.16 на уровне пользователя это абсолютно не реально. если вы получили 'обратный ход времени' измеряя подобные промежутки - то это вполне нормальная хоть и неприятная ситуация. просто Вы видимо пытаетесь оперировать величинами меньшими чем погрешность таймеров. По этому поводу есть пояснения в man nanosleep (BUG). В полях tv_usec,tv_nsec всё что меньше 10ms можно считать мусором. Выход: патчить текущее ядро и читать документацию в патче либо переходить на последнее - в нем всё нужное по идее есть.

IMHO, всё равно такие промежутки надо измерять аппаратно-зависимым способом - в ядре, иначе погрешность измерения и время отклика будут сранимы с измеряемой величиной - а это уже ахинея:)

Кстати, стандарты POSIX требует точность 1ms для таймеров высокого разрешения и разработчики универсальной ОС вряд-ли будут прыгать выше..

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

ййй

Сия морал проста: используй микруху atmel + gcc

А про говно очень хотелось бы услышать, чтобы потом его не кушать

;)

binr ★★
()
Ответ на: комментарий от MKuznetsov

MKuznetsov (22.05.2006 2:31:28):

Все верно! Ленин просто вышел за пределы разрешения таймера,
а все мои рассуждения про adjtimex -- глупости (я никогда
с этим не возился, сорри).

Меня сбил с толку некий довольно идиотский баг, который я
случайно вставил в Ленинскую программу:

 . . .
while (1)
   {
      t2 = GetCurrentTime();
      ct2=clock();
      printf ("%d %ld\n", (t2-t1),ct2-ct1);
      ct1=ct2;
      t1 = t2;
   }
  . . .

После adjtime -t 9000 

она мне периодически выдавала строки типа
-382 -1
откуда я заключил, что clock() заворачивается назад.

Разумеется, это просто тривиальный баг, 
printf ("%d %ld\n", (t2-t1),ct2-ct1); =>
printf ("%lld %d\n", (t2-t1),ct2-ct1);
и -1 нет.

Die-Hard ★★★★★
()
Ответ на: ййй от binr

2 All:

Полагаю, тема закрыта, MKuznetsov все подробно объяснил. От личных выпадов можно воздержаться (про себя я все сам понял :))

Die-Hard ★★★★★
()
Ответ на: комментарий от MKuznetsov

> В полях tv_usec,tv_nsec всё что меньше 10ms можно считать мусором.

Ой. это неправда.

gettimeofday() имеет resolution _намного_ лучше, чем 10ms.
насколько лучше - зависит от текущего time_interpolator.

обратного хода все-таки не должно быть, если это происходит
без adjtime - это баг.

idle ★★★★★
()
Ответ на: комментарий от idle

idle:

> обратного хода все-таки не должно быть, если это происходит
без adjtime - это баг.

А оно происходит!

Вот программа:

# include <sys/time.h>
# include <stdio.h>
int main (void)
{
struct timeval ttt1,ttt2;

   for(gettimeofday(&ttt1, NULL);;ttt1=ttt2){
      gettimeofday(&ttt2, NULL);
      printf ("%ld %5ld -- %ld %ld %ld %ld\n",
              ttt2.tv_sec-ttt1.tv_sec,
              ttt2.tv_usec-ttt1.tv_usec,
              /*--*/
              ttt1.tv_sec,ttt1.tv_usec,
              ttt2.tv_sec,ttt2.tv_usec
             );
   }
   return 0;
}

Делаем adjtimex -t 9000 (под рутом), запускаем
программу, направляя вывод в файл, ждем секунду,
дальше ^C, и вот типичный результат:

0     5 -- 1148319082 1148319082 933312 933317
0     4 -- 1148319082 1148319082 933317 933321
0  -384 -- 1148319082 1148319082 933321 932937
0     4 -- 1148319082 1148319082 932937 932941
0     5 -- 1148319082 1148319082 932941 932946

Микросекудны периодически 
отматываются назад, где-то в пределах миллисекунды.
А с секундами при этом вообще ничего не происходит.

Если adjtimex -t 10000, то все в порядке!

Die-Hard ★★★★★
()
Ответ на: комментарий от idle

> Ой. это неправда.

к сожалению, правда :( 2.6 vanilla ядра до 2.6.16 не умеют nanosleep < 10ms и gettimeofday даёт ошибки в тех-же величинах. Можешь взять любой тест POSIX и посмотреть диагностику. Кстати, чтобы поймать ошибку gettimeofday надо либо долго гонять тест, либо запустить коррекцию времени :)

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

MKuznetsov (*) (22.05.2006 22:15:25):

> чтобы поймать ошибку gettimeofday надо либо долго гонять тест, либо запустить коррекцию времени :)

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

Нет, на проблемы с разрешением это не очень похоже...

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

С моей стороны личных выпадо нет. По ntp меня интересует исключительно технический вопрос. По текущим проблемам времени буду мотать себе на ус, чтобы не напороться в будущем.

binr ★★
()
Ответ на: комментарий от Die-Hard

у тебя ядро >= 2.5, но не последнее видимо :)

в 2.5 измененно значение системного тика до 4ms :)) оно как-раз и определяет точность и корректировку..

если интерестно, посмотри

http://lwn.net/Articles/152363/ обоснование изменения системы таймеров,

http://lwn.net/Articles/152436/ то же, с детальной критикой классической системы

http://www.tglx.de/hrtimers.html homesite новых таймеров :)

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

> в 2.5 измененно значение системного тика до 4ms :)) 
> оно как-раз и определяет точность и корректировку..

это АБСОЛЮТНО НЕВЕРНО. HZ (тот самый тик) никоим образом
не связан с точностью gettimeofday(). равно как к этому
не имеет никакого отношения hrtimers.

> Связанно с устройством таймеров в ядре. в 2.6.16 таймеры
> высокого разрешения переделанны

это не совсем переделка, и опять-таки эти таймеры не имеют
отношения к измерению времени.

HZ и core timers (те, timer_list или hrtimer) влияют на
точность alarm или всяких там posix timers.

по видимому, вас запутало то, что слишком много разных
вещей называются словом timer.

смотрите arch/i386/kernel/time.c:do_gettimeofday()
точность работы зависит от того, что у нас в cur_timer.

он выбирается из arch/i386/kernel/timers/timer.c:timers[].
любой из этих таймеров дает НАМНОГО лучшую точность, чем
10ms. если, к примеру, cur_timer == timer_tsc, то точность
у нас - тактовая частота.

idle ★★★★★
()
Ответ на: комментарий от MKuznetsov

> 2.6 vanilla ядра до 2.6.16 не умеют nanosleep < 10ms

и сейчас не умеют.

> и gettimeofday даёт ошибки в тех-же величинах.

нет.

как я уже говорил, это разные вещи.

alarm, nanosleep все еще tick based.

> в 2.6.16 таймеры высокого разрешения переделанны

да, schedule_timeout теперь использует hrtimers, но
пока это мало что дает, срабатывают эти таймеры все
еще из TIMER_SOFTIRQ, те по приходу smp_local_timer_interrupt,
те точночть у нас по-прежнему определяется значением HZ.

idle ★★★★★
()
Ответ на: комментарий от Die-Hard

Die-Hard:

> > обратного хода все-таки не должно быть, если это происходит
> > без adjtime - это баг.

> А оно происходит!

так я же говорил "без adjtime", про adjtime я мало
что знаю.

тут говорилось, что gettimeofday() может идти назад
даже без adjtime, вот этого никак не должно быть.

такое может например случится, если у нас SMP и tsc
не синхронизированы, и система не смогла переключиться
на другой timer source (hpet, pit).

idle ★★★★★
()
Ответ на: комментарий от idle

2idle:

> так я же говорил "без adjtime", про adjtime я мало что знаю.

Я же не вызываю adjtime() в программе! Я просто запускаю коррекцию времени уменьшением системныех тиков командой adjtimex -t 9000 (или tickadj 9000). Или ты именно это имел в виду?

Я, к сожалению, совершенно не знаком с вопросом, но очень хотелось бы разобраться.

Die-Hard ★★★★★
()
Ответ на: комментарий от MKuznetsov

MKuznetsov : > у тебя ядро >= 2.5, но не последнее видимо :)

2.6.13-15-smp, Пентиум4 с гипертредингом виден как две головы. Под рукой нет другого компа с рутом, кроме больших машин, на которых я экспериментировать не хочу.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Die-Hard:

> Или ты именно это имел в виду?

да, именно. sys_adjtimex() ведь действует глобально,
так что не важно то, что сама программа его не зовет.

> Я, к сожалению, совершенно не знаком с вопросом,

я тоже абсолютно ничего не знаю про adjtime кроме
очень общего принципа работы. я даже не знаю баг
это или нет, если время идет назад. точнее, если
этого нельзя избежать (там ведь параметров полно).

idle ★★★★★
()
Ответ на: комментарий от idle

idle (23.05.2006 16:20:44):

> ...если этого нельзя избежать (там ведь параметров полно).

Вот, это и был главный вопрос Ленина.

Как сделать так, чтобы время менялость плавно, как и положено, для чего и служит sys_adjtimex().

Есть 3 утверждения:

1. Скачкообразное подкручивание времени, возвращаемого gettimeofday() которое мы наблюдаем при изменении тиков командой adjtimex -t ###, есть баг (присущий ядрам >=2.5?).

2. Это не баг, но фича, которую можно победить, играя параметрами adjtimex (то есть это не баг ядра, а багофича программы adjtimex).

3. Все в порядке, поскольку скачки не выходят за рамки разрешения.

Как бы узнать, что соответствует истине?

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> Как бы узнать, что соответствует истине?

нет, не знаю. честно говоря, это вне сферы моих
интересов, а код do_adjtimex() не для поверхностного
чтения.

разве что вот этот комментарий в do_gettimeofday()
                /*
                 * If time_adjust is negative then NTP is slowing the clock
                 * so make sure not to go into next possible interval.
                 * Better to lose some accuracy than have time go backwards..
                 */
                if (unlikely(time_adjust < 0)) {

наводит на мысли о том, что время все равно не должно
идти назад.

у меня нет ни adjtime, ни tickadj. что strace говорит?
может, оно не только sys_adjtimex() делает?

а в man'е что-нибудь есть про monotonic time?

хм...  clock_gettime(CLOCK_MONOTONIC) использует все тот
же do_gettimeofday(), так что...

не, это точно в google, а я им пользоваться не умею :)

idle ★★★★★
()
Ответ на: комментарий от idle

2idle по поводу tick-based sys_nanosleep и sys_alarm

asmlinkage long
sys_nanosleep(struct timespec __user *rqtp, struct timespec __user *rmtp)
{
        struct timespec tu;

        if (copy_from_user(&tu, rqtp, sizeof(tu)))
                return -EFAULT;

        if (!timespec_valid(&tu))
                return -EINVAL;

        return hrtimer_nanosleep(&tu, rmtp, HRTIMER_REL, CLOCK_MONOTONIC);
}

sys_alarm использует do_setitimer(ITIMER_REAL..)
int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue)
{
        struct task_struct *tsk = current;
        struct hrtimer *timer;
        ktime_t expires;
        cputime_t cval, cinterval, nval, ninterval;

        switch (which) {
        case ITIMER_REAL:
again:
                spin_lock_irq(&tsk->sighand->siglock);
                timer = &tsk->signal->real_timer;
                if (ovalue) {
                        ovalue->it_value = itimer_get_remtime(timer);
                        ovalue->it_interval
                                = ktime_to_timeval(tsk->signal->it_real_incr);
                }
                /* We are sharing ->siglock with it_real_fn() */
                if (hrtimer_try_to_cancel(timer) < 0) {
                        spin_unlock_irq(&tsk->sighand->siglock);
                        goto again;
                }
                tsk->signal->it_real_incr =
                        timeval_to_ktime(value->it_interval);
                expires = timeval_to_ktime(value->it_value);
                if (expires.tv64 != 0)
                        hrtimer_start(timer, expires, HRTIMER_REL);
                spin_unlock_irq(&tsk->sighand->siglock);
                break; 
...

то есть CLOCK_MONOTONIC и tsk->signal->real_timer (фактически CLOCK_REAL) - являются tick based ??

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

> tsk->signal->real_timer (фактически CLOCK_REAL) - являются tick based ??

(фактически, CLOCK_MONOTONIC, см kernel/fork.c:copy_signal())

вопрос не очень корректный. еще раз, срабатывают они в момент
"тика", то есть один из ответов - да. однако, это ограничение
сегодняшнего дня.

интерфейс hrtimers (в отличие от старого timer_list) этих
ограничений не имеет. не следует, однако, думать, что
hrtimers во всем "лучше".

idle ★★★★★
()
Ответ на: комментарий от idle

2idle (*) (24.05.2006 0:02:20):

> что strace говорит?

После всякой белиберды с екзеком и ммаппингом, strace
adjtimex -t 9000 говорит так:

adjtimex({modes=16384, offset=47, freq=-2041345, maxerror=385623,
esterror=245, status=1, constant=4, precision=1, tolerance=33554432,
time={1148432140, 909283}}) = 0
exit_group(0)                           = ?

После этого adjtimex -p выдает такое:

         mode: 0
       offset: 45
    frequency: -2041345
     maxerror: 410711
     esterror: 245
       status: 1
time_constant: 4
    precision: 1
    tolerance: 33554432
         tick: 9000
     raw time:  1148432189s 581596us = 1148432189.581596

То есть, adjtimex -- не совсем дословное воспроизведение сисколла с
текущими параметрами. Кто б сказал, что все эти циферки значат?

Die-Hard ★★★★★
()
Ответ на: комментарий от idle

> срабатывают они в момент "тика", то есть один из ответов - да. однако, это ограничение сегодняшнего дня.

А каким тогда образом тесты hrtimers-test проходят успешно на всех ядрах начиная с 2.6.12 ? IMHO Если бы nanosleep срабатывал в момент тика, то тесты бы просто не прошли.

кстати, не в курсе, какая ещё часть от realtime-preempt патча от mingo кроме hrtimers уже интегрированна в trunc ?

MKuznetsov ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.