Subject: Re: Networking strangeness Solution?
From: Charles McLachlan (cim@uk.research.att.com)
Date: Tue May 09 2000 - 11:31:07 MDT
Warning: Quite a lot of this is a based on guesses and may well be wrong.
On Tue, 09 May 2000, you wrote:
> 1. You mention it messes up NFS. Is that NFS on the
> Linux side, or the MOL side? Care to elaborate on
> what the side effect to NFS is on your solution?
My set up:
Intel Box A --|
|
100baseT Switch ------ Rest of the world ----- Intel Box B
|
G3 -----------|
After hacking sheep_net, Intel box A refuses to nfs mount the shares exported
(by Linux via /etc/exports) from the G3. The G3 will mount the shares from Intel
box A. Intel Box B will mount the nfs shares from both the G3 and Intel box B.
Both G3 and Intel A can mount Intel B.
Workaround: rlogin to Intel box B if I want to fiddle with the G3's files (The
G3 has no monitor, keyboard or mouse)
Note: This may well be a combination of the switch getting confused by two
separate ip addresses on the same Mac address, and nfs's fusiness over dropped
packets.
My Mac environment (running in MOL) knows nothing (and cares less) about NFS so
I can't really help there.
> 2. We also see a similar problem on the Appletalk side of the fence.
Intel Box A is running atalkd. My Mac envirnment can see this but I haven't
actually tried using it.
> I believe the error message on this one is something like
> "Warning Ethernet packet dropped" (from memory, not an exact
"Warning: packet dropped" is what osi_enet says when its receive queue (fixed
length of 32 packets) fills up. I first tried increasing the size of this to 320
but to no avail. The packets that fill up this queue come from sheep_net, and
most of them have nothing to do with MOL. Hence my hack. It stops sheep_net
filling up osi_enet's buffer with packets that it doesn't need to bother
with. The "can't allocate datas" message comes from the Mac side driver when
*its* receive buffer is full. As this driver gets its packets from osi_enet then
reducing the load on osi_enet helps this problem as well.
Of course, when the Mac (inside MOL) gets sent a load of packets that really
are meant for it (like when doing a big download), you're back to square one,
sheep_net sends them to osi_enet faster than it can deal with them and you get
"Warning: packet dropped", then the Mac side driver clogs up and you get "Can't
allocate datas".
It must be said that none of this is totally bad, the system *will* recover once
the network load drops, and no actual data is lost (it just has to be resent).
But because two spearate receive buffers are filling up and a load of useless
data is being copied all over the shop, (with associated irq spoofings and mode
switches) it can slow things to a halt on busy networks.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Charlie McLachlan AT&T Research Lab. Cambridge. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This archive was generated by hypermail 2a24 : Tue May 09 2000 - 11:58:33 MDT