[ARM] clock_nanosleep и RT_PREEMPT

убедись, что в конфиге ядра CONFIG_PREEMPT_RT_FULL=y, и HZ поставь в 1000

Just for fun проверил на компе (resolution 1nsec), то же самое. А вот MONOTONIC_RAW - ~1200

через ethernet отправлять пакеты с заданным интервалом - 250мкс

Нереально. Ethernet вообще для реалтайма мало пригоден, а для таких микро интервалов и подавно.

Тут недавно arsi(*) пробовал подобный код на arm без rt ядра, у него задержка была до 17мс. Так что я думаю тут сам arm тормозит.

Ну как обычно. Прочитай ман полностью на clock_nanosleep. Там же красным по русскому написано почему он лучше чем нанослип. Указывай не скока времени ждать а до какого времени ждать. Тогда и узнаешь арм тормозит или линукс говно.

> arsi(*)

> *

фигасе ты меня опустил… :)

> Так что я думаю тут сам arm тормозит.

не факт, это у меня арм тормозит :) /proc/timer_list: «.resolution: 10000000 nsecs», да и проц 200МГц.

Сколько работает clock_gettime (тот же код, но убрать nanosleep)?

Сколько работает clock_gettime (тот же код, но убрать nanosleep)?

8958
7291
26417
3500
3292
3292
3750
4042
2833
2625

почему на 3 итерации 26417 нс занимает вызов, не понятно. но это почти все время повторяется, именно на 3-ий раз.

Кстати, пересобрал ядро. Отключил CONFIG_NO_HZ и поставил CONFIG_HZ = 1000. Только почти ничего изменилось.

отправляешь «сырые» езернет фреймы или прогоняешь через сетевой стек?

отправляешь «сырые» езернет фреймы или прогоняешь через сетевой стек?

«сырые». просто ethernet кадр с необходимыми данными.

Отключил CONFIG_NO_HZ

1)По логике лучше включить.

2)Можешь попробовать привязать этот процесс к одному процессору, а все остальные - к другим. И прерывания отвязать.

> почему на 3 итерации 26417 нс занимает вызов, не понятно. но это почти все время повторяется, именно на 3-ий раз.

1. прогони 100 раз, а не 10, м.б. это что-то периодическое…

2. в самом начале поставь sleep(1);

3. подгрузи страницы для стека в самом начале:

static void __attribute__((noinline)) map_stack_pages(void) {
    char t[1024*1024];
    memset(t, 0, sizeof t);
}

int main() {
    map_stack_pages();
    ...
}

1)По логике лучше включить.

насколько я понял, CONFIG_NO_HZ позволяет экономить расход энергии при простое ядра. у меня простой не предвидится. но опцию попробую вернуть.

2)Можешь попробовать привязать этот процесс к одному процессору, а все остальные - к другим. И прерывания отвязать.

можно об этом подробнее?) физически у меня только одни процессор и имеется, АРМ9.

«сырые». просто ethernet кадр с необходимыми данными.

может тогда в виде ядреного модуля оформить с колбеками в юзерспейс например?

serge@blacktablet:~$ cat sched.c 
#define _POSIX_C_SOURCE  200112L

#include <stdio.h>
#include <unistd.h>
#include <time.h>
#include <sched.h>
#include <stdlib.h>
#include <sys/mman.h>

int main() {
    mlockall(MCL_FUTURE);

    sched_setscheduler(0, SCHED_FIFO, &(struct sched_param) {
        .sched_priority = sched_get_priority_max(SCHED_FIFO)
    });

    struct timespec a, b, c;

    c.tv_sec  = 0;
    c.tv_nsec = 150000;

    for (int n = 10; n--;) {
        clock_gettime(CLOCK_MONOTONIC, &a);

        clock_nanosleep(CLOCK_MONOTONIC, 0, &c, NULL);

        clock_gettime(CLOCK_MONOTONIC, &b);

        fprintf(stdout, "%ld\n", b.tv_nsec - a.tv_nsec + (b.tv_sec - a.tv_sec) * 1000000000l);

        fflush(stdout);
    };

    return 0;
}

serge@blacktablet:~$ sudo ./sched 
192273
181238
176699
179213
191016
180260
180749
184311
184172
179142

