# 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;
	}
}

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.

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

Вышла новая OPERA

Спроси здесь, тебе сразу дадут правильный ответ: http://www.linux.org.ru/view-message.jsp?msgid=1402978

lenin:

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

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

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

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

binr !

Как сделать так, чтоб у меня высвечивался
длинный список тем, а не как обычно ?

Вышла новая OPERA

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

Вышла новая OPERA

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

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

lenin:

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

Что? Чему?

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

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

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

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

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

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

network time protocol

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

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

> network time protocol

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

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

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

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

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

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

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

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

2lenin:

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

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

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

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

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

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

2lenin:

Извини, очепятался -- не -s, а -S

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

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

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

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

Если события аппаратные можно попробовать написать дривер.

:D

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

binr:

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

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

Привет всем

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

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

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

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

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

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

ййй

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

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

;)

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 нет.

2 All:

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

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

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

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

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

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, то все в порядке!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> в 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, то точность
у нас - тактовая частота.

> 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.

Die-Hard:

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

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

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

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

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

2idle:

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

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

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

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

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

Die-Hard:

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

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

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

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

idle (23.05.2006 16:20:44):

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

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

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

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

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

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

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

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

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

нет, не знаю. честно говоря, это вне сферы моих
интересов, а код 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, а я им пользоваться не умею :)

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 ??

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

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

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

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

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 -- не совсем дословное воспроизведение сисколла с
текущими параметрами. Кто б сказал, что все эти циферки значат?

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

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

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