Da, pozaluj smisl v etom est'. Po idee v bol'shinstve situacij propustit' odin poll luchshe chem poluchit' pik na grafike. Ja dumaju sdelat' tak:

1. Dobavit' flazok "is counter" v DCI - poskol'ku eto mozet bit' naprimer temperatura, i plavat' vverh-vniz - togda sled. znacjenie men'she prediduschego eto ok;
2. Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.

2 лучше. Особенно для подсчета DCI значений, где считается просто дельта.

Da, pozaluj smisl v etom est'. Po idee v bol'shinstve situacij propustit' odin poll luchshe chem poluchit' pik na grafike. Ja dumaju sdelat' tak:

1. Dobavit' flazok "is counter" v DCI - poskol'ku eto mozet bit' naprimer temperatura, i plavat' vverh-vniz - togda sled. znacjenie men'she prediduschego eto ok;
2. Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.

Спешил, и опечатался в своём сообщении ( даже не опечатался а откровенный бред набрал )
конечно же

if (QWORD)value < (QWORD)m_prevRawValue then
{
value = m_prevPrevValue;
}

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

1. Dobavit' flazok "is counter" v DCI - poskol'ku eto mozet bit' naprimer temperatura, i plavat' vverh-vniz - togda sled. znacjenie men'she prediduschego eto ok;
2. Esli new value < prev value, to libo propustit' poll (net dannih voobsche), libo sdelat' delta value = prev delta value. V ljubom sluchae pik uberem.

это встроенний код, не скрипт. выглядит он так:

      case DCM_AVERAGE_PER_MINUTE:
         nElapsedTime /= 60;  // Convert to minutes
      case DCM_AVERAGE_PER_SECOND:
         // Check elapsed time to prevent divide-by-zero exception
         if (nElapsedTime == 0)
            nElapsedTime++;

         switch(m_dataType)
         {
            case DCI_DT_INT:
               value = ((LONG)value - (LONG)m_prevRawValue) / (LONG)nElapsedTime;
               break;
            case DCI_DT_UINT:
               value = ((DWORD)value - (DWORD)m_prevRawValue) / (DWORD)nElapsedTime;
               break;
            case DCI_DT_INT64:
               value = ((INT64)value - (INT64)m_prevRawValue) / (INT64)nElapsedTime;
               break;
            case DCI_DT_UINT64:
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;
            case DCI_DT_FLOAT:
               value = ((double)value - (double)m_prevRawValue) / (double)nElapsedTime;
               break;
            case DCI_DT_STRING:
               // I don't see any meaning in "average delta per second (minute)" for string
               // values, so result will be 0 if there are no difference between
               // current and previous values, and 1 otherwise
               value = (LONG)((_tcscmp((const TCHAR *)value, (const TCHAR *)m_prevRawValue) == 0) ? 0 : 1);
               break;
            default:
               // Delta calculation is not supported for other types
               break;
         }

Угу приведение вижу, странно, на первый взгляд никаких проблем не должно быть.

case DCI_DT_INT64:
               value = ((INT64)value - (INT64)m_prevRawValue) / (INT64)nElapsedTime;
               break;
case DCI_DT_UINT64:
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;

Не может быть проблемы в платформе? (win32)
Может отказаться от uint64 в пользу int64?

Можно ли предусмотреть какой либо лог который будет отрабатывать флуктуации?
Например

if (DCI_DT_PREV*4) < DCI_DT_NEXT then

пишем в лог

DCI_RAW
DCI_RAW_PREV
DCI_DT_PREV
DCI_DT_NEXT

И тут в голову пришло во время написания.

Когда поле .1.3.6.1.2.1.31.1.1.1.6 достигает максимального значения uint64 он не сбрасывается на 0, либо в других предусмотренных ситуациях? Полез в документацию,из описания поля

The total number of octets received on the interface,
including framing characters.  This object is a 64-bit
version of ifInOctets.

Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime.

то есть теоретически у нас может получится ситуация когда
value будет меньше m_prevRawValue

может добавить проверку?

сase DCI_DT_UINT64:
if (QWORD)value < (QWORD)m_prevRawValue then
{
value = m_prevPrevValue;
}
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;

Ну как?

      case DCM_AVERAGE_PER_MINUTE:
         nElapsedTime /= 60;  // Convert to minutes
      case DCM_AVERAGE_PER_SECOND:
         // Check elapsed time to prevent divide-by-zero exception
         if (nElapsedTime == 0)
            nElapsedTime++;

         switch(m_dataType)
         {
            case DCI_DT_INT:
               value = ((LONG)value - (LONG)m_prevRawValue) / (LONG)nElapsedTime;
               break;
            case DCI_DT_UINT:
               value = ((DWORD)value - (DWORD)m_prevRawValue) / (DWORD)nElapsedTime;
               break;
            case DCI_DT_INT64:
               value = ((INT64)value - (INT64)m_prevRawValue) / (INT64)nElapsedTime;
               break;
            case DCI_DT_UINT64:
               value = ((QWORD)value - (QWORD)m_prevRawValue) / (QWORD)nElapsedTime;
               break;
            case DCI_DT_FLOAT:
               value = ((double)value - (double)m_prevRawValue) / (double)nElapsedTime;
               break;
            case DCI_DT_STRING:
               // I don't see any meaning in "average delta per second (minute)" for string
               // values, so result will be 0 if there are no difference between
               // current and previous values, and 1 otherwise
               value = (LONG)((_tcscmp((const TCHAR *)value, (const TCHAR *)m_prevRawValue) == 0) ? 0 : 1);
               break;
            default:
               // Delta calculation is not supported for other types
               break;
         }

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

и таким скриптом трансформации

sub main()
{
return ((uint64($1)*8)/(1 << 20));
}

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

Все счетчики - это беззнаковые целые, и при достижении максимума переходят через 0. Например, если у меня 8-ми битовый счетчик, то при значении 254 прибавив 3 я получу 1. Обычно для счетчиков абсолютные значения не важны, и собирают обычно дельту. В истории должно хранится уже значение после вычисления дельты и обработки transformation скриптом. Что касается быстрых интерфейсов, то переполнение счетчиков происходит очень быстро, и чтобы получить осмысленные значения, надо собирать данные часто, каждые 5-10 секунд, иначе между двумя опросами может произойти несколько переполнений и переходов через 0, и тогда дельта, вычисленная сервером, даст неправильный результат. Можно также использовать 64-битные счетчики из ifXTable (.1.3.6.1.2.1.31.1.1.1.6 и другие), если устройство их поддерживает.

Огромное спасибо, окончательно разобрался в данном вопросе. Немножко обнаглею, а за драйвера на скриптах не брались  ::) ?

столкнулся с проблемой что выпадают некорректные значения при сборе и обработке значение.

скрипты примерно такие

sub main()
{
return int64((($1*8)/1024)/1024);
}

выпадают отрицательные значения там где их не может быть, собирается параметр .1.3.6.1.2.1.2.2.1.16.1

Poskol'ku original'noe znachenie 32 bit, to pri pervom umnozenii na 8 mi mozem vijti za predeli vozmoznih znacenij dlja 32 bitnogo celogo, i poluchit' perepolnenie. Ja bi predlozil delat' snachala privedenie znachenija k 64 bitam, chtobi interpretator vse dal'nejshie matematicheskie operacii delal kak s 64 bit znacheniem. Vot malen'kij skript, kotorij pokazivaet raznicu:

println int64((($1 * 8) / 1024) / 1024);
println int64(((int64($1) * 8) / 1024) / 1024);

Rezul'tat:

C:\Source\NetXMS\debug>nxscript math.nxsl 100000000
NetXMS Scripting Host  Version 1.1.10
Copyright (c) 2005-2012 Victor Kirhenshtein

762
762

C:\Source\NetXMS\debug>nxscript math.nxsl 1000000000
NetXMS Scripting Host  Version 1.1.10
Copyright (c) 2005-2012 Victor Kirhenshtein

-562
7629

ну наиболее стабильная работа идет на стандартных настройках.
то есть тип определяется как unsigned integer,никак не интерпретируется больше, ясно что это недостаточно, потому как на больших значениях данные ожидаемо падают в 0 и нужно использовать unsigned integer64, у этого же наоборот данные падают в нереальный плюс, если тип ансигнед, если сигнед то еще и в минус могут.
Отдаваемый тип явно int64

The total number of octets received on the
            interface, including framing characters.

Esli rech' idet o standartnih OIDah dlja trafika na interfeisah (.1.3.6.1.2.1.2.2.1.16 naprimer), to oni imejut SNMP tip Counter, t.e. unsigned 32bit integer. Zaschet togo chto znachenie unsigned, vichislenie delta budet prohodit' pravil'no daze pri perehode cherez 0.

И еще вопрос в догонку я подозреваю что использовать сдвиги выгоднее деления или не принципиально?

Dlja interpretiruemogo skripta eto ne principial'no

sub main()
{
return ($1*8)/(1 << 20);
}

The total number of octets received on the
            interface, including framing characters.

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

sub main()
{
return uint32((($1*8)/1024)/1024);
}

точки на графике real, хотя в истории они ожидаемо uint32

Ogranichenij na kolichestvo DCI net.