[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mystery hardware query
David Empson wrote:
Michael J. Mahon <mjmahon@aol.com> wrote:
For a software-driven network, it is quite time consuming to sense the
state of the bus to determine that another sender is interfering with
your transmission. Therefore, I would expect that collision avoidance
techniques were used (all in the arbitration phase) and that collision
detection existed only in the sense that a failed transmission checksum
was detected and retried.
Nestar did a brief negotiation using an arbitration handshake to confirm
that there was a single sender and recipient, followed by a burst of
data with checksum, and acknowledge. If the acknowledge was lost, the
sender retried (needing another arbitration phase).
Exactly what should be done--assuming that the gap between request,
acknowledgement, and subsequent data was short enough to inhibit any
other machine from successfully arbitrating in the "gap".
Or, as you suggest below, there may have been a dedicated "lock"
wire. While this is tolerable for a parallel bus, it does present
another failure mode. For a serial bus, it would be intolerable,
since it would double the electrical complexity of the bus.
A dedicated "lock" wire is generally avoidable, since the handshake
wire(s) will betray bus activity or idleness, and some state can be
chosen to represent a locked state during latency or other non-data
intervals.
Workstations weren't expecting to receive unsolicited data, so only the
server had to actively poll the network to look for incoming arbitration
requests. Workstations were then in an active polling state while
waiting for a response to a data request.
Also just as it should be. A peer-to-peer network would have all
possible receivers polling for any request. NadaNet has all receivers
receive the request packet to determine the addressee, which is then
the only one to acknowledge to the sender.
There were some special applications which did direct communication
between workstations, but they polled the network themselves.
Interesting! So there must have been published rules for protocols
so that they would all arbitrate compatibly.
There was no scheme for sending out notifications or alerts to
workstations, e.g. popup messages from the administrator.
This would only have been possible if workstations were regularly
polling the net (within some request timeout interval).
The majority of data was accessed using block-level operations, together
with a higher level command set for mounting and unmounting volumes. A
station would send a request packet, then wait for the reply. The server
would respond when it had data available. I expect there was no need for
an acknowledgement of the request, and the server wasn't able to queue
or schedule requests, so the network communication would look like this:
1. Workstation arbitrates for network access for sending to server,
identifying itself. (A collision at this point results in failed
arbitration and randomly timed retries by the workstations.)
Detecting a failed arbitration with a parallel network can be
done in ways not accessible to a serial network.
Most arbitration schemes have a small window for failure between
its last poll of the idle net and the first assertion of ownership
that is observable by other machines. Within this window, it is
possible for two machines to think they have "won" the arbitration.
Detecting that an arbitration collision has occurred requires some
data exchange to verify sole ownership. For a byte-wide bus with
8 or fewer possible masters, this is pretty easy. For more masters
it requires more data cycles.
If the window is made small enough (in comparison with the minimum
idle time required to sense a seizeable bus), then the probability
of arbitration collision is small enough that it is more efficient
to simply assume sole ownership and then detect the data error in
the subsequent control packet (which is recovered by re-arbitrating).
Since it is likely that two machines seeking to arbitrate for the bus
will start timing "idle" within a loop period of each other after an
in-process transaction completes, the vast majority of collisions are
easily avoided by causing each machine to wait for a unique amount of
"idle" time before attempting to seize the net.
This collision avoidance arbitration protocol is extremely effective
if the "win" ambiguity window described above is a very small fraction
of the minimum idle time for arbitration.
2. Server acknowledges to the workstation which it heard first.
Which will, of course, be the sole arbitration winner or an
error packet if a collision occurred. This acknowledgement
could be omitted and the workstation could simply start with
the next (request) message, leaving error detection to the
absence of response from the server.
3. Workstation sends request packet.
Essential, and could be the first packet transmitted.
4. Server processes request and sends reply.
This may involve some latency (disk accesses, etc.) and so
may require either locking the network during the latency period
or a two-phase "disconnect and reconnect later" protocol.
If latencies can be comparable to data transfer times, then
a two-phase protocol could be much more efficient, assuming
that requests can be queued.
5. Workstation acknowledges the reply.
If the data was sent to the workstation, and the workstation
made the request, this is unnecesary, since if the data was
not received correctly, the request can be repeated.
6. Network is released so another arbitration can occur.
And "release" could simply be a certain threshold of idle time
(different for each arbitrator).
If I can dig out the disassembled source code for the Nestar card, I
could confirm some of these details. I might not have got far enough
into the disassembly to fully understand this level of the protocol. I
only needed to find out how to replicate the Pascal block I/O protocol
so I could implement a ProDOS block driver which sent the same messages.
Protocol design is a very interesting subject, since every protocol must
be analyzed from at least four perspectives:
1. Requestor,
2. Server,
3. Other requestors waiting to arbitrate, and
4. Other listeners (servers) not involved in the request.
One seeks the best combination of simplicity, performance, robustness,
and, sometimes, fairness in designing a protocol. In my experience,
cnsiderable analysis is beneficial under different assumptions of
traffic and loading.
> Don't know how it dealt with fan-out problems or transmission line
> effects like signal reflections. I don't recall anything like a
> terminator as a separate component, or as a switch setting on the "end"
> cards.
At Apple II signalling speeds, 1 cycle is about 200 feet of cable, and
since handshaking involves multi-cycle delays between sensing "data rdy"
and sampling data lines, any reflections would be fully damped out.
Ok. That explains the lack of termination.
Fan-out (signal loading) would depend on the components used for the
transmit and receive circuits, and cable impedance. I expect it was
designed to cope with something in the order of 20 workstations on the
network, by which time the performance of the network in times of heavy
load was unbearably slow (due to server performance, network throughput
and arbitration collisions).
For a file server, I would expect peaky loads when a class was starting
or ending, or when a new application was needed by most participants,
but relatively low usage most of the time.
Driving long cables is best done with low-impedance drive circuits (to
deal with induced interference and cable capacitance). I chose to use
discrete transistor emitter followers for NadaNet, to allow up to 200
feet of shielded cable or up to 500 feet of twisted pair. I feel a
lot better about exposing 2N4401's to the outside world than the output
pins of even a buffer IC. ;-)
-michael
NadaNet file server for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."