Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!bloom-beacon!apple!desnoyer
From: desnoyer@Apple.COM (Peter Desnoyers)
Newsgroups: comp.protocols.appletalk
Subject: Re: does Mac barge into flashtalk?
Keywords: flashtalk
Message-ID: <26459@apple.Apple.COM>
Date: 27 Feb 89 18:36:10 GMT
References: <20838@agate.BERKELEY.EDU> <325@taniwha.UUCP>
Distribution: usa
Organization: Apple Computer Inc, Cupertino, CA
Lines: 45

In article <325@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:
>In article <20838@agate.BERKELEY.EDU> jim@insect.berkeley.edu () writes:
>>     "The major reason Appletalk is slow is that the Zilog serial
>>     chip can be overwhelmed by clock pulses that arrive at rates
>>     faster than 230.8 kbps.  
>>
>What it really means is that the clock recovery ciruitry on the SCC
>(phase locked loop) doesn't work at much over 230k .... I think that
>both FlashTalk and DaynaTalk are both just external faster PLLs and clocks
>(probably 2 chips and a crystal) plus extra software.
>
>One thing you should be aware of if you are going to run a net a 3 times
>the speed is that collision detection (esp of the type mentioned above)
>is only going to work on a net with a MAXIMUM size that is 1/3 that
>of the maximum size of a 230k net. 

Slight correction. The maximum delay on a LocalTalk network (300m, v
(est.) = 0.5) is about 2 microseconds. LocalTalk does not do hardware
collision detection, but instead uses a CSMA reservation system -
sending out a lapRTS and waiting 200uS for a lapCTS. The 200uS swamps
any possible cable delays. However, the efficiency is lowered because
beta (frame size / slot time) is decreased.

If you are interested in the performance of CSMA buses, read on...


For vanilla LocalTalk, beta = 106. The reservation cycle works as
unslotted Aloha, with an efficiency of 1/2e or 18.4%. For every
successful reservation (2e cycles, or 5.4*200uS or 1.1mS) you can send
a frame of 609.5 bytes + inter-dialogue gap or 21.2mS + 0.4mS. Thus
raw efficiency (for max size packets) is 21.2/(21.2+0.4+1.1) = 93.4%.
Actual throughput is lowered by LAP overhead (1.6%) and DDP overhead
(2.3%). 

If you speed it up 3 times, you get the same reservation period -
1.1mS - and a maximum frame size of 7.1mS, for an efficiency of
7.1/(1.1+7.1+0.4) = 82.6%. So you actually speed up by 2.7, instead of
3.  Still looks like a win to me. 

This analysis assumes worst-case load and best-case frame length
(maximum length frames). If you are not sending maximum-length frames
you are probably interested in delay, rather than throughput, anyway.
This analysis also ignores any non-theoretical, real-world issues. (:-)

				Peter Desnoyers