но проверял на обычном ядре.

serge@blacktablet:~$ sudo ./sched 
177816
166222
165664
165315
165244
165244
164546
165035
165035
165175

если убрать из основного цикла все io

250мкс из юзерспейса... какова частота процессора? И да, для начала следует убрать printf.

> как приблизиться к заветным 250мкс?

примерно так ;)

#define _POSIX_C_SOURCE  200112L

#include <stdio.h>
#include <time.h>
#include <sched.h>
#include <stdlib.h>

int main() {
    sched_setscheduler(0, SCHED_FIFO, &(struct sched_param) {
        .sched_priority = sched_get_priority_max(SCHED_FIFO)
    });

    const clockid_t clock = CLOCK_REALTIME;
    struct timespec a, b, t = { .tv_nsec = 250000 };

    for (int i = 1; i <= 100; ++i) {
        clock_gettime(clock, &a);
        clock_nanosleep(clock, 0, &t, NULL);
        clock_gettime(clock, &b);
        long dt = b.tv_nsec - a.tv_nsec + (b.tv_sec - a.tv_sec) * 1000000000l;
        printf("%ld\n", dt);
        t.tv_nsec -= (dt - 250000) / i;
    }
}

Случайно отладочные опции для мутексов/семафоров/etc в Kernel Hacking не включены?

calibration loop? :)

у меня на таком говнокоде

#define _POSIX_C_SOURCE  200112L

#include <stdio.h>
#include <unistd.h>
#include <time.h>
#include <sched.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <string.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>

int main() {
  mlockall(MCL_FUTURE);

  sched_setscheduler(0, SCHED_FIFO, &(struct sched_param) {
    .sched_priority = sched_get_priority_max(SCHED_FIFO)
  });

  static struct timespec a, b, c;

  static struct sockaddr_in sa;

  static int n, s;

  static unsigned long t[10];
  static unsigned char buf[512];

  memset((char *) &sa, 0x00, sizeof(sa));

  s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

  sa.sin_family = AF_INET;
  sa.sin_port = htons(0xFF);

  inet_aton("192.168.1.1", &sa.sin_addr);

  c.tv_sec  = 0;
  c.tv_nsec = 250000;

  for (n = 10; n--;) {
    clock_gettime(CLOCK_MONOTONIC, &a);

    clock_nanosleep(CLOCK_MONOTONIC, 0, &c, NULL);

    clock_gettime(CLOCK_MONOTONIC, &b);

    sendto(s, buf, sizeof(buf), 0, &sa, sizeof(sa));

    t[n] = b.tv_nsec - a.tv_nsec;
  };

  for (n = 10; n--;) {
    fprintf(stdout, "%ld\n", t[n]);
  };

  return 0;
}

выдает

serge@blacktablet:~$ sudo ./sched 
288654
279993
278526
280831
317149
273079
272590
276990
314076
282019

только для получения реальной картины надо поменять

   clock_gettime(CLOCK_MONOTONIC, &b);
   sendto(s, buf, sizeof(buf), 0, &sa, sizeof(sa));

местами

Может из-за «NTP adjustments»?.. Выше, намекалось, намекалось.

фигасе ты меня опустил… :)

я не хотел)) можешь писать меня golodranez() :)))

Вот ты вся тупо с слипом пытаешься чтото сделать, а я тебе по опыту поворю - ethernet для realtime не подходит, периодически будут некислые задержки. Тут из протокола TCP/IP уже это понятно.

Вот ты вся тупо с слипом пытаешься чтото сделать, а я тебе по опыту поворю - ethernet для realtime не подходит, периодически будут некислые задержки. Тут из протокола TCP/IP уже это понятно.

это я с стеком тестил j4f. ТС'у надо слать сырые езернет кадры а если у него на этом ифейсе ничего не будет + девайсы соединены p2p то вполне может прокатить.

внял всем вашим советам и выдавать пакеты с интервалом ~250 мкс. получилось, так что задачу можно считать решенной. время конечно плавает, но в целом держится около заданной отметки. теперь другая проблема, после продолжительной работы отваливается ethernet, ругаясь на ошибку MDIO. трудноуловимый баг, буду разбираться.

Всем огромное спасибо!