🚀 go-pugleaf

Keith and Clive,

  I have spent some time studying the Econet code and what it does is this.

  When StartTransmit is called the data from registers is checked and copied
to an RMA block.  Included in this block are the delay time (as passed in),
the "start time" (initialised with the current time) and "finish time"
(initialised with the current time plus ten seconds).  The status is set to
TxReady.  This block is then stored as a part of a list

  Every centi-second the Econet code scans the list looking for TxCBs that
are TxReady and have a start time <= the current time, when such a TxCB is
found a pointer to it is passed to a standard routine for "starting" a
transmission this routine first tries to get "line access" i.e. it sees if
another station is transmitting.  If there is access to the line the scout
packet is sent.  If the scout packet fails (NotListening) then the count
value is decremented, if it becomes <= zero then the Not Listening status is
recorded on the TxCB and that is that.  If the count value has not yet
reached zero then the delay time is added to the start time to make the new
start time and ten seconds is added to that new start time to make the new
finish time, and the status is set to TxReady.  If there was no line access
then the status is set to TxReady and none of the times or the count value
are changed, however the current time is compared to the finish time and if
the finish time is <= to the current time the TxCB is marked LineJammed and
that is that.

  The PRM tries to explain this on pages 1339, 1340 and elaborates on page
1362.

  There isn't a queue as such there is a list (ordered by initial creation
time) and this list contains all active transmissions i.e. from
StartTransmit to AbandonTransmit.  The processing of the list is as
described above.

  As to the choice of count and delay times, this is a matter for the
programmer to decide.  The product of the count and delay values will give
the approximate time before a 'terminal' status like NotListening or
NetError will be returned (the exact time is (Count-1)*Delay).  It is usual
to set this to be between ten and forty seconds depending on the behaviour
of the receiving machine.  The actual delay value gives control over the
granularity of noticing the state of the receiving station.  For example if
the count and delay are set to 2001 and 1 and the receiving station is not
ready then the NotListening status will occur after 20 seconds, this would
be that same as the other extreme values 2 and 2000.  However in the former
case within a centi-second of the receiving machine opening an RxCB the
transmitter will succede, the latter case it will only 'notice' at the
expiration of the 20 seconds.  There is a drawback to always using a delay
of one centi-second and that is other processes and other machines will find
the world very hostile and difficult to use.  Most Acorn protocols use a 10
centi-second delay value.  This gives a nice balance to responsiveness and
fairness without overloading the network or the machine.  Note that if your
receiver is known to have particular characteristics e.g. a server which
always takes five seconds to process a request before accepting the next one
then turning up the delay to, say, 100 centi-seconds would be the right
thing to do.

  Hope that makes things a little clearer.

  Bruce.

Any views expressed are my own and are not necessarily those     _--_|\ 
of Acorn. Any factual information is given in good faith and    /      \
neither I, nor Acorn can accept liability for loss or damage    \_.--._/
resulting from its use.                                               v