site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Thunderbird 2.0.0.12 (X11/20080228) Michael Cashwell wrote: Well, there's a grey area here between what is "correct" and what is allowed. William Kucharski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I'd just run across the "UDP == throw-away" mindset in William's post in other contexts (mainly sysadmins configuring routers) and wanted to point out that it's not really correct in all cases. If a particular router or system wanted to pass (being silly here) one UDP packet per hour, it could and wouldn't be violating any of the rules of IP networking. That doesn't mean it's a bad idea to drop those packets, but it's not technically incorrect behavior to do so. In this particular case, the fact that ring buffer overflow messages are being generated seems indicative that the behavior is not what was intended by the driver authors. The fact that Linux does not display a similar error when run on the same hardware seems to back up this point, but at the same time we don't know what Mac OS X's priorities are when it comes to maintaining isochronous system events. It may have perfectly good reasons it believes it's OK to let the ring buffer overflow. Nevertheless, the fact that so much CPU is being consumed to process the UDP packets is pretty much evidence to me that something isn't working the way it was designed, or putting a Mac OS X box on any busy network segment would be enough to bring it to its knees. (Stupid trivia fact: Did you know that dealing with network interrupts is an OLD Mac problem? Back in 1988, putting a Mac II (68020 + PMMU) running A/UX 1.0 or 1.1 on a busy Ethernet network would cause the Mac to first choke then shut off its Ethernet card entirely as it just couldn't handle the traffic properly.) This email sent to site_archiver@lists.apple.com