On Oct 27, 2013, at 11:22 AM, Adam Armstrong adama@memetic.org wrote:
On 2013-10-27 17:10, Tyler Christiansen wrote:
On Oct 27, 2013, at 9:49 AM, Jason Lixfeld jason@lixfeld.ca wrote: One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked). Whether they're interested in supporting feature requests of their general user base or not isn't really what I'm getting at. I didn't say "help, I'm completely clueless." I offered helpful feedback. I identified an issue with the code. I showed how it could be improved by examining the OIDs from the RFCs, and I proved that it could be improved through a series of tests and by writing a patch for my own installation. In return, I was told to "fuck off" and removed from the list.
No you didn't, you made a bunch of incorrect assumptions and then proceeded to screech about them repeatedly. We've already been through all of this, you just seem to want to be right about something, anything.
We're quite well aware of what the MIBs contain and which parts are useful. You're not offering anything helpful beyond a lot of moaning and finger pointing, you're wasting everyone's time.
If they aren't interested in my patch or in performance issues being identified--fine. There's not really a reason to tell someone who offered feedback to "fuck off" and then remove them from a mailing list.
You've been told before that you're wrong, but you're still harping on about it, trying a different avenue to find people who'll make you feel clever. You're not, you're wrong.
I'm quite certain that all you've done is stopped the poller walking if[In|Out][Octets|UPkts|NUPkts] and have declared yourself victorious, of course completely ignorant to the fact that you've broken polling for anyone who's devices don't return 64-bit values for certain types of ports.
I removed more than those 6 MIBs, and I'm well aware that it breaks polling for users whose devices don't support 64-bit counters, which is why I haven't offered it as an official solution or patch. And no, it hasn't broken anything in my installation.
The point of this was tests showing how much time is wasted on any given device, not to say "I know how to do this better than you."
There are performance improvements that can be made to the ports poller, we know where they are and how to do them, we just haven't gotten around to fixing them yet.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code. I am actually curious if it's a Juniper-only issue. Does anyone have anything with around 300 or 400 ports on a _single_ device that they are polling over a respectable distance? If so, what are your poll times like?
I've rarely monitored devices with less than 400 ports.
You've proved in a number of emails that you're only interested in ranting and being right, without actually bothering to look at the code at all. In your first email you didn't even seem to know that we use bulkwalk! In later emails you don't seem to have worked out how we do 32/64 bit decision, despite having claimed to have read and optimised the code.
I'm also aware that you use bulkwalk. All of my tests used bulkwalk. I never suggested that you didn't, only that you request OIDs in serial instead of in parallel. The use of bulkwalk doesn't change the fact that it's still polled in serial for a single device.
Regarding the 32- and 64-bit decision, it's not a very good decision when you're still polling both 32- and 64-bit for devices.
I think you're an unhelpful timewasting bullshitter, and I'd much prefer if you went back to Cacti and stopped wasting our time.
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so. Again, that's fine, but the response was a bit…excessive, particularly considering I am only trying to point out ways that the product can be improved. I actually like Observium.
Observium doesn't like you. Shoo.
I was considering a subscription, but I think I'll pass.
I'll "shoo," but not because Observium doesn't like me. I'll "shoo" because I don't like you and your obscenely unprofessional attitude.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium