Dave Crocker (dcrocker@TWG.COM)
23 Mar 88 09:12:00 PST
As with most technical choices, each alternative has its appropriate uses.
The concern about reliability of processing, expressed by Vint, seems not
to apply to many of the current "intelligent-board" solutions. Their
interface to the host is essentially -- often exactly -- like accessing
standard primary memory. So, if you don't trust your primary memory,
you probably have more serious architectural fish to fry that where you
put your protocol processing. When the interface is more channel-oriented,
then reliability becomes factor. That is, if you need a serious protocol,
to access your protocols, there is a reasonable chance that the access
protocol has bugs, so that you have a step in the networking chain
truly exposed to problems, and not detectable by the end-to-end
safety mechanism of the transport protocol.
On the other hand,
There is some interesting mythology about the benefits of moving your
protocols to an intelligent board. Having a slow board and a fast
host has become a very significant issue, as discussed in some
messages, already. My only comment is that when making a choice, you
should pay close attention to this issue.
Less well-understood are some beliefs that the intelligent board
makes the host less complex and relieves the host of substantial
overhead. This is true only sometimes. The only factor that is
always nicer about intelligent boards is that they do the checksum
On the other hand,
They significantly increase the cost of networking hardware. They
tend to limit the number of virtual circuits that you can have, due to
memory limitations on the board -- a factor that is becoming less of
a problem, with 512K and 1M boards. They tend to make multiple-interface
configurations a problem, since you then have to add complexity to the
host, anyhow, to coordinate the cards.
That is, when you move the protocols to the board, then multiple
boards become multiple protocol implementations. Coordinating IP
routing, UDP and TCP Port number allocation, etc, becomes a real
hassle. Worse, customers seem to be inclined to try to do this
with implementations from different vendors(!)
The idea that intelligent boards reduce interrupt overhead sounds
appealing, but often does not prove out. Most incoming packets
have their data handed immediately to the receiving application, so
that the network interrupt, caused when the packet arrives, still
causes the o/s device driver -- yup, you still need such a beast when
you have intelligent boards -- to interrupt and you still have the
kernel/user context switch. In the case of heavy traffic with
small packets, the intelligent board does have an edge. Otherwise,
the host-based solution seems to be a much more efficient use of
Now, suppose that you have a host that is tending towards saturation and
you believe that the extra processing on the board will relieve the
problem. At one level of analysis, you would be correct.
On the other hand,
It is a very short-sighted way to solve a system congestion problem. If
your host has a problem at that level, you probably have only bought yourself
relief for a short time. In all likelihood, you need to get yourself
Given that most machines are in the micro-computer and small-minicomputer
range, this expense is not necessarily onerous.
Now, about the idea of having a non-networking-oriented access
model for the software, such as the view of fitting the network in
as a portion of a process's address space, so that the software need
not be aware of networking; it simply thinks that it is doing memory
transfers, and the underlying hardware/software handle the rest...
For general, "distributed processing" types of activities, this
will, no doubt, prove very, very useful. In essence, it is the
natural evolution down the path that includes the remote procedure
call model, since you are integrating networking into increasingly
"natural" computing models.
This, also, is its problem. While it often is very nice to hide
networking issues, it often is necessary to manipulate them directly.
Allowing a program to ignore the issues is great. Preventing it from
paying attention is terrible.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:31 GMT