Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Тестирование латентности прерываний ОС
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Evgeny_CD
Идея проста. Задающий импульс на прерывание. В обработчике прерывания ногой дергаем.

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

Микроконтроллер. Берет выход счетчика -> COM -> PC -> файл. Метки PC времени проставить в файле.

Статистика. Скользящая гистограмма. Как распредились латентности за последнюю минуту.

Ну и задачки всякие разные под ОСью запускать. WEB сервачек там и т.д.

А затем смотрим, как плывет гистограмма в зависимости от нагрузки.

Особенно меня такое интересует для Linux (нормального, не RT) на небыстрых процах (~70 Mhz ARM720 и т.д.)
Harbour
В нормальном linux'е нет смысла - любой драйвер могет прерывания запретить надолго, особенно актуально для X'овых/fbdev драйверов. В i386 RT варианте легко получить стабильные 4-10 мкс, arm не юзал, но народ на motorollовском 5672 получал 5 мкс, думаю arm должен быть не хуже.
Evgeny_CD
Цитата(Harbour @ Jul 29 2005, 14:33)
В нормальном linux'е нет смысла - любой драйвер могет прерывания запретить надолго, особенно актуально для X'овых/fbdev драйверов. В i386 RT варианте легко получить стабильные 4-10 мкс, arm не юзал, но народ на motorollовском 5672 получал 5 мкс, думаю arm должен быть не хуже.
i386 - это при какой тактовой?

5672 - это что за проц (не нашел), тактовая?

Мне 5 мкс не надо, меня 1 мс устроит. Вопрос в том, можно ли ее гарантировать в обычном, не RT линухе?
tvv
Цитата(Evgeny_CD @ Jul 29 2005, 13:56)
Мне 5 мкс не надо, меня 1 мс устроит. Вопрос в том, можно ли ее гарантировать в обычном, не RT линухе?
*

Ответ скорее нет, чем да sad.gif Тут еще та обманка, что время реакции 1мс получить можно, а гарантировать никак. Я на осцилоскопе это красиво видел. Драйвер в прерывании (мною писанный, т.е. я уверен что мин нет) кидает через PCI флаг прямо на вход скопа. И все вроде хорошо пока не поставил секундную развертку. Падал (или стоял) мой флаг до сотен милисекунд, без каких-либо сообщений. Причем чем сильнее я грузил шину тем дольше лежал флаг (что по-человечески понятно). Машина была встроеный в VME контроллер с P3 800MHz (дело трех летней давности). Если надо гарантировать мс берите QNX или что нравится из аналогов. А про линух и масдай надо забыть. В Вашей задаче можно попытаться использовать счетчик тактових импульсов, есть у Р2 и выше (про ARM не знаю) такой восьми битный регистр. Под QNXом он доступен через апи, у линуха через асемблер. Пускается при включении питания и считает пока не выключат PC. В отличаи от RTC точность определяется частотой процессора и счетчик не зависит от операционки. Ну а дальше считайте латентность и стройте гистограмки.
Harbour
Цитата(Evgeny_CD @ Jul 29 2005, 13:56)
Цитата(Harbour @ Jul 29 2005, 14:33)
В нормальном linux'е нет смысла - любой драйвер могет прерывания запретить надолго, особенно актуально для X'овых/fbdev драйверов. В i386 RT варианте легко получить стабильные 4-10 мкс, arm не юзал, но народ на motorollовском 5672 получал 5 мкс, думаю arm должен быть не хуже.
i386 - это при какой тактовой?

5672 - это что за проц (не нашел), тактовая?

Мне 5 мкс не надо, меня 1 мс устроит. Вопрос в том, можно ли ее гарантировать в обычном, не RT линухе?
*



Sorry, очипятка - 5272 Coldfire 66 Mhz
В обычном linux'e - нельзя. Ставишь adeos/fusion и пишешь проги в юзер-спейс - аналогов нет ни у одной коммерческой RTOS, я уже молчу о превосходстве adeos в платформах и скорости.
Olej
Цитата(tvv @ Jul 29 2005, 23:50)
В Вашей задаче можно попытаться использовать счетчик тактових импульсов, есть у Р2 и выше (про ARM не знаю) такой восьми битный регистр. Под QNXом он доступен через апи, у линуха через асемблер. Пускается при включении питания и считает пока не выключат PC. В отличаи от RTC точность определяется частотой процессора и счетчик не зависит от операционки. Ну а дальше считайте латентность и стройте гистограмки.
*


Вопрос хоть и давний, но часто актуальный:
1. под QNX опрос такого счётчика (x86 only) - ClockCycles() - и эта возможность действительно позволяет засекать временные интервалы диапазона наносекунд...
2. Но и под Linux есть такой инструмент: get_cycles() (asm/timex.h)...
3. И практически под любой OS x86 можно поискать, потому, что реализуется всё это хозяйство через специальную команду rdtsc (реализована начиная с i586, исключения amd 5x86);
4. ... в конце концов в любой OS можете сами такое сваять, вот примерный код в GCC:
Код
unsigned long long tsc( void ) {
  unsigned long long f;
  __asm__ __volatile__ ( "rdtsc" : "=А"( f ) );
  return f;
};

5. Но что интересно, что времена, определяемые таким менером ... будут "расходиться" с системным временем (заметно на интервалах уже начиная с 1 сек.) - эти часы работают от 2-х разных физических кварцев (RTC / тактовая частота процессора), 10**-4 - 10**-5 разница ... может порождать эффекты, над которыми можно долго просидеть wink.gif...
6. Но (!) для определения латентности по прерыванию, Dedicated Systems например, применяют методики, которые они обстоятельно обсуждают - построенные на электрической (типа осциллографа) фиксации реакции на PCI!
zaratustra
Evgeny_CD

У меня был другой тест. Железка на pci шине генерила прерывания по внешним синхроимпульсам, а в isr я засекал системное время. Для 1Кгц при отсутствии обмена по шине pci (прерывания запрещались) получалась с точностью до 1мкс прямая линия. Но стоило нагрузить шину данными из pci-железки, то получался разброс до 10мкс, а временами происходили отскоки на несколько делятков мкс. Причину честно говоря мне раскопать не удалось. Но проц-то был 3ГГц, а на медленных этот эффект наверняка будет никак не меньше.
Olej
Цитата(zaratustra @ Nov 18 2005, 17:40) *
У меня был другой тест.


Тема - давняя, но вопрос как был актуальным так и остаётся... даже для сравнения характеристик не только разных и новых RTOS, но и контроля при появлении новых версий знакомых RTOS (не намудрили ли там чего? cranky.gif )

Здесь вот размещёно свеженькое сравнение 3-х RTOS (как, по крайней мере, их авторы называют) - RTLinux, RTAI и VRTXsa:
http://www.linuxdevices.com/news/NS5236356423.html
- в том числе и по латентноти.
Не думаю, что результаты сами по себе будут интересные, но может можно что-то "подсмотреть" по методикам (или дефектам методик ).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.