In the case of Pactor-2 and Pactor-3, the developers knew they were
running on dedicated processors with complete control over scheduling,
so there was no reason to reduce performance by unnecessarily extending
turnaround time or pipelining control messages (which extends recovery
when an error occurs). If you're in the business of selling standalone
TNCs, as these developers are, then you exploit every strength afforded
by this approach. The last thing you'd do is design a protocol that
could be implemented without your hardware!
IBM Bisync? I know it all too well. The first commercial product I
designed was a hardware interface for this protocol. Dating myself, it
was implemented with TTL MSI -- before the availability of large scale
integration or customizable logic.
73,
Dave, AA6YQ
--- In digitalradio@yahoogroups.com, "jhaynesatalumni" <[EMAIL PROTECTED]>
wrote:
>
> I'm willing to believe that the timing tolerances in -tor modes
> are so tight that ordinary PC operating systems cannot cope with
> them the way a dedicated processor can. What I don't understand
> is why the tolerances need to be so tight. The transmitter sends
> a packet and then listens for an ACK or NAK. Why can't it wait
> arbitrarily long?
>
> There are protocols for wire transmission e.g. IBMs Bi-Sync
> which worked in the days of modems that could only transmit in
> one direction at a time. These used old slow computers to
> run the protocol.
>
Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org
Other areas of interest:
The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion)
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
