Глюк параллельного времени.
Дата публикации: 27.08.2010

Сообщение об ошибке.

Как всем известно, программисты Спецлаб перевели свой продукт на архитектуру параллельного исполнения кода для полного использования многопроцессорных систем. Надо отметить не только возросшие мощности, которые позволили повесить на GOALcity Pegal целый ряд высокозагрузочных технологий, но и качество программирования. Практически все проблемы, с которыми пришлось столкнуться в этом никем неосвоенном направлении, были решены год назад, когда официально вышел релиз.

За все это время при продажах более полусотни тысяч комплектов ПО не было проблем со стабильностью работы даже в самых длительных и ресурсозатратных режимах. Сегодня мы точно можем сказать, что спецлабовская технология параллелизма состоялась. Тем не менее, мы обязаны сообщить и о некоторой проблемке, которая была выявлена специалистами Спецлаб. Такие вещи естественны в разработке новых технологий, здесь главное – честное изложение и предупреждение.

В целом никаких критических моментов с точки зрения работоспособности нет, и некритических тоже. Но была латентная проблема, больше относящаяся к организационным вопросам - к точности отображения времени записи кадра. Проще говоря, была погрешность таймера.

И связана она с архитектурой многопроцессорности, которую стала использовать программа. Дело в том, что каждый процессор имеет собственную тактовую частоту. Нет, она не разная по номиналу, просто разная потому, что ничего одинакового в мире нет. Сколько бы мы ни взяли одинаковых генераторов, все они будут иметь разную тактовую частоту. Естественно, сама по себе погрешность мизерная, но она вырастает в солидную при длительной работе, все больше отклоняясь от заданного значения с каждым моментом времени. При исполнении реально параллельного кода каждый процессор обрабатывает данные по собственному количеству тактов, поэтому запись видео при месячной работе получала диспропорцию временных меток, при очень детальном рассмотрении заметную на глаз. В результате аддитивной ошибки синхронизации времени в некоторых крайне редких случаях время кадра в архиве отличалось от истинного на несколько секунд.

Чтобы никто не подумал, что за умными словами что-то скрывается, поясним вопрос доступным языком. Наша программа не использует часы Windows в процессе работы, так как их скорость обновления крайне низка – всего 16 миллисекунд. С учетом того, что кадр меняется через каждые 40 миллисекунд, это не дает возможность расчета точного времени. Поэтому мы забираем из БИОСа время во время старта и в дальнейшем просчитываем его сами. Естественно, эта проблема касается конкретно видеонаблюдения, где требуется четкая синхронизация большого числа параллельных потоков видео.

При использовании одного процессора не возникает проблем, так как вся обработка идет на одной тактовой частоте. А вот в многопроцессорном софте вылезла такая «бага».

В новом релизе она исправлена. Те, для кого расхождение в несколько секунд за месяц явилось критичным, могут скачать его на странице для пользователей. Для тех, кто использует автоматическую перезагрузку, с ней не столкнется. Извините за доставленные неудобства, но они неизбежны в сфере высоких и неизведанных технологий!

processors8.jpg

«Инстинкт» для выживания.
Честно и прагматично – несколько слов о новом бренде.
Как сэкономить 20 миллиардов?
Простой вопрос – простой ответ.