LINUX.ORG.RU

Странный способ вычисления значения delay для Net::SNMP

 ,


0

1

Добрый день!

Есть код, который опрашивает железо через интервалы времени и складывает собранные данные в бд.
Код legacy, автор не я.
Есть вопрос касающийся вычисления задержки между опросами (delay)

Общий смысл такой (названия переменных сохранены, вместо работы sleep-ы):

#/usr/bin/env perl
use strict;
use warnings;

my $freq = 10;
my $EPOH = time;

data_processing(4,$freq, $EPOH-$freq);

sub data_processing{
    my ($delay, $freq, $ts_start) = @_;
    # *** начать сбор данных необходимо через delay секунд
    sleep $delay;

    # *** здесь происходит сбор данных
    sleep 1;
	
    my $ts_cur = time;
    # *** здесь происходит сохранение данных
    sleep 1;	
	
    # !!! алгоритм рассчета delay
    my $next_ts_start = $ts_start + $freq;	
    $delay = $freq - ($ts_cur - $next_ts_start);
    $delay = 1 if $delay < 1;
	
    print "freq=[$freq] ts_start=[$ts_start] ts_cur=[$ts_cur] next_ts_start=[$next_ts_start] delay=[$delay]\n";
    data_processing($delay, $freq, $next_ts_start);
}

freq=[10] ts_start=[1395319276] ts_cur=[1395319291] next_ts_start=[1395319286] delay=[5]
freq=[10] ts_start=[1395319286] ts_cur=[1395319298] next_ts_start=[1395319296] delay=[8]
freq=[10] ts_start=[1395319296] ts_cur=[1395319308] next_ts_start=[1395319306] delay=[8]
freq=[10] ts_start=[1395319306] ts_cur=[1395319318] next_ts_start=[1395319316] delay=[8]

Реальный код использует неблокирующий Net::SNMP и ему сообшает вычисленый delay.
Здесь получается, что next_ts_start всегда оказывается в прошлом и это сильно путает.
Но как это работает мне понятно.

Вопрос:
Я не понимаю, зачем так сделано?
Есть-ли какие-то причины чтобы рассчитывать этот dealy именно так, а не просто вычесть целевое время из текущего?

парметры $ts_start и $next_ts_start зависят лишь от того с каким параметром была вызвана функция в самый первый раз.

Очевидно, что этот код работает не так как задумывалось. Скорее всего по задумке функция должна запускаться раз во $freq секунд, а время сбора данных переменно, поэтому и нужен delay.

codeogre
()

Обычная практика. Только мало проверок в коде.

Зачем так делать? Затем, что время опроса вычисляется точными промежутками времени. Вне зависимости от побочных эффектов (тормоза бд). Далее эта информация поступает в RRD (или аналог), где записывается значение опроса в нужные «ячейки». Иначе полученные графики будут иметь резкие линии и/или разрывы.

Этого всего можно избежать покурив маны на RRD (или аналог). Но иногда данное решение себя оправдывает.

P.S. Также, это один из методов избежания множества запросов к железке, следующие друг за другом.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 3)
Ответ на: комментарий от gh0stwizard

Не, я понимаю зачем нужен delay

             _________freq______________
            |                           |
            A            B              C
Время ------|---------------------------|------
            .            .              .
            .            .              .
            .            .              .
            .            .              .
            .            .              .
	    .            .              .
	   начало       мы здесь        придти сюда

С = A + freq надо понять сколько из B осталось до C
Указанный алгоритм считает расстояние AB и отнимает его из freq, получает BC

Я не понимаю, есть-ли причины по которым нельзя считать его как С-B=BC (что гораздо понятней для меня)

pru-mike ★★
() автор топика
Ответ на: комментарий от pru-mike

Посколько мне неизвестно что и куда пишется в БД заниматься телепатией мне лень. Выше я объяснил стандартные мотивы.

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

Представьте себе ситуацию, что железка не ответила, а таймаут стоит выше периода опроса. Или железка «протупила» и дала ответ через 12 секунд.

Что касается проще/сложно для понимания это ваше дело. На практике важно время замера и то время, которое будет указано при записи в БД. У вас оно совпадает и сделано специально. Также это называется точнее время замера с точным периодом опроса. В других реализациях время замера/периода задается скриптом/программой на основе других факторов и чаще всего делается динамически.

У вас просто «разрыв шаблона» из-за того, что вам не знаком случай, где точное время замера играет ключевую роль. Это разные методики решения одной задачи.

Можете переписать скрипт как вам видется «правильно». Вам же за него отвечать. Реализация в топике имеет право на жизнь и работоспособна.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от pru-mike

Этот пост проглядел. Тогда поправка. В бд всегда пишется значение расчетного опроса. Иначе говоря, у вас в rrd все ячейки будут записаны. Даже не смотря на то , что время опроса в реальности было на несколько ячеек ранее. И в таком случае, ячейки будут иметь значения с опозданием.

Имеет ли это смысл в вашем случае? Все зависит от окружения (сети, железок и т.п.)

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