*start*
00874 00024 US 
Date: 23 Nov. 1981 9:18 pm PST (Monday)
From: Stewart.PA
Subject: VTMU control protocol
To: Belleville, Lau, Olmstead
cc: VoiceProject^.pa

I had an idea a couple of weeks ago.  Wouldn't it be a reasonable idea to have
the voice unit put a deadline on some host response to, say, ring detect, in the
case that the control of the phone is by the host?  Thus if the host doesn't do
something by the third ring, the voice unit will reset itself and ring the local
station on the assumption that the host is dead.  People will boot out of the
phone-mate program on their 820's and then miss calls...  Presumeably a NOP
response would be OK, or somethign more complex if you want some assurance
that the host program isn't subtly sick.  This is close, in spirit, to a watchdog
timer, but only applied when needed.

	-Larry

PS  has this thing got a name?
*start*
02770 00024 US 
Date: 24 Nov. 1981 12:57 pm PST (Tuesday)
From: Stewart.PA
Subject: Microprocessors and El Segundo
To: Ornstein
cc: Stewart

1. How you like the following?  Seems fine
2. What have I forgotten or misrepresented?  I editted the assembler section
3. Who else should get it?  -- ABell, Pasco, Garner, Pier

*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

Subject: Microprocessors and El Segundo
To: TonyWest, McCreight, Thacker, Belleville, Petit, Wilhelm, Basket, Lau,
Taylor
cc: Ornstein, Stewart

Yesterday Larry and I spent the day in El Segundo talking to various people
about the Etherphone board and related matters. Here are some interesting things
that emerged.

1. They (Roy Quin) are designing (currently in debug) a board that connects
two RS232 lines to a 1.5 MB Ethernet - the information on the Ethernet is
encrypted. It uses an 8085, an SLC, a Zilog serial-line part and the AMD 8068
encryption chip. They've gone around some with AMD about the 8068, but their
strategy has been to try to meet the AMD specs, getting the specs relaxed where
a problem (rather than trying to understand what the specs mean). They hinted
that the Western Digital chip might have noise problems with its 'TTL
compatible' outputs.

2. Our Etherphone design looked reasonable to them - they had a couple of
helpful hints. They have no experience with DMA controllers and seem to talk
directly to all devices with whatever microprocessor they are using.     

3. There is an untried 8086 assembler written in Mesa. The assembler is table
driven and versions for the Intel 8051 and 8085 are expected.  We tried the
assembler briefly.  It seems to assemble, but the output file format is newly
invented and the linker is not finished.  There are a number of input syntax
differences from Intel standard.

4. They have put quite alot of work into a rather nice debugging setup for
multiple microprocessor systems (think Lotus). It includes high-speed in-circuit
emulation that lets you run all the target microprocessors together at full bore
with individual break points etc; if any machine hits a break point, all are
stopped and you can step from there. One trouble is that the system isn't
integrated with program production (compiler, assembler, loader, etc.) Ron Huff
explained it to us and said they are busy extending it to work with more
microprocessor types. Their primary customer is Rochester but they would love to
extend their base. In particuler they want to come up here and make a brief
presentation if enough folks are interested. I suspect that even if we don't want
to buy a system (inside cost $20K to $30K depending), it would be worthwhile
having them come by. If you would like to attend such a presentation, let me
know.

S.     

*start*
02618 00024 US 
Date: 24 Nov. 1981 2:33 pm PST (Tuesday)
From: Ornstein.PA
Subject: Microprocessors and El Segundo
To: TonyWest, McCreight, Thacker, Belleville, Petit, Wilhelm, Basket, Lau,
 Taylor, ABell, Pasco, Garner, Pier
cc: Ornstein, Stewart

Yesterday Larry and I spent the day in El Segundo talking to various people
about the Etherphone board and related matters. Here are some interesting things
that emerged.

1. They (Roy Quin) are designing (currently in debug) a board that connects
two RS232 lines to a 1.5 MB Ethernet - the information on the Ethernet is
encrypted. It uses an 8085, an SLC, a Zilog serial-line part and the AMD 8068
encryption chip. They've gone around some with AMD about the 8068, but their
strategy has been to try to meet the AMD specs, getting the specs relaxed where
a problem (rather than trying to understand what the specs mean). They hinted
that the Western Digital chip might have noise problems with its 'TTL
compatible' outputs.

2. Our Etherphone design looked reasonable to them - they had a couple of
helpful hints. They have no experience with DMA controllers and seem to talk
directly to all devices with whatever microprocessor they are using.     

