perfsonar development work

[Giovanni Cesaroni <>]

Hi Vedrin,
thank you for your prompt reply.
I have some comments

Vedrin Jeliazkov wrote:

Hi Giovanni,

Many thanks for your report. The described behaviour is expected. It is due to
a combination of conditions, which in some cases happen to be true
simultaneously.

Here are some more details:

1) There are two interfaces in your MA, for which perfsonarUI-v0.08 produces
N/A utilization values in the summary table as well. The corresponding IP
addresses are:

192.168.11.1
192.168.11.2
  

these are private IP addresses that I get automatically from a database.
I'll add some lines to remove these addresses to my script which generate the xml registry file.

The reason for this is that the received response is empty. It might be due to
some configuration problem.

2) There are another four interfaces in your MA, for which no fresh
utilization data is published since the end of November. The corresponding IP
addresses are:

193.206.134.174
193.206.134.173
193.206.134.170
193.206.134.169
  

These ip addresses correspond to 4 dismissed links.
I have to update the xml on eXist.

For these 4 interfaces PerfsonarUI-v0.08 reports 0 utilization, while
perfsonarUI-v0.09 reports N/A if there is no data for the selected time
period. The correct behaviour is the later, because the message content in
both cases is something like:

<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"
id="localhost.localdomain.-70321a6b:1102b61e8e7:-2023">
  <nmwg:metadata id="meta117">
    <netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/"
id="subj117">
      <nmwgt:interface xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
        <nmwgt:hostName>rt.na1.garr.net</nmwgt:hostName>
        <nmwgt:ifName>at-3/0/0.160</nmwgt:ifName>
        <nmwgt:ifDescription>PoP-NA -- PoP-NA1 Link 1</nmwgt:ifDescription>
        <nmwgt:ifAddress type="ipv4">193.206.134.169</nmwgt:ifAddress>
        <nmwgt:direction>in</nmwgt:direction>
        <nmwgt:authRealm>GARR</nmwgt:authRealm>
        <nmwgt:capacity>155000000</nmwgt:capacity>
      </nmwgt:interface>
    </netutil:subject>
    <nmwg:eventType>utilization</nmwg:eventType>
  </nmwg:metadata>
  <nmwg:data id="localhost.localdomain.-70321a6b:1102b61e8e7:-2024"
metadataIdRef="meta117">
    <nmwg:datum timeValue="1168952700" value="NaN" />
    <nmwg:datum timeValue="1168953000" value="NaN" />
    <nmwg:datum timeValue="1168953300" value="NaN" />
    <nmwg:datum timeValue="1168953600" value="NaN" />
    <nmwg:datum timeValue="1168953900" value="NaN" />
    <nmwg:datum timeValue="1168954200" value="NaN" />
    <nmwg:datum timeValue="1168954500" value="NaN" />
    <nmwg:datum timeValue="1168954800" value="NaN" />
    <nmwg:datum timeValue="1168955100" value="NaN" />
    <nmwg:datum timeValue="1168955400" value="NaN" />
    <nmwg:datum timeValue="1168955700" value="NaN" />
    <nmwg:datum timeValue="1168956000" value="NaN" />
    <nmwg:datum timeValue="1168956300" value="NaN" />
    <nmwg:datum timeValue="1168956600" value="NaN" />
    <nmwg:datum timeValue="1168956900" value="NaN" />
    <nmwg:datum timeValue="1168957200" value="NaN" />
    <nmwg:datum timeValue="1168957500" value="NaN" />
    <nmwg:datum timeValue="1168957800" value="NaN" />
    <nmwg:datum timeValue="1168958100" value="NaN" />
  </nmwg:data>
</nmwg:message>

In fact, perfsonarUI-v.08 used to replace NaN with 0, which is misleading and
undesirable.
  

I think there is something more besides points 3 and 4 (for perfsonar.jnlp).
The problem appears with addresses like 193.206.134.53 .
If I request data searching by interface IP, specifying the single IP address,
I should not get any aggregation nor overloading problems, but still v0.09 (perfsonar.jnlp) doesn't work while v0.08 works.

As you predicted, I found a different result with perfsonar-noapr.jnlp
It works specifying the single IP address, but not requesting a retrive all.

Regards,
Giovanni

3) When aggregation of requests is enabled in perfsonarUI-v0.09 (as it is in
the default JNLP version available online), a problem with a single interface
in an aggregated query could invalidate the whole query and lead to missing
info for correctly configured/reported interfaces, sharing the same aggregated
query/response. This is actually a protocol design issue, which needs to be
addressed.

4) Certain services become easily overloaded when a high number of parallel
(and/or aggregated) requests have to be processed. This is also an issue,
which has to be addressed by service developers. In cases when an answer is
not received by the client for a given period of time, the corresponding
entries are marked as N/A. We could consider displaying another value in case
of timeouts.

While playing with an alternative perfsonarUI-v0.09 setup, temporarily
available online here:

http://perfsonar.acad.bg/perfsonar-noapr.jnlp

we were able to get correct data for all your interfaces, except those
mentioned in (1). The difference is that this perfsonarUI-v0.09 instance is
configured to avoid parallel and aggregated queries. In addition, a longer
time period for summary statistics has to be selected in order to get data for
the four interfaces mentioned in (2) - "Last 3 months" or "Last year".

Best regards,
Vedrin

Giovanni Cesaroni  wrote:

  

Hi all,
I found a problem with the perfSONAR UI v 0.09.
I don't know if it is a known issue.
In the table "Select Interface" some links have an N/A value on 
Inbound/Outbound Utilization,
while the utilization statistics are correct.
The problem does not happen in the previous version.
See the highlighted link in the images below.

UI v 0.09


UI v 0.08


Regards,
Giovanni
    

-- 
Giovanni Cesaroni

..............................................
CONSORTIUM GARR
The Italian Academic and Research Network

Network Operation Center
Tel.  06 4336 1488/52
Fax   06 4336 1444
E-mail 
..............................................