cornish (04/29/83)
We have had a Codata 3300 in house for evaluation for the last 1 1/2 weeks,
with 750 Kb ram, 30 Mb disk.
In terms of cpu speed (Zilog benchmarks), it was found to be comparable to
a Vax 11/750. In terms of disk throughput, it is approximately 1/3 the speed.
Several problems identified were:
1) Codata's uucp (as delivered by Unisoft) will not talk to Berkeley uucp.
Apparently the problem is a non-portable checksum evaluation.
Codata is supposed to be fixing the problem in 2-6 months. Until then,
their machines will only talk to each other.
2) Porting V7 uucp to the Codata allows the two machines to handshake,
but file transfers fail, because raw mode does not disable xon/xoff.
Apparently the problem is in the intelligent serial i/o card, and is
supposed to be corrected in 3-4 weeks by substitution of a new card.
3) A source license for the Codata is $10,000, if you already have a Unix
source license. In our case, this would boost the system price from
$18,000 Canadian to $30,000 Canadian.
For the record, the Codata timings were:
Elapsed User System
disk_test: 1:13.0 0.4 15.6
piper: 0:11.0 0.0 4.4
proc_call: 0:44.0 43.6 0.1
sieve: 0:08.0 7.4 0.1
systemcall: 0:05.0 0.1 3.4guy (04/30/83)
1) Codata's uucp (as delivered by Unisoft) will not talk to
Berkeley uucp. Apparently the problem is a non-portable
checksum evaluation. Codata is supposed to be fixing the
problem in 2-6 months. Until then, their machines will only
talk to each other.
A non-portable checksum evaluation? Well, somebody screwed up; we have
gotten VAXes running 4.1BSD's "UNIX 2.0" UUCP, Zilog's running V7 UUCP, CCI
Power 5's running V7 UUCP, Plexuses running V7 UUCP, ONYXes running ONIX
V7 UUCP, ONYXes running IS/1 V7 UUCP, ONYXes running AT&T 3.0 UUCP, etc.,
etc. to talk to various of each other. What's so hard that Unisoft V7(?)
UUCP can't talk to Berkeley UUCP (and, quite possibly, any other UUCP)?
The nice thing about UUCP is that it IS a nice portable way to wire two
UNIX machines together. A UUCP which can't do that loses much of its
reason for existence, given all the problems that UUCP has.
2) Porting V7 uucp to the Codata allows the two machines to
handshake, but file transfers fail, because raw mode does
not disable xon/xoff. Apparently the problem is in the
intelligent serial i/o card, and is supposed to be corrected
in 3-4 weeks by substitution of a new card.
Well, according to my V7 manual, TTY(4):
Certain ASCII control characters have special meaning.
These characters are not passed to a reading program
*except in raw mode where they lose their special character*
("italics" mine)...see below.
...DC3 (Control-S) delays all printing...
It seems, then, that the Codata is not running a V7-compatible UNIX.
(If, by some chance, it's USG (System III) compatible, the equivalent of
RAW mode is achieved by turning off several options, *including* XON/XOFF).
If the serial I/O card is bypassing the driver's handling of XON/XOFF,
I suspect the adjective "unintelligent" applies better. Most operating
systems (including V7 and post-V7 UNIXes) support two kinds of "raw" mode;
a "very raw" mode, with an 8-bit data path and NO special characters, to
be used for transmitting binary data, and a "sort of raw" mode, with a 7-bit
data path, parity checking, and a lot of the same input/output special
processing as in "cooked" mode, to be used for things like screen editors.
In short, there's a reason why the UNIX tty drivers do what they do with
RAW and CBREAK mode; why did the designer of the I/O board screw this up?
Was the I/O board originally designed for another operating system (which
decided not to support a real 8-bit data path), or did the guy just not
know anything about UNIX or real-world tty drivers?
Some of this sounds like people stressing creativity at the expense of
compatibility. This is a bit of a flame, but I've been burned by this
sort of crap more times than I'd like to remember. I hope Codata (and
Unisoft?) cleans up its act; both those failings are inexcusable.
Guy Harris
RLG Corporation
{seismo,mcnc,we13,brl-bmd}!rlgvax!guyshannon (05/02/83)
There IS a non-portability in the uucp checksum routine, I reported
it (and the fix) in net.bugs.uucp right after the Unicom conference.
The problem is related to casts. It's possible to build compilers
for all the machines Guy Harris listed that would do the cast the
same way as the VAX and the PDP-11, it's also possible to do it
differently and still be C. All the 68000 pcc-based compilers I've
seen do this one particular thing differently than the VAX pcc.
Also, I believe UniSoft fixed their uucp many months ago, Codata
probably doesn't have the fix yet.
As for the "intelligent" I/O board that won't let ^S through, if it's
the board I think it is, the word that comes to mind is "terminally
braindamaged".
Bill Shannon
Sun Microsystems Inc.
{decvax,decwrl,ucbarpa}!sun!shannon