[
Lists Home |
Date Index |
Thread Index
]
I'd like to thank everyone for the input thusfar. having whirled all the
input around in the blender that is my head I've come-up with some
changes to the format. I've nixed the explicit namespaces and decided
that until I or someone enhancing netperf encounter a problem with
conflict I'll just ignore it.
I'm also thinking that if I do write a DTD for this as a config file
(likely I would think - it sounds like Schema support is not yet
univeral among C-based free solutions) that I would define the
<specific> element to have a config, optional initconfig, optional
interval and optional result child elements, but will leave those child
elements as "ANY" (I think that is the right term?)
I'm still going back and forth on the advantages of having the test
elements be child elements of the netserver (renamed server) elements.
I'm also still a bit lost on the whole ID/IDREF thing - some of what
went by in unrelated but on the list email today implied that there
could only be one ID space in a document, and I seem to have two - one
for netservers and one for tests. Nesting a test in a netserver means
that when I want to find a companion test element I either want to know
the netserver identifier or I have to search all the netserver elements
for the corresponding test element identifier. On the plus side, the
association of test to netserver becomes a simple matter of parentage
(please, no questioning of parentage here :).
My config file definition appears to be expanding into one that also
encompases other stages of a benchmark run - the post-init state,
intermediate results, and the results. I like this because it implies
that as I build-up these things during a run I can just dump the entire
tree as the "results" file and take what I want in post processing. I
find the idea of keeping the netperf process rather stupid appealing. It
also implies that a results file could be (post processed and) used
directly as a config file when trying to reproduce a result. What
worries me is that this thing could become quite huge - watching the
--debug output of xmllint from libxml2 I see where bunches of empty and
otherwise useless TEXT things (elements?) are created during parsing.
It is also beginning to look like some of that is the "price" of
formatting the document for easier human reading (the indentation in
particular). I suppose I can look for options that say "ignore anything
that isn't in an element, it isn't important" - is that something
commonly available among parsers?
rick jones
<?xml version="1.0"?>
<netperf xmlns="http://www.netperf.org/ns/netperf";>
<netserver id="1">
<host family="AF_INET" port="12345">foo.bar.baz</host>
<test id="1">
<type>SEND_TCP_STREAM</type>
<library>libnettest_bsd.sl</library>
<!-- the companion is the companion test instance. of course the
open question is whether or not the dependent test instance
should be a child test element if netserver attribute is
present, it will be used to accelerate the lookup of the
companion test instance -->
<companion testid="2" netserverid="2"/>
<specific>
<!-- the initial configuration setup. some of the defaults will
be replaced with real values at run time - eg port numbers,
socket buffer sizes, etc -->
<config>
<source family="AF_INET" port="1234">foo.bar.baz</source>
<sndbuf units="B">32768</sndbuf>
<rcvbuf units="B">32768</rcvbuf>
<sendsize units="KB">4KB</sendsize>
<nodelay>0</nodelay>
<!-- not sure if I should keep these here or retrieve them by
following an IDREF to the setup section of the companion
test element. I think I need to keep them since related
test instances will be on separate systems -->
<destination family="AF_INET"
port="0">bin.fred.ethel</destination>
<sendalign>8</sendalign>
<sendoffset>0</sendoffset>
</config>
<!-- what all the setup parameters are after the test
instance has completed INIT processing. these may be queried
by a companion test instance and will most likely be included
in the benchmark report -->
<initresult>
<!-- most if not all things from a config element will be
found here. the difference between a config and an initresult
is that an initresult has no optional child elements -->
<mss units="B">1460</mss>
</initresult>
<!-- an interval is a snapshot of the results over an
interval. it may not be implemented at first but we'll have a
placeholder. there could be quite a few of these for a long
test -->
<interval>
<throughput units="Mb"
start="sometimetoseconds"
end="sometimetoseconds">123.45</throughput>
</interval>
<!-- the final result of the test from entry to and exit from
the MEASure state -->
<results>
<throughput units="Mb">123.45</throughput>
</results>
</specific>
</test>
</netserver>
<netserver id="2">
<host family="AF_INET" port="12345">bing.fred.ethel</host>
<test id="2">
<type>RECV_TCP_STREAM</type>
<library>libnettest_bsd.sl</library>
<companion idref="1"/>
<specific>
<config>
<source family="AF_INET" port="0">bing.fred.ethel</source>
<sndbuf units="KB">32</sndbuf>
<rcvbuf units="KB">32</rcvbuf>
<recvsize units="KB">4</recvsize>
<recvalign>8</recvalign>
<recvoffset>0</recvoffset>
</config>
<initresult>
</initresult>
<results>
</results>
</specific>
</test>
<test id="4">
<type>CPU_UTIL</type>
<library>libnettest_cpu.sl</library>
<specific>
<config>
<cpus>0</cpus>
</config>
<initresult>
<method method="P"/>
<cpus>4</cpus>
</initresult>
<result>
<throughput units="%">95.3</throughput>
</result>
</specific>
</test>
</netserver>
<netserver id="3">
<host family="AF_INET" port="12345">lucy.ricky.ricardo</host>
<test id="3">
<type>HTTP_DOWNLOAD</type>
<library>libnettest_curl.sl</library>
<specific>
<config>
<source family="AF_INET6" port="0">sys.boom.bah</source>
<urllist>url_list.txt</urllist>
</config>
<initresult>
</initresult>
<results>
</results>
</specific>
</test>
</netserver>
<!-- This is just another boring comment -->
</netperf>
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
|
