Conference 7.286::fddi

612.0. "Help for an oem" by WELLIN::MCCALLUM () Wed Jun 17 1992 11:59

Can anyone comment on this note from one of our oems who is using our kit
in a development environment.

Thanks,

Dave McCallum.


From:	VBORMC::"[email protected]" "stelios pavlides" 17-JUN-1992 15:51:33.06
To:	wellin::mccallum
CC:	
Subj:	Concentrator FDDI/SMT compliance

Hi Dave

As you may know from our discussions, we use your concentrator to
facilitate development of a FDDI card for our own workstations. Our card
has been tested at AMD's ANTC in Sunnyvale. We also have in house a CMT/RMT
test suite, which is a subset of ANTC's test suite and runs on AMD's
FASTcard.

We have tried the test suite against your concentrator (DAS one-to-one
testing, no equipment attached to the M ports) and it has thrown up a
number of problems. When in Sunnyvale last March a DECconcentrator was
present and was used during inter-operability tests. We assumed that it had
passed the standard ANTC tests.

Would you please comment on our findings?

Regards
Stelios

-- 
Stelios Pavlides			Phone  :  +44 442 230000 ext 3468
Crosfield Electronics Ltd		Fax    :  +44 442 232301
Hemel Hempstead, Herts. HP2 7RH, UK	E-mail :  [email protected]
-----------------------------------------------------------------------------


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: by vbormc.vbo.dec.com; id AA28739; Wed, 17 Jun 92 16:46:59 +0200
% Received: by enet-gw.pa.dec.com; id AA14628; Wed, 17 Jun 92 07:50:07 -0700
% Received: from bnr.co.uk by eurogate.bnr.co.uk with SMTP (PP)           id <[email protected]>; Wed, 17 Jun 1992 15:49:56 +0100
% Received: from hedera.bnr.co.uk by innergate.bnr.co.uk with SMTP (PP)           id <[email protected]>; Wed, 17 Jun 1992 15:49:41 +0100
% Received: from maple.bnr.co.uk by hedera.bnr.co.uk with Internal SMTP (PP)           id <[email protected]>;          Wed, 17 Jun 1992 15:47:47 +0100
% Received: from server2 on maple.bnr.co.uk over UUCP id AA28095;          Wed, 17 Jun 92 15:46:45 +0100
% Received: from suns4.cel.uucp by server2.cel.uucp; Wed, 17 Jun 92 15:39:07 BST
% From: stelios pavlides <[email protected]>
% Message-Id: <[email protected]>
% Subject: Concentrator FDDI/SMT compliance
% To: wellin::mccallum
% Date: Wed, 17 Jun 92 15:39:04 BST
% X-Mailer: ELM [version 2.2 PL13]

How on earth is one supposed to respond to a message that says, in effect:

	"there is a problem"

??

(Actually, I remember a famous SPR and response years ago; the SPR said:
"there's a bug in the XYZ compiler" and the answer was "there is a fix
for the compiler".)

	paul

    
    More detail on the problems ancountered.
    
    What is our views on the ANTC tests ???
    
    
> Can you detail some of the problems you found with your tests please.

OK, here we go:-

The concentrator's A and B ports are connected to two AMD FASTcard 1s
installed in a PC and comprising a DAS station. The concentrator's M ports
are unused. ANTC PCM/RMT test suite V3.00 or V3.02 is run on the PC.

Trace initialization or propagation tests pass. After the test has
completed the concentrator crashes, self tests and recovers. Is this an
enthusiastic implementation of the path test function?

The ANTC test suite may proceed to other tests. If the concentrator is
still self testing these fail.

The trace react test always fails.

Regards
Stelios

-- 
Stelios Pavlides			Phone  :  +44 442 230000 ext 3468
Crosfield Electronics Ltd		Fax    :  +44 442 232301
Hemel Hempstead, Herts. HP2 7RH, UK	E-mail :  [email protected]
-----------------------------------------------------------------------------

1. Yes, restart and full selftest is a perfectly valid implementation of
   "path test" and is the one we use.  It's incorrect to characterize
   that as a "crash".  It is an INTENTIONAL reinitialization.

2. If the ANTC tests continue after the trace test and fail because the
   concentrator hasn't finished restarting yet, that's a bug in the ANTC
   test procedures.  Any expectation that the path test takes a particular
   small amount of time is wrong; the standard sets no requirements, nor
   should it (makes no difference for interoperability).

3. Please explain what you mean by "the trace react test always fails".

	paul