Ken McDonell wrote:
On 28/08/2010 1:39 AM, Frank Ch. Eigler wrote:
The table below outlines some of the differences ... these help to
explain why PCP is /a priori/ not necessarily suitable for event
tracing.
I think another problem is the dynamic range of time scales. Event
tracing tracing tends to require analysis of behaviour that manifests at
wildly varying time scales in the same trace, from the tens of seconds
down to the microseconds. PCP's front ends are not very good at doing
this kind of thing, and don't really handle zooming or LoD or
bookmarking well.
* no web-based frontends
In our usage, it would be desirable to have some mini pcp-gui that
is based on web technologies rather than QT.
There are several examples of web interfaces driven by PCP data ...
but each of these has been developed as a proprietary and specific
application and hence is not included in the PCP open source
distribution. The PCP APIs provide all the services needed to build
something like this.
Myself and at least one other person on the PCP list have been involved
with designing three generations of one such proprietary web front end,
and we found it quite a difficult problem to solve. The main issue was
that the PCP architecture is basically a stateless client-driven pull,
so that any operation which needs to maintain state across multiple
samples (like time averages, or rate conversion of counters) needs to be
done all the way out in the client. Our browser requirements prevented
us from using Javascript, so we had no practical way to do that, and had
to insert a caching/rate conversion/averaging daemon in between. That
daemon proved...troublesome. These days a JS + AJAX + SVG solution
would probably do the trick nicely, and would be interesting to write.
Also, Frank: you mentioned NFS in passing; I'm curious as to what
exactly you're up to?
--
Greg.
|