I see your point, but I still think RRD is "good enough". If cisco/foundry/juniper added this to their respective OS's -- I'd be a happy camper... If they don't -- I won't lose sleep over it. --Phil -----Original Message----- From: Doug Clements [mailto:dsclements@linkline.com] Sent: Tuesday, July 23, 2002 2:12 AM To: pr@isprime.com Cc: nanog@merit.edu Subject: Re: PSINet/Cogent Latency ----- Original Message ----- From: "Phil Rosenthal" <pr@isprime.com> Subject: RE: PSINet/Cogent Latency
I don't think RRD is that bad if you are gonna check only every 5 minutes...
Again, perhaps I'm just missing something, but so lets say you measure
30 seconds late , and it thinks its on time -- So that one sample will
be higher , then the next one will be on time, so 30 seconds early for
that sample -- it will be lower. On the whole -- it will be accurate enough -- no?
If you're polling every 5 minutes, with 2 retrys per poll, and you miss 2 retrys, then your next poll will be 5 minutes late. It's not disastrous, but it's also not perfect. Again, peaks and vallys on your graph cost more than smooth lines, even with the same total bandwidth. Do you want to be the one to tell your customers your billing setup is "accurate enough", and especially that it's going to have a tendancy to be "accurate enough" in your favor?
Besides I think RRD has a bunch of things built in to deal with precisely this problem.
Wouldn't that be just spiffy!
I'm not saying a hardware solution can't be better -- but it is likely
overkill compared to a few cheap intels running RRD -- assuming your snmpd can deal with the load...
No extra hardware needed. I think the desired solution was integration into the router. The data is already there, you just need software to compile it and ship it out via a reliable reporting mechanism. For being relatively simple, it's a nice idea that it could replace the "almost" in an "almost accurate" billing process. --Doug