3. There is an untried 8086 assembler written in Mesa. The assembler is table
driven and versions for the Intel 8051 and 8085 are expected.  We tried the
assembler briefly.  It seems to assemble, but the output file format is newly
invented and the linker is not finished.  There are a number of input syntax
differences from Intel standard.

4. They have put quite alot of work into a rather nice debugging setup for
multiple microprocessor systems (think Lotus). It includes high-speed in-circuit
emulation that lets you run all the target microprocessors together at full bore
with individual break points etc; if any machine hits a break point, all are
stopped and you can step from there. One trouble is that the system isn't
integrated with program production (compiler, assembler, loader, etc.) Ron Huff
explained it to us and said they are busy extending it to work with more
microprocessor types. Their primary customer is Rochester but they would love to
extend their base. In particuler they want to come up here and make a brief
presentation if enough folks are interested. I suspect that even if we don't want
to buy a system (inside cost $20K to $30K depending), it would be worthwhile
having them come by. If you would like to attend such a presentation, let me
know.

S.     

P.S. There was rumor of Intel doing some sort of interim 5 MB Ethernet chip.
Does anyone know anything about this?
*start*
00298 00024 US 
Date: 27 NOV 1981 1824-PST
From: STEWART.PA
Subject: Etherphone status
To:   VoiceProject^

Severo and I started bringing up the Etherphone prototype.  The 
SDK-86 monitor is working as of 6:20 pm Friday...  We have found
a few minor blunders but no show stoppers.
	-Larry 
*start*
00566 00024 US 
Date: 28 Nov. 1981 6:25 pm PST (Saturday)
From: Stewart.PA
Subject: Lark Progress
To: VoiceProject^.pa

Severo and I worked some more on Lark this afternoon.  The upside is that we
have successfully talked to the Timer chip and the Parallel port.  The downside
is that we discovered a blunder that effectively prevents us from testing the
DMA stuff (it keeps us from talking to the DMA chips at all).  We will continue
with the non-DMA checkout, but will start working on a change list for Rev-Ab
with everything we've found so far.
	-Larry

*start*
03944 00024 US 
Date: 2 Dec 1981 17:55 PST
From: TonyWest at PARC-MAXC
Subject: TRIPOS Software Distribution Tape
To: GC @ XNET
cc: TonyWest, Stewart

Please forward this message to:

Telex number 81240 CAMSPL G for:

To:	Dr. Martin Richards, Tel: 223-352435
	Computer Laboratory
	Cambridge University
	Corn Exchange Street
	Cambridge CB2 3QG
	England

From:	Anthony West
	Xerox Palo Alto Research Center
	3333 Coyote Hill Road
	Palo Alto
	California 94304
	USA

----------------------------------------

Dear Martin,

Based on out last telephone discussion, I have arranged for
an official Xerox Purchase Order to be sent to you, ordering
one "Tripos Distribution Tape".

The order assumes that the cost of the distribution tape (note,
this means the cost of preparing the tape etc.) is 350 pounds.
I stress that I am operating on the basis that the money is for
the tape and not for the software.  That way, both we and you
avoid the potential problems associated with the Computer 
Laboratory being cast in the role of "Software Vendor".

The normal practice is that, after receiving the order, you 
would send the tape and an invoice for this amount.

However, it is important for Xerox to be enabled to send you
the money before the end of December, since the expense
budget concerned lapses then.  Since we are all friends, I 
would like to ask you if we can cut corners in the following
way:

I hereby notify you that the Official Xerox Purchase Order
Number is M53980, I repeat M53980.  Please could you send off
to me an invoice which refers to "your order number M53980"
for the sum of 350 pounds, as if you were sending it with
the shipment of the tape.  When the invoice arrives, Xerox
can send you the cheque (in sterling) more-or-less immediately.

Since this is the urgent part, we have decoupled it from the
actual delivery of the tape, which may follow at your 
convenience.  As we discussed in our last telephone 
conversation, please could you include the following on the
tape:

* BCPL Compiler for 8086 and for 68000
* TRIPOS Kernel for 8086 and 68000
* Tripos Sources of both 8086 and 68000 implementations
* As much documentation as possible
* Assemblers for 8086 and 68000 (if you have them)
* Sources for the latest version of the filesystem
* Anything else you might think is useful, for
	example, the source code of the little object module
	linker program used to assemble separately compiled
	code modules together for the 68000, and the utility
	which converts them into Motorola S-records.

Please consider the above to be a wish-list, I would not
want you to send us anything which is not in the public
domain, or which you are not authorised to give to us.

