perfsonar development work

["Nina Jeliazkova" <>]

Hello Szymon,

We have analyzed the problems you’ve reported and came to the following
conclusions:

1) N/A values in perfsonarUI’s summary table and bar chart (when data is
actually available in the service) are most probably due to an unresolved
issue either in client/server side Axis or in the RRD MA service itself. The
problem is occurring whenever aggregated and/or parallel requests are sent
through Axis calls and is more frequently exhibited when more queries are
aggregated in a single Axis call. The N/A values correspond to broken strings
(e.g. for eventType or other query parameters), reported by the service:

<nmwg:data id="resultDescriptionData_for_resultCodeMetadata_22"
metadataIdRef="resultCodeMetadata_22">
    <nmwgr:datum
xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>MetadataQueryGeneratorFactory.getMetadataQueryGenerator:
eventType f.org/ns/nmwg/characteristic/utilization/2.0 is not
supported</nmwgr:datum>
  </nmwg:data>

This happens for random interfaces and random positions in the parameter
strings. However, perfsonarUI sends the correct strings in its queries,
regardless if they’re aggregated, parallel or simple. As a workaround we have
reduced the default level of query aggregation from 32 to 8 interfaces which
mitigates the issue for PIONIER RRD MA. However, even with these more
conservative settings some erroneous N/A values are reported by GEANT RRD MA,
illustrating the fact that the problem depends on other factors as well (e.g.
number of available interfaces in a given RRD MA, load of the RRD MA, etc). We
have reproduced the above problem with the Python client as well, which points
to the server side Axis or the RRD MA service itself as the culprit, because
the Python client doesn’t use client side Axis and moreover is a completely
independent client implementation.

2) PIONIER’s RRD MA contains one interface with no utilization data associated
(so the reported N/A values are expected):

Hostname        poznan-gw1.rtr.pionier.gov.pl
IP Address      212.191.224.90
Interface name  ge-2/1/0.111
Interface description   Slask at poznan-gw1 10GE
Capacity        1000000000
Resolution      300
Key     localhost.50d15574:1138643848f:-27e

3) PIONIER’s RRD MA contains one interface which is defined in a different way
for in/out directions:

Hostname        poznan-gw1.rtr.pionier.gov.pl
IP Address      212.191.224.58
Interface name  ge-2/1/0.116
Interface description   Czestochowa at poznan-gw1 10GE
Capacity        1000000000
Resolution      300
Key     localhost.50d15574:1138643848f:-254

vs.

Hostname        poznan-gw1.rtr.pionier.gov.pl
IP Address      212.191.224.58
Interface name  ge-2/1/0.116
Interface description   Czestochowa at poznan-wg1 10GE
Capacity        1000000000
Resolution      300
Key     localhost.50d15574:1138643848f:-25a

Please note the difference in interface description: poznan-gw1 vs.
poznan-wg1. The effect of this typo is that perfsonarUI considers those two
instances as separate interfaces and reports utilization for only one
direction (out or in respectively) for each of them. It could be fixed in your
metadata configuration file.

4) We have fixed perfsonarUI’s utilization graph at the bottom to report
trailing NaNs as Null rather than 0, which results in the behaviour you’ve
suggested.

Best regards,
Nina

PS: Reducing the level of aggregation has a big performance impact because the
response time is increased significantly in this case.




Szymon Trocha 
<>
 wrote:

> Hi Nina,
> 
> I was using pUIv0.10 with PIONIER RRD MA and noticed that numeric in/out 
> utilization differs from what is show on the graph. For instance when 
> you take interface no 7 (ge-2/1/0.102) outbound utilization is shown as 
> N/A while the utilization graph in Mb/s shows proper value all the time. 
> Similarly % util is not shown. The same is for some other interfaces.
> 
> Could you please try to investigate what could be wrong?
> 
> I also have one more comment to the Utilization Mb/s graph. Now the last 
> value on the graph is 0 and it looks strange to me as the lines are 
> drooping down suddenly from the one before last to zero. While in fact 
> there is no zero value at the end. usually in MRTG the lines showing 
> current values are aligned with the right edge of the graph. I think 
> it's more natural.
> 
> Regards,