[EMAIL PROTECTED] test]$ time ./path_test message size is 45
real 0m2.303s user 0m2.279s sys 0m0.004s [EMAIL PROTECTED] test]$ time ./xdr_test xdr message size is 80 real 0m6.830s user 0m6.805s sys 0m0.008s this is the results that i found in benchmarks between using xdr and ascii on the wire. both benchmarks look at the time to encode/decode a wire message 1 million times... both do pretty well .. xdr can handle about 146,413 msg/sec and a straight ascii message can be parsed about 434,783 times/sec... here is some examples of ascii messages... "cpu::user:20.2:system:0.0:nice:10.1:idle:69.7" "load::one:3.2:five:2.5:fifteen:1.1" "processes:1034:memory::used:4565" this message format is almost half as large as xdr and gets processed twice as fast. actually 45/4 ~= 11 bytes means that (even compared to our 2.x 8-byte message format) the new format's per/metric price is nearly as low just in terms of data.. and doesn't require any internal lookup table and we are sending a single message instead of 4 separate (dropping the cost of 3 headers at 52 bytes each for 156 bytes). again.. i'm not saying this is exactly what the wire format will be but i think it's close. it's fast compact and would be trivial for apps to plug into the monitoring wire. as an aside.. since we will be using explicit heartbeat messages (as we do now)... we'll be able to dramatically expand the time thresholds for every metric and reduce the number of messages (which we aren't doing now). -- matt