I order to simplify the installation process, I have ordered
an 8086 Multibus configuration which is a true superset of
the system they have running at Rutherford.  I have been
talking to Graham Adams about the strategy we might employ
to get the system up and running.  I intend to ensure that,
as we did at IBM, we have a diskette system which is capable
of reading IBM format diskettes.  By this means, software
exchange in all directions (Rutherford, Cambridge and Xerox)
should be easier.

The understanding I have is that, unlike IBM, Xerox is not
particularly interested in maintaining any rights to the 
software developed here under TRIPOS.  Thus, in the (at the
moment, seemingly unlikely) eventuality that we generate
some code which might benefit either of you, there would be
no problem about sending it to you.

If you have a draft of your paper on the 68000 system, you 
might like to include it on the tape.

Tony

----------------------------------------


You may reply by TELEX to 22921 HQ RX in LONDON
and request that the message be forwarded to:

   TonyWest
   SAC: RD
   Xerox Palo Alto Research Center, USA

NB: Please do not put a space between Tony and West
or else the message will not be forwarded correctly to me.

*start*
04167 00024 US 
Date: 2 Dec. 1981 10:56 pm PST (Wednesday)
From: Stewart.PA
Subject: Notes on Voice unit Review
To: NDSmith, Belleville, Lau, Olmstead
cc: Gunning, VoiceProject^, Stewart

Some of these duplicate comments made at the meeting:

A European version would need an A-law codec in addition to European power. 
Eventually there will be tariffs for digital trunks and voice peripherals would
probably need to use the local interchange standard encoding (or provide
translation?)

Speakerphones are hard to get right.  The switching should be under control of
the local party only, not both parties, and the switching effect should be a gain
reduction of the speaker (~20 dB?) rather than outright cutoff.

How is a good computer answering machine going to be built without a second
tape deck?  Provision for aux in and out jacks and a contack closure would allow
use of an external tape deck for recording messages, while the more functional
internal deck was in use for playing the announcment.  An aux-in jack would
also allow (gasp) music on hold etc.  The aux in and out (I think) could be
paralleled with the existing tape in and out.

RS-232 should transmit 2 stop bits, but be prepared to receive only one.  This can
be done by a one-bit software delay before issuing each character if RS-232
hardware can't do it.

The Handset off-hook detector needs hardware debouncing, but should follow
pulse dialing.  (If the user needs pulse dialing outbound, then he probably has a
dial phone).

The use of an inversion of the 8243 chip select to enable the LS368 seems scary. 
Is there any possibility that both the 8031 and the 368 could be driving the lines
at the same time? (not counting control program errors)

I don't believe that Port 2 bits 0-3 can be used both as PROM address bits and as
IO lines.  Since they are not latched, they must be stable throughout memory
read cycles.  Since there is no other program memory, there is nowhere for the
program to stand while using the lines for IO.  (The code could live temporarily
in RAM or instructions could be duplicated at 16 locations...)

The 'typical' voice should nearly fill the input range of the codec, otherwise
dynamic range of the digital speech is reduced.  Probably somewhere in the telco
literature there is information on the correspondence between a standard signal
level and the u-law codes.  (How much "headroom" does the phone system
have?)  The DTMF transmit levels must be higher than the voice levels.  I have
connected DTMF generation through level restricting couplers and have had
trouble getting the tones detected by the CO.

The crosspoint switch should be used in a mixing mode so that any combination
of switches is legal.  Matching all the source impedances at 5K-10K should do it. 
If all the sources are ground-referenced, the capacitive coupling at the switch
may not be needed.

Make sure all analog nets have a ground reference through less than 500K or so
(no caps connected only to FETs).

Debouncing logic needed in all contact sensing applications.

Isolation is not needed in the handset interface.  (Wait!  The handset interface
CAN be plugged into the local loop, since the connectors are necessarily the
same!  RING...Bzzzap...smoke.)

If the control program is a big state-machine and is guaranteed to execute at least
once every millisecond or so, it seems that no interrupts may be needed.

The control protocol should meet some 'principles'.  It should be possible to
always parse the output.  It should be possible to use the voice box from a
machine with NO clock of its own (thus if the box must be poked every once in
a while, a reasonable time base should be available.)  It should be possible to
write a 'background' host program that need only respond to not-too-frequent
characters from the voice box.  [The two safety cases are instructive:  It seems to
me that keeping the local loop off hook should require occasional pokes from the
host.  It also seems to me that this is NOT true of keeping the loop relay
off-normal.  Only when ring-indicator shows up and the the host fails to
respond should the host be presumed dead.]   

Larry

*start*
02962 00024 US 
Date: 3 Dec. 1981 8:23 am PST (Thursday)
From: Swinehart.PA
Subject: More Notes on Voice unit Review
In-addition-to: Stewart's message of 2 Dec. 1981 10:56 pm PST (Wednesday)
To: NDSmith, Belleville, Lau, Olmstead
cc: Gunning, VoiceProject^
Reply-To: Swinehart

The only thing I'd add to Larry's comments involves the control protocol, and this is more by way of personal opinion than anything else.  I believe it would be preferable if the host machine could be given the impression that commands are accepted in full, then executed -- just as Mesa multi-byte instructions are fetched and decoded in full before being executed.  This applies primarily to the dialing and tape positioning commands, which accept parameters.   (I don't think that interpreting the appearance of a "naked digit" at the host/voice unit interface buys you nearly what it costs you -- there should be a command prefix.  The host program can readily insert this prefix if it's not part of the program's command language.)  Notice that the time-of-day command essentially works this way already.

A variable-length command should also have a predictable termination: its length should be determined by the "opcode", by a length parameter, or by an explicit terminator.  If there's room to do it this way (memory's cheap, buy more . . . sorry, I must have thought I was Butler for a moment), I believe things would work better if the entire number to be dialed were transmitted, checked for validity, and buffered before dialing.  Then the host will know what the problem is before arbitrary amounts of time-consuming and possibly costly telephone line activity has occurred.  Subsequently the only errors that can occur (since you're running open loop) will be power failure or something.  This simplifies the host communication program, which will be non-trivial to get right anyhow, and can result in much smoother dialing behavior.  Remember that the user will hear the tones going out.

I believe the state-machine program can be made reliable enough that it can implement the necessary watchdog timers -- the hardware/software MTB(catastrophic)F should be reducible to an acceptable value.  Other reviewers were, as you know, more cautious.

It will be important for you to get the feel for what FCC requirements really have to be met in a voice-only box; the data requirements are substantially more stringent because of the continuous high-level duty cycle of modulated data.  The FCC and the Bell system seem to be pretty hang-loose about interconnection issues these days, all things considered.  This is partly because Western Electric now has to register its equipment.  If a local consultant does not give us satisfactorily laissez-faire answers on some of the signal level and "cut-through" issues, we should pursue them directly with the FCC folks in Washington, who seem not to be quite as busy as one would expect.

Nice project.

Dan Swinehart

*start*
00395 00024 US 
Date: 4 Dec. 1981 9:39 am PST (Friday)
From: Stewart.PA
Subject: WATS areas
To: Stewart

Given an interstate inward WATS number (800-xxx-xxxx, where the
third 'x' is not a 2), is there a way I can determine its geographic
location?  I'm curious to know if there is a numbering plan for WATS
"exchange codes".

Phil

[Yes - call (800) xxx - 005y (y = any integer) -JSOL]

*start*
00591 00024 US 
Date:  4 DEC 1981 1116-PST
From: STEWART.PA
Subject: Disk drive, 26LS
To:   Belleville
cc:   TonyWest, Stewart

As I mentioned Wednesday, Tony West and I are building a Multibus
system.  We have ordered a winchester controller and plan to order
a Shugart 110x when available.  In the meantime, we'd like to borrow
a 100x drive (any size) for a few months.  You mentioned that there might
be a 1004 (?) 5 Mb drive lying around.  Who should I talk to about that?

Also, have you guys got any 26LS31s and 32s?  I could use a couple of each
for the Etherphone...
	-Larry
*start*
01237 00024 US 
Date: 8 Dec. 1981 6:05 pm PST (Tuesday)
From: Curry.PA
Subject: Multibus board
To: Ornstein, LStewart

[IVY]<Curry>RouteMultibus.br is the Route Multibus board specification routine.

There are 5 connectors on the board.
  Two E connectors (Edge connectors = P in sil font 3)
	J1 has 86 pins labeled from 101 thru 186 (only 66 locations have pins)
	J2 has 60 pins labeled from 201 thru 260
  Three C connectors (Cable connectors = p in sil font 3)
	J3 has 50 pins labeled from 301 thru 350
	J4 has 50 pins labeled from 401 thru 450
	J5 has 26 pins labeled from 501 thru 526

Reserved Names:
    Tracewired voltage busses:
	VCC GND
    Uncommitted voltage busses:
	VEE (=VB renamed)
	VD VF VH VK VM VP VR
	VTA VTB	VVA VVB	V2 V3

This version of the routine uses the VB bus (cable edge uncommitted bus) as the
VEE bus (-5 for some ECL).  If you actually use this voltage it must be
connected by hand to the appropiate connector pin (E109 via the V2 bus
possibly).  If for some reason you need another uncommitted bus to be VEE it
could be done fairly easily although it would be nice to have only one version
of the board routine floating around.

Don

------------------------------------------------------------

*start*
00291 00024 US 
Date: 9 Dec. 1981 6:29 pm PST (Wednesday)
From: Stewart.PA
Subject: SLC working
To: VoiceProject^.pa
cc: Boggs
Reply-To: Stewart

Was able to send packets with the SLC at around 5:30 pm today.  Via the hewx
debugger of course.  Maybe tomorrow a program. (!)  -Larry

*start*
00196 00024 US 
Date: 10 Dec. 1981 10:45 am PST (Thursday)
From: Curry.PA
Subject: Multibus drawings
To: Ornstein, LStewart

[IVY]<Curry>Multibus01.sil is the sil drawing I gave you.
Don

*start*
03007 00024 US 
Mail-from: Arpanet host SU-SCORE rcvd at 10-DEC-81 1514-PST
Date: 10 Dec 1981 1511-PST
From: Bill Nowicki <CSD.NOWICKI at SU-SCORE>
Subject: [Richard Furuta <FURUTA at WASHINGTON>: Update to request for references on non-textual editing]
To: VoiceProject^.PA at PARC-MAXC, Boggs.PA at PARC-MAXC

Warning that I turn into a pumpkin December 31.  If I can ever be of
help for anything, mail to "Nowicki@Score" should get to me.  I
am assuming my Xerox accounts will go away soon.  This should allow
me to spend some more time on my thesis, I guess, which needs it.
I will be in Milwaukee December 18 to January 6, so I might have
to do final cleaning up after that.
	Thanks again, Bill.

P.S. You probably have seen these already, but...
                ---------------

Mail-From: ADMIN.JQJ created at 10-Dec-81 10:59:06
Mail-from: ARPANET site WASHINGTON rcvd at 8-Dec-81 1110-PST
Date:  8 Dec 1981 1109-PST
From: Richard Furuta <FURUTA at WASHINGTON>
Subject: Update to request for references on non-textual editing
To: editor-people at SU-SCORE
			 *******************
I received a number of messages describing Bell Labs' speech editing
system.  In essence, this system seems to automate the manual steps
normally taken in editing tape recordings.  Speech is stored on a
disk.  A terminal with added function keys is used to specify
operations like: "Mark a segment of text", "Delete the segment",
"Insert text", etc.  Various speech compression techniques are
available for use in quickly scanning already recorded text.   This
system is described by N. F. Maxemchuk in Bell Sys. Tech. J., vol. 59,
#8, pp. 353-355.  Bob Allen of Bell Labs adds:
--------------
|Within a few days I should have a publicly available report on the
|human factors of this system and a discussion of user-interface issues
|in speech editors generally.  I will be happy to send out copies of
|this report.
|			Bob Allen (allegra!rba)
|			7A-221
|			Bell Labs
|			Murray Hill, NJ 07974
--------------
Thanks also to Jim Hook (Jgh.Cornell@UDel) and Hilary Wilder
(allegra!haw) for information on this system.
			 *******************
I also heard of a similar system, produced by IBM:
--------------
|Date: 12 Nov 1981 0917-PST
|From: Frank da Cruz <G.DACRUZ at SU-SCORE>
|To: Furuta at WASHINGTON
|
|IBM has an editor for recorded messages; they've just announced it as
|a product -- it's in all the trade publications.  I saw it a few years ago
|in Yorktown Heights when they were working on it.  Basically, you speak into
|a touch-tone phone, mark things (like sentences, paragraphs) by pushing
|buttons on the phone, and when you've finished, you can review and "edit"
|your message (by pushing buttons that refer to marked things) before
|sending it off.  At the time, I believe they also had some way of looking
|at the messages from their computer terminals; certainly not the contents,
|but maybe at the to, from, and cc lists, length, status, etc.
--------------
			 *******************
-------
*start*
00668 00024 US 
Date: 10 Dec. 1981 3:34 pm PST (Thursday)
From: Ornstein.PA
Subject: Butler's response
To: Stewart


Date: 10 Dec. 1981 4:06 pm EST (Thursday)
From: Lampson.PA
Subject: Re: The etherphone. . .
In-reply-to: Your message of 10 Dec. 1981 12:47 pm PST (Thursday)
To: Ornstein

I consider WD to be a mildly flaky supplier, but if their chip is better it should
be perfectly OK for this application.

Converting to Multibus sounds like a fine idea.  How do we wire them? When
can I talk on it?

Hope your trip East was agreeable. I am glad to take the couch.  See you
Wednesday.

Butler

------------------------------------------------------------

*start*
00399 00024 US 
Date: 11 Dec. 1981 3:03 pm PST (Friday)
From: Ornstein.PA
Subject: 3 MB SLC
To: Stewart
cc: VoiceProject^, Boggs, Rider.ES
Reply-To: Ornstein

Just spoke with Bob Markle. They've just recently gotten back the first of the
new SLC's (with the design bug fixed). Haven't yet tried to push the frequency
up but he promises to do so and call me back next week with results.

S.

*start*
01384 00024 US 
Date: 12 DEC 1981 2009-PST
From: GONSALVES.PA
Subject: Partial report on Ethernet performance measurements
To:   boggs, dalal, nowicki, stewart, taft
cc:   gonsalves



The file [ivy]<gonsalves>etherPEpaper.press contains an incomplete 16-page draft of a report on my measurement activities on a 3 Mbps Ethernet.  The abstract follows :

 "This paper presents measured performance characteristics of an Ethernet local network.  Shoch & Hupp [1980] measured the throughput of the network under artificially generated high loads.  We extend these measurements to include packet delays.  Next, we compare the performance of the implemented backoff algorithm with one which more closely approximates the binary exponential algorithm.  The latter is found to have marginally improved mean throughput and delay characteristics.  However, the variances are larger and fairness is poorer.  Finally, we study the effectiveness of the Ethernet network for real-time applications such as voice telephony.  Depending on various parameters, the network is capable of handling real-time traffic satisfactorily upto throughputs of 95% of capacity." 

  This draft contains the sections on real-time traffic.  I would appreciate hearing any comments and suggestions which you have.  The sections on data traffic will be included in the not too distant future.

Tim Gonsalves.
*start*
00495 00024 US 
Date: 14 Dec. 1981 12:13 pm PST (Monday)
From: Pasco.PA
Subject: Electronics mag. on Ethernet Voice
To: VoiceInterest^.pa

William Krause, president of 3Com Corp, is quoted by Martin Marshall in
Electronics mag. of 11/30/81, as saying that a 10-MBit Ethernet could carry
150 real-time 64 kBit voice conversations.  The item goes on to quote Don
Massaro as promising a telephone-Ethernet gateway by 1983, and to mention
research at Bell Labs in Ethernet-based telephony.

*start*
00281 00024 US 
Date: 14 Dec. 1981 12:57 pm PST (Monday)
From: Stewart.PA
Subject: Electronics mag. on Ethernet Voice, more
To: VoiceInterest^.pa

A more interesting note is on page 44 of the December 15, 1981 Electronics.  
Intel is working on Ethernet Voice...

	-Larry

*start*
00779 00024 US 
Date: 14 Dec. 1981 4:14 pm PST (Monday)
From: Dalal.PA
Subject: Re: Electronics mag. on Ethernet Voice, more
In-reply-to: Stewart's message of 14 Dec. 1981 12:57 pm PST (Monday)
To: Stewart
cc: VoiceInterest^
Reply-To: Dalal

We aren't the only ones persuing voice on the Ethernet, you know!

A couple of months ago I talked briefly with Twyver at BNR who said they
have a couple of Ethernet-like networks on which they are experimenting with
voice.  He said he couldn't tell me much more.

Ollivetti is rumored to be working on this too, as is GTE Telenet.

Intel's entry into Ethervoice is triggered by their interest to build chips for voice
applications--compression, synthesis, telephony; not to mention their desire to
sell Ethernet chips.

/Yogen

*start*
00575 00024 US 
Date: 14 DEC 1981 1840-PST
From: GONSALVES.PA
Subject: Re: Partial report on Ethernet performance measurements
To:   Dalal
cc:   boggs, nowicki, stewart, taft, GONSALVES, baskett, shoch

In response to your message sent  14 Dec. 1981 10:07 am PST (Monday)


I don't really have a good reply to that.  My guess is that the curves for
a 10 Mbps net and some P would look like the curves for a 3 Mbps net and 
P * 3 / 10.  This would imply that a 10-Mbps net could support about 100+
simultaneous conversations. (Assuming 64 Kbps per conversation).

Tim
*start*
00650 00024 US 
Date: 14 DEC 1981 2100-PST
From: STEWART.PA
Subject: Re: Partial report on Ethernet performance measurements
To:   GONSALVES, Dalal
cc:   boggs, nowicki, taft, baskett, shoch, STEWART, |h

In response to the message sent  14 DEC 1981 1840-PST from GONSALVES.PA

Remember that we have been using 160 voice bytes per packet plus 30
overhead bytes.  At 50 packets per second, this is 76 kilobits
per conversation.

I believe| that| the 10 Mbit network does  not scale linearly
(10/3) the 3 Mbit system.  The network is larger in bandwidth-length
product so small packets like voice fare relatively worse than at
3 Mbit.

	-Larry
*start*
03672 00024 US 
Mail-from: Arpanet host SU-SCORE rcvd at 15-DEC-81 1119-PST
Date: 15 Dec 1981 1109-PST
From: Bill Nowicki <CSD.NOWICKI at SU-SCORE>
Subject: Re: Partial report on Ethernet performance measurements
To: Gonsalves.PA at PARC-MAXC
cc: Stewart.PA at PARC-MAXC
In-Reply-To: Your message of 14-Dec-81 1840-PST

A few quick comments on the performance paper:
First, I'm glad to see this writing; a real empricial study.
As was pointed out, however, 10Mbit data would be nice, and
the scaling may not be direct.  Remember the addresses, CRC,
and preamble are all longer for 10Mbit. On this same note,
you tested Pmins of 64, 128, and 512.  256 would be closer
to a real telephone value, or actually about 200.

In the abstract and conclustion you use the word "upto"
which should be two words.

On page 2 you say that "the channel is about 550 metres".
Is this the actual length of network 3 (the one you measured)?
We have one at Stanford that is about 2000 metres (which
explains why it doesn't work very often).

In your discussion of the backoff algorithm (which you sometimes 
call "back-off" instead) it might be interesting to note what the
total delay is after 16 retransmission attempts, when the 
controller finally gives up.  This is interesting because
real-time voice data is useless if it is delayed more than one
packetization interval, or about 10-20 ms.

Your claim of "Error rates due to causes other
than collisions are on the order of 1 packet in 2,000,000"
might be a little optimistic.  This might be true for a
perfectly working Ethernet interface, the fact that should
be mentioned is that since higher level protocols are so
forgiving, interfaces with error rates up to, say 10% are
in common use.

On page 4 you say loss rates of up to 1% are considered acceptable.
However, when I tried my Etherphone program over the summer,
I discovered that any lost packet gave a "click" or "pop".
A rate of 0.1% would mean one pop every 20 seconds, and 1%
would be one a second, very anoying.  If you miss a sample
or two now and then, its not quite so bad.

Along the same lines, your modification of the data link
level protocol (keep growing packet until you get the wire)
is interesting, but it would also be interesting to see how
the standard link layer works (packet size fixed once 
it is passed to link level).  This is important because
VLSI chips such as the SLC and Intel's have the link level
hardwired in silicon (I think?).

On page 7 you say Ethernet has no priorities, but on page 8
you propose a scheme in which phone conversations are
interrupted for data traffic, which seems like priorities
in the wrong direction.  A better idea, I would think,
would be to DELAY data traffic.  I would rather have my
Dorado CopyDisk delayed by a second than interrupt
a call to the Vice President.

The bottom ledgends of the diagrams are labeled
"Throughput", "Offered Load", and "Generated Load".
Are these the same or might "Offered Load" be a better
name for them all?

5.2 and 5.5 are a little confusing with two things on
each graph.  There's one BIG question on the %loss
figures.  Is that TOTAL loss for all the hosts added up,
or AVERAGE loss of each conversation?  This is the
real order-of-magnetude question. 10% loss spread
over 30 hosts is great, 10% for one host would make
speech unacceptable. Note, however, that hopefully
such high loads are just transient.

So finally, there is one graph I really want to see.
Use the standard link level, 200 byte packets, 50 
per second, graph the percentage of packets delayed
more than 20ms vs. the offered load.
THAT really determines go/nogo with EtherPhone.

	-- Bill
-------
*start*
02048 00024 US 
Date: 15 DEC 1981 1232-PST
From: GONSALVES
Subject: Re: Partial report on Ethernet performance measurements
To:   CSD.NOWICKI at SU-SCORE, Gonsalves
cc:   Stewart

 In response to the message sent 15 DEC 1981 1119-PST by Bill


Bill,

Thanks for yuour comments.  Here are some answers to the points you raised.

1.  The Ethernet on the second floor of Building 35 at PARC is indeed about
550 metres long according to David Boggs.

2.  In my model of real-time traffic, the maximum delay is imposed by the
maximum packet length choosen.  These values are shown in Table 5.2 - oops,
there is an error there.  The heading of column 2 should be Dmax, not Dmin!

3.  I got the 1% acceptable loss level from the paper by Johnson & O'Leary.
The % losses in my graphs refer to the loss per host (or connection).

4.  The priorities I propose are higher level priorities built into the
Voice Protocol.  I agree that it would be preferable to delay the data
traffic rather than the voice traffic.  If one were designing a system
from scratch this would be the obvious choice.  However, if one wants to
add voice to an Ethernet in which the data protocols are more or less frozen
then this seems a reasonable suggestion.  In practice, one would hope that
high data loads would occur very infrequently.

5.  "Throughput" is the utilization of the available channel bandwidth i.e.
the number of bits which were successfully transmitted as  a
percentage of channel bandwidth.  "Offered load" and "Generated Load"
are the same and refer to the number of bits which the hosts actually try to
transmit.  Thus, Generated Load = Throughput + lost bits.  Note, that I
have defined throughput and generated loads as percentages of channel capacity
while loss is expressed as a percentage of generated load.

6.  I think that the EtherPhone performance could be improved by some filtering,
either hardware or software (eg. repeat the previous sample until the next
packet comes along) to reduce the  posps and
clicks caused by lost packets.

Tim
*start*
00724 00024 US 
Date: 15 DEC 1981 1406-PST
From: ORNSTEIN.PA
Subject: WireList
To:   Stewart
cc:   Ornstein

I know you're gonna love this. I tried to do the merge and it was going along fine doing the deletes until I came to the first GND path - I think it is GND-18 in the .ad file. Regret to inform you that the pins constituting GND-18 in the wirelist are not the pins called out for deletion on the .ad file. Something is wrong somewhere. We really have to straighten this out somehow and be sure that we have a proper backup command. I have not saved etp* for the current rev  Ab since we don't have a correct wire list at the moment and that is one of the most important items needing saving.

More anon.

S.
*start*
00247 00024 US 
Date: 17 DEC 1981 1344-PST
From: STEWART.PA
Subject: Loader bug?
To:   Duvall
cc:   Stewart

[Maxc]<Stewart>Test4.dm contains all the pieces for a program that
won't load.  LOC gives "Segment not found: <garbage>."
	-Larry
*start*
00410 00024 US 
Date: 17 DEC 1981 1612-PST
From: STEWART.PA
Subject: Loader Bug info
To:   Duvall
cc:   Stewart

It has something to do with the GROUP directive.  It seems to become
upset if more than one input REL file has one.  I editted out the
GROUP directive in all but one .asm file and now my program
loads.  Editting the compiler output, is, of course, not a good
long term solution...  -Larry
*start*
01056 00024 USm
Date: 18-Dec-81 16:17:47 PST (Friday)
From: Gobbel.PA
Subject: ChatTool
To: Stewart.PA
cc: Gobbel

Unfortunately, it doesn't look like there are any surviving copies of the latest Rubicon ChatTool sources - all of my sources are for the 8.0c world. If you don't mind unconverting some parts of the program (mainly user.cm processing), I'd recommend that you grab the source from [Idun]<Gobbel>Hacks>, otherwise [Igor]<PreCascade>Utilities>ChatImpl.mesa should at least work, though I'm not sure how much stuff is missing from that version (relative to the latest).  If you want to use the latest, the files are: ChatTool.config, ChatOps.mesa, ChatGlobal.mesa, ChatInstance.mesa.  As well as I can remember, the changes from Rubicon are:
	- Rubicon user.cm processing is much simpler
	- (Almost) all strings in 8.0c are LONG
	- UserInput.userAbort => variousInterfaces.UserAbort[window]

The ChatTool also uses one operation that's only implemented by Pilot- UserTerminal.Beep.  Just take it out and everything should work.

	-Randy
*start*
00222 00024 US 
Date: 21 Dec. 1981 7:14 am PST (Monday)
From: Stewart.PA
Subject: Disk drive
To: Belleville
cc: TonyWest, Stewart

Who is it that I should talk to regarding borrowing that 5 Mb disk drive?
	-Larry

*start*
00321 00024 US 
Date: 21 Dec. 1981 5:19 pm PST (Monday)
From: Stewart.PA
Subject: Lark (Etherphone) working . . .
To: VoiceProject^.pa, CSL^.pa
Reply-To: VoiceProject^.pa

The Lark prototype can now send encrypted voice over the 1.5 Mb
Ethernet, bounce it off an echo server, and play it out again. (!)

	-Larry