Re: Network stack/ethernet driver issues
Re: Network stack/ethernet driver issues
- Subject: Re: Network stack/ethernet driver issues
- From: Michael Cashwell <email@hidden>
- Date: Fri, 11 Apr 2008 09:57:08 -0400
On Apr 11, 2008, at 9:25 AM, William Kucharski wrote:
Michael Cashwell wrote:
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.
Well, there's a grey area here between what is "correct" and what is
allowed.
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.
Oh yes, absolutely. Systems often have their own policies. Some are
boneheaded, but it's their kit.
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.
Again, absolutely correct. I wouldn't be surprised if it's a tuning
issue to make the graphical UI or Quicktime more responsive or to
reduce the amount of wired memory. The error message does very much
suggest that the driver writers were expecting to be able to fully
handle the hardware, as you say. So there's some disconnect somewhere.
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.
Indeed. And I'm glad to see the Apple folks strongly request a bug
report be entered because it certainly should not have that effect.
(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.)
No, hadn't heard about that one. I've done a lot more low-level work
on Macs since Mac OS X. Almost none before.
I did have fun doing first bring-up of an ATM PCI card on a dual-CPU
mirrored G4. My first attempt in testing out interrupts failed to
properly clear them and one of the two cores fell to its knees running
the ISR continuously. I noted the spike but the system was still
working fine so I continued on, found the bug, recompiled and only
then rebooted. (I tried to kextunload and not reboot but it was new
code and that went down in flames.)
A few weeks ago I got an 8-core MacPro and thought "Dual CPUs? Oh how
quaint." I spend a lot of time on dual-core laptops but it still
amazes me what one can get used to.
Happy Friday.
-Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden