NetXMS Support Forum

Microsoft can promise all they want, but reality is sometimes different.

I couldn't find the msdn blog I was remembering, but I did find this kb article.  It appears they may have fixed a few things since this is considered retired now.
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&

I don't think they use the rdtsc counter in multi-core systems anymore, but they do still recommend to lock the timing thread to one processor since not all HAL implementations will give consistent readings between cores.  Closest thing my quick search returned is: http://msdn.microsoft.com/en-us/library/ee417693%28v=VS.85%29.aspx

BTW, I DO appreciate your timing changes and keep up the good work!!!  I just wanted to warn you that some odd hardware/os combos will probably fail to measure time correctly...

Haven't had time to test it yet, but QueryPerformanceCounter can have issues on machines with SpeedStep enabled.  (Since the frequency varies dynamically.)  I believe some AMD multi-core systems have problems too.  I suspect it will work for most people fine.  I hadn't noticed the original function was ms since a set epoch.  That could easily be simulated with an initial call to save the offset from the system start time.  However, my example would still roll over after 49 days anyway, which could cause problems as well.  Windows just sucks at telling high resolution time...

Might be easiest just to use the multimedia timers and crank up the resolution to 1ms.
Could possibly call timeBeginPeriod in some startup routine.  Not sure of the overhead or if it hurts to repeatedly call it like this.
Might also need to include mmsystem.h if not already present through windows.h

I don't have a functional netxms build system or else I would just try this myself.

Something like this in tools.cpp:


INT64 LIBNETXMS_EXPORTABLE GetCurrentTimeMs(void)
{
#ifdef _WIN32
 INT64 t;
 DWORD ms;
 timeBeginPeriod(1);
 t = (INT64)timeGetTime();
 timeEndPeriod(1);
#else
  struct timeval tv;
  INT64 t;

  gettimeofday(&tv, NULL);
  t = (INT64)tv.tv_sec * 1000 + (INT64)(tv.tv_usec / 10000);
#endif

  return t;
}


I had not noticed "save and apply".  I just pressed ctrl-s to save the file.  That means my manual restart fixed the problem, not my normalization of the line endings.  It would be nice to normalize the line endings, but is not as big of a problem as I first thought.

Thanks!

I used the Windows NetXMS 1.01 console on my windows server to edit the agent config file on a windows client machine.  After doing so, it appears the new nxagentd.conf file on the client had some lines with dos line endings and some line with unix line endings.  The line endings should probably be normalized for the platform.

I'm not sure, but the mixed line endings may have been causing the agent to not honor my changes.  (I modified the file to have only dos line endings and restarted the agent and it then saw my changes.)

I setup a Windows XP SP3 client with a ping.nsm SubAgent and added a *PING section with the target of two IP addresses.  It appears the timing resolution is not large enough, since the one IP address has an average and last values of 0, but other tools show it should be around around 3-5ms.  It seems to be rounding anything less than 20ms down to zero.

The other IP address which is much farther away seems to be reporting valid values in the 260ms range.

Is this a known limitation of the ping subagent on windows?