Re: Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?
On Sun, Dec 11, 2011 at 11:24:45AM -0800, Brian Buhrow wrote: hello. I'm interested in seeing detailed errors like CRC, frame, underrun and overrun error counts. Further investigation reveals that drivers that came later in the game, i.e. nfe(4) and age(4) don't have latent support for these counters, but it looks fairly easily added. I think it's up to the driver's author discretion, and maybe debugging history (I remember adding such counters to a driver for debugging purpose). While I understand performance considerations are necessary, the counters I'm proposing to add should be fairly low frequency events, since we already count bytes and packets in and out, and if the performance of the event counters infrastructure were really a problem, we should be taking a hit because many of the interrupt counters are using it to keep their statistics. I don't think performances would be a problem, at last with modern nics, because statistics are gathered internally by the NIC and the driver updates its copy periodically, but not necesserely for each transmitted or received packets. While I don't aspire to be like Linux, Linux does report these kinds of errors, as do most modern networking devices. I think we should hav the capability of tracking such errors, and I think we can for little effort and almost no performance loss. Since there's been some nervousness expressed to me about performance hits, I propose to do one driver at a time, do some testing of mine, then commit those changes to the tree. We can either set the COUNT_INTERFACE_EVENTS option to true at that time, or have a self selected group do some early testing. However, it is my wish to have this higher granularity of error tracking turned on by default in future releases of NetBSD. If we want to add support for this, I'd suggest adding this to the statistics reported by netstat -i, instead of driver-specific event counters. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?
On Sat, Dec 10, 2011 at 05:04:41AM -0800, Brian Buhrow wrote: Hello. I notice that most, if not all, of the network drivers in NetBSD have interface counters which they use to track things like collisions, CRC errors, framing errors, etc. It looks like these counters, You have these informations (with less granularity I admit) in netstat -i outtput. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?
hello. I'm interested in seeing detailed errors like CRC, frame, underrun and overrun error counts. Further investigation reveals that drivers that came later in the game, i.e. nfe(4) and age(4) don't have latent support for these counters, but it looks fairly easily added. While I understand performance considerations are necessary, the counters I'm proposing to add should be fairly low frequency events, since we already count bytes and packets in and out, and if the performance of the event counters infrastructure were really a problem, we should be taking a hit because many of the interrupt counters are using it to keep their statistics. While I don't aspire to be like Linux, Linux does report these kinds of errors, as do most modern networking devices. I think we should hav the capability of tracking such errors, and I think we can for little effort and almost no performance loss. Since there's been some nervousness expressed to me about performance hits, I propose to do one driver at a time, do some testing of mine, then commit those changes to the tree. We can either set the COUNT_INTERFACE_EVENTS option to true at that time, or have a self selected group do some early testing. However, it is my wish to have this higher granularity of error tracking turned on by default in future releases of NetBSD. -thanks -Brian On Dec 11, 1:18pm, Manuel Bouyer wrote: } Subject: Re: Using event counters with network interfaces, is there a reas } On Sat, Dec 10, 2011 at 05:04:41AM -0800, Brian Buhrow wrote: } Hello. I notice that most, if not all, of the network drivers in } NetBSD have interface counters which they use to track things like } collisions, CRC errors, framing errors, etc. It looks like these counters, } } You have these informations (with less granularity I admit) in } netstat -i outtput. } } -- } Manuel Bouyer bou...@antioche.eu.org } NetBSD: 26 ans d'experience feront toujours la difference } -- -- End of excerpt from Manuel Bouyer
Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?
Hello. I notice that most, if not all, of the network drivers in NetBSD have interface counters which they use to track things like collisions, CRC errors, framing errors, etc. It looks like these counters, and the framework for displayng these counters has been in NetBSD for well over 10 yers, yet, all of these counters are ifdefed out of general use and hence unavailable to those users who use generic kernels, or who didn't happen to pursue what those EVENT_COUNTERS ifdefs meant in the various drivers. Is there a reason all of these counting facilities are not enabled by default in GENERIC kernels? Does using these counters impose such a performance penalty that general use was deemed too crippling? I think having these counting facilities available to the general NetBSD user would be a huge win. As such, I propose to embark on a project to enable such counters in GENERIC kernels so that users may view these extended stats about their network performance. I'll note that event counters seem to be enabled in the NetBSD-5.x kernels to do things like count the number of tlb flushes, ioapic interrupts and the like. If it works for those high frequency items, why not enable it for network drivers? My thought is to define a generic option, say ENABLE_INTERFACE_COUNTERS, which would turn on these counters for drivers which had been tested and were known to work. Then, for each driver, enable its counting options and test. Finally, once local testing was complete, check in a change for that driver which would hook it to the general cunting option, and, as a result, add that driver's counting capabilities to the GENERIC kernel. Is there a reason this should not be done? Are there caveats that I need to be aware of? Having event stats on network interfaces would be a huge bonus for NetBSD's usability and, since it looks like it's almost there, why not make it happen? thoughts? Objections? Encouragement? -thanks -Brian
Re: Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?
drivers. Is there a reason all of these counting facilities are not enabled by default in GENERIC kernels? Does using these counters impose such a performance penalty that general use was deemed too crippling? Do you try any benchmark? (by ttcp(1) etc.) During mec(4) (on sgimips O2) debugging, enabling evcnts made network xfer notably slower, but probably it depends on how many counters the driver has and how often they are called. I think we need benchmark results per interfaces rather than blindly enabling counters, because most ordinary users don't care driver internals but just visible xfer rates. --- Izumi Tsutsui
