Subject: Mac Network business - further investigation - Are you a hacked sheep_net user?
From: Charles McLachlan (cim@uk.research.att.com)
Date: Mon May 22 2000 - 03:08:53 MDT
I originally designed my sheep_net hack (which Samuel has kindly included on
0.9.43) as a stop gap solution until the real problem could be found and
fixed, but it now seems that the real problem (emulated Mac can't deal with
packets fast enough) may be a hard limit imposed by the 3 or 4 context
switches/ memory copies/ signals required to process each packet. (see below
for details of further investigation). Hence, my solution might actually be
the right way of doing it.
All this means it might be a good idea if I made sure it was working the way
I intended it to.
The current method is to start off with no filtering. Once the emulated Mac
sends an IP packet, the filter records its IP address and filters incoming
traffic so that only packets destined for that address are passed. Only
TCP/UDP is filtered. All other packets are let through. The filter is reset
on each out going IP packet, so if the Mac changes its mind about what IP
address it is using, the filter will still work.
Issues:
1) The Mac still has to face the onslought of an unfiltered network on
startup. This may make startup a bit slow.
2) All other packets (ARP etc) are passed. Therefore, on networks with a
large amount of non TCP/UDP traffic, the filter might not be effective.
I work on a 10baseT that is heavily loaded with small UDP packets. Neither of
the above issues effect me.
I've read others on this list talking about EtherTap (or something) that I
presume is somesort of IP filter.
What I want is feedback from Ethertap and hacked sheep_net users, especially
from people who are effected by the issues mentioned above.
Does hacked sheep_net help? Does it play well with EtherTap?
There now follows details of an experiment I did to see if the sheep_net hack
was actually needed. This probably won't be of interest to everyone.
------------------------------------------------------
I hacked osi_enet to remove its internal packet spool
Original situation (3 spool) situation
- sheep_net reads packets and remembers them.
- osi_enat polls /dev/sheep_net, reads packets, remembers them, signals the
emulated Mac via an irq.
- Emulated Mac responds to the irq, reads packets and remembers them.
This had the problem that if the network is heavily loaded, all 3 spools fill
up and it all goes wrong (error messages stream out, teriffic numbers of
important packets are lost, MOL goes so slowly as to appear locked).
Hacked solution (2 spool) situtuation
- sheep_net reads packets and remembers them
- a thread in osi_enet, polls /dev/sheep_net and reads a single packet. It
then signals the emulated Mac (via the irq) and waits until it reads the
packet.
- Emulated Mac responds to the irq, reads packets and remembers them.
This cuts down on packet spooling and hence reduces the number of packets
lost. But, it slows down MOL even more, to the point of un-usability.
In conclusion, it seems to me that MOL *cannot* work when it it expected to
deal with all packets. There has to be some level of filtering.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Charlie McLachlan AT&T Research Lab. Cambridge. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This archive was generated by hypermail 2a24 : Mon May 22 2000 - 03:08:21 MDT