Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Problems using perfSONAR-UI to plot graphs

Subject: perfsonar development work

List archive

Re: [pS-dev] Problems using perfSONAR-UI to plot graphs


Chronological Thread 
  • From: Nina Jeliazkova <>
  • To: Martin Swany <>
  • Cc: Fausto Vetter <>, perfsonar-dev <>
  • Subject: Re: [pS-dev] Problems using perfSONAR-UI to plot graphs
  • Date: Wed, 19 Sep 2007 11:38:10 +0300

Hi Martin,

Martin Swany написа:
> Hi Nina, All,
>
> Yes, we should have a better way to describe the units in use and
> standardize common ones. However, my perspective has also
> been that:
>
> 1) it's easy for a client to say "I don't understand X" (rather than
> silently failing)
>
PerfsonarUI gives such messages in debug log, I'm working on some more
user friendly way for errors processing.

for utilization
2007-09-19 11:29:00,312
[http://150.162.248.28:8081/soc/plugins/perfsonar/web/CACTISonar.php]
ERROR org.perfsonar.perfsonarui.ma.MARequestPerfsonar2_0 -
org.perfsonar.perfsonarui.UnsupportedTypeException: bits/sec

for errors
2007-09-19 11:32:32,140 [] ERROR
org.perfsonar.perfsonarui.ma.MARequestPerfsonar2_0 -
org.perfsonar.perfsonarui.UnsupportedTypeException: errors/sec

for discards
2007-09-19 11:33:00,625 [Interface details] ERROR
org.perfsonar.perfsonarui.ma.MARequestPerfsonar2_0 -
org.perfsonar.perfsonarui.UnsupportedTypeException: discards/sec

> 2) for basic value/time graphing, the units are just a string that
> describes the Y axis and it (conceivably) shouldn't matter too
> much
>
While I can agree this is true for counters like errors/drops, for
utilization it is essential to know if the value is in bits or bytes.

The recent changes in PerfsonarUI code took the most conservative way of
handling time/value pairs, i.e., allowing only for predefined value
units (org.perfsonar.perfsonarui.plugins.PSTypedValue and derived
types). It seemed to us this is the most error prone way, rather than
not paying attention to the units specified. Of course we are open for
suggestions that are more suitable from user point of view.

> I'm not being critical of the way that things are done. I agree that
> we need a better way to specify capabilities in services. The key
> is that there is a tradeoff between over-specification and extensibility.
Exactly.

> As we move forward, we need to think carefully about where we
> must specify, negotiate, or "be liberal in what we accept".
>
Best regards,
Nina
> best,
> martin
>
>
>> Hi Fausto,
>>
>> Having a look on the response, my best guess is valueunits
>> "errors/sec" is causing the problem. PerfsonarUI understands so far
>> "Eps" for input errors and "Dps" for output drops (these were
>> suggested by some time ago on the list and used in current services)
>> , "Bps", "bps" and "octets" for utilization.
>>
>> This brings us once again to the need to have standardized list of
>> valid units.
>>
>> Best regards,
>> Nina
>>
>>
>> Fausto Vetter написа:
>>> Hi Nina,
>>>
>>> I am trying to validate my RRDMA service I am implementing to
>>> CACTISonar. I tryed to test it using the last version available and
>>> I am not being successful. I tryed to compare the results I sent and
>>> other services also do, and to me they look very similar. But even
>>> this way I am not getting perfsonar-ui plotting graphs correctly.
>>> Attached it goes 2 documents: a request and a response message I
>>> observed. Why do you think it is going wrong now? Do you have any
>>> idea? Is the response message not well formed? Once I had done it
>>> and it worked fine (last schema version and the version prior this
>>> last one of perfsonar-ui).
>>>
>>> If you wanna test it, perfsonar-ui line configuration is:
>>>
>>> Fausto,http://150.162.248.28:8081/soc/plugins/perfsonar/web/CACTISonar.php,http://schemas.perfsonar.net/2.0,,http://ggf.org/ns/nmwg/characteristic/utilization/2.0,http://ggf.org/ns/nmwg/characteristic/utilization/2.0
>>>
>>>
>>> Thanks a lot.
>>>
>>
>> -- --------------------------------- Dr. Nina Nikolova-Jeliazkova
>> Institute for Parallel Processing Bulgarian Academy of Sciences Acad.
>> G. Bonchev St 25-A 1113 Sofia, Bulgaria Tel: +359 886 802011 ICQ:
>> 10705013 www: http://ambit.acad.bg/nina
>> --------------------------------- PGP Public Key
>> http://cert.acad.bg/pgp-keys/keys/nina-nikolova-0xEEABA669.asc 8E99
>> 8BAD D804 1A43 27B7 7F87 CF04 C7D1 EEAB A669
>> ---------------------------------------------------------------
>

--
---------------------------------
Dr. Nina Nikolova-Jeliazkova
Institute for Parallel Processing
Bulgarian Academy of Sciences
Acad. G. Bonchev St 25-A
1113 Sofia, Bulgaria
Tel: +359 886 802011
ICQ: 10705013
www: http://ambit.acad.bg/nina
---------------------------------
PGP Public Key
http://cert.acad.bg/pgp-keys/keys/nina-nikolova-0xEEABA669.asc
8E99 8BAD D804 1A43 27B7 7F87 CF04 C7D1 EEAB A669
---------------------------------------------------------------




Archive powered by MHonArc 2.6.16.

Top of Page