🚀 go-pugleaf

In article <1263@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes:
>Thank you Sequent, for getting it together. Thanks in particular to Dean
>Phetteplace (hope spelling's correct) for starting the ball rolling with
>the followup phone call from Portland.

In light of our experiences with UK support, perhaps comp.sys.sequent is
the forum for raising problems?

I've not had the time or the energy to do something about the situation,
but the poor responsiveness of UK support is a major irritation.

Incidentally, when will Portland get a mailer that can cope with UK
addresses? It is particularly frustrating that we've never had ANY
response to the mailbugs we've sent. I've had to phone UK support to
get the pts reference numbers. [Yes, they didn't even phone me.]

		Jim

In article <1263@syma.sussex.ac.uk>, andy@syma.sussex.ac.uk (Andy Clews) writes:
> A couple of weeks ago I posted a slightly scathing, but good humoured,
> article about the problems being caused by our buggy X.25 daemon on our
> S81 [...]

> [...] within DAYS we had a new, bugfixed X.25 daemon, and I
> am pleased to report that, so far, it is performing beautifully, with no
> more zombie logins appearing. 

Martin Jones of Sequent Europe pointed out an inaccuracy in my posting,
and I am therefore pleased to set the record straight.  I quote from his
message (I asked his permission but haven't heard anything for a few
days, so I hope he doesn't mind being quoted):

"Thank you for posting your follow up article.  I would however like to point 
out one inaccuracy.

The zombie process problem was nothing to do with the X.25 daemon.
The problem was in the X.29 handler, which is partly on the controller board,
and partly in the kernel.  The fix was a new release of Sequent's X.25 driver
and a new front-end module for the controller board.  In fact you are still
running the exact same daemon as before.

The reason I'm pointing this out is not just to be pedantic, but that
the Coloured book X.25 daemon is supported by Lancaster University, and
they were concerned that the article you posted might lead people to
think that they were slow in fixing Coloured Book bugs.  In fact quite
the opposite is true." 
---- 

I hope this clears things up.  My apologies for any embarrassment caused
to Lancaster University.  And thanks again to all concerned for fixing
the bug. 



-- 
Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, ENGLAND
JANET: andy@syma.sussex.ac.uk   BITNET: andy%syma.sussex.ac.uk@uk.ac
Voice: +44 273 606755 ext.2129

Hi all,
	I am interested to know more about 386 based sequent boxes.

	1)	Do the sequent compilers produce truly parallel execution
		of a particular procedure. (Producing multi-threaded execution
		of loops etc.) or does the architecture simply allow multiple
		processes to run in parallel (A la NCR 850).

	2)	I believe they run under Dynix. Is this compatible with "real"
		(AT&T) unix. (5.3 / 5.4 etc)

	3)	Does the architecture "scale" correctly, ie does performance
		increase linearly with the number of processes added?

	4)	The machine that I have seen has 2 dual-processor 386 boards
		with each chip running at 16 MHz. Are there speed up (33MHz)
		options available? What about 486 boards?

	5)	What are your experiences with bug-fixes and customer-support?

	6)	Given a free choice, would you buy another one...

Thanks, treval

Trevor,

	Some of your questions require a bit of detail.  I'll make these
as short as possible.  We can follow-up if you like.

In article <218@runxtsa.runx.oz> treval@runx.oz (Trevor Luker) writes:

>	I am interested to know more about 386 based sequent boxes.
>
>	1)	Do the sequent compilers produce truly parallel execution
>		of a particular procedure. (Producing multi-threaded execution
>		of loops etc.) or does the architecture simply allow multiple
>		processes to run in parallel (A la NCR 850).

	A couple of answers here.  The sequent architecture does automatic
	multiprocessing across the available processors.  The scheduler
	works quite well.  The "Parallel Processing" is not done
	automatically!  The Sequent compiler allows you to use library calls
	to implement calls to the parallel processing routines.  There are
	third party compilers that try to parallelize loops and such.
	But for anything of any complexity, it is up to the person writing
	the program to parallelize it.  This is not too difficult once
	you get used to using the library calls.  The effort needed to
	parallelize you rprogram is completely dependant on the complexity
	of your program.  The library routines are quite easy to use.
	
>
>	2)	I believe they run under Dynix. Is this compatible with "real"
>		(AT&T) unix. (5.3 / 5.4 etc)

	The parallel processing libraries are not available under the AT&T
	dynix (they soon will be).  DYNIX is a dual universe OS, running
	both BSD and AT&T.  The parallel processing libraries are available
	under the BSD universe.  The AT&T universe has few inconsistencies
	with standard AT&T 5.2.  However, all administration is BSD.
>
>	3)	Does the architecture "scale" correctly, ie does performance
>		increase linearly with the number of processes added?

	My tests say YES!!!
>
>	4)	The machine that I have seen has 2 dual-processor 386 boards
>		with each chip running at 16 MHz. Are there speed up (33MHz)
>		options available? What about 486 boards?

	I'm not aware of any clock speed-up options.  I'm sure the 486
	boards will be available sooner or later.  But I don't have
	hard info.
>
>	5)	What are your experiences with bug-fixes and customer-support?

	Very responsive!  Bug fixes have been shipped promptly.  CUstomer
	support is great (although, we had some trouble with the time
	difference between Oregon and the east coast (7 AM in NJ is 4 AM
	in Oregon and no one is awake.)
>
>	6)	Given a free choice, would you buy another one...

	Absolutely!!!!!!!!
>
>Thanks, treval

Your welcome.



John O'B


John J. O'Brien
ISCP (Integrated SCP)
ctt!johno or johno@ctt
RRC 4B-307
699-8788

In article <17580@bellcore.bellcore.com> johno@dduck.UUCP (John OBrien) writes:
>A couple of answers here.
>The sequent architecture does automatic multiprocessing
across the available processors.
>The "Parallel Processing" is not done automatically!

Oh?      What's the difference?  [*if you think this terminology is bad,
I can refer you to other vendors with bad terminology...*]

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

In article <5053@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
>In article <17580@bellcore.bellcore.com> johno@dduck.UUCP (John OBrien) writes:
>>The sequent architecture does automatic multiprocessing
>across the available processors.
>>The "Parallel Processing" is not done automatically!
>
>Oh?      What's the difference?  [*if you think this terminology is bad,
>I can refer you to other vendors with bad terminology...*]

Here's the deal:

If you and I each launch a dozen processes or so on a ten processor
machine, the kernel scheduler worries about which to run where, and
silently handles getting our 24 jobs done on 10 processors.

However, if I want to run a DSP application in parallel on 4 processors,
then I have to embed the appropriate parallel directives in my code
at compile-time, ie. the compilers won't generate parallel code for me.

---Rsk

In article <11500@boulder.Colorado.EDU> rsk@boulder.Colorado.EDU (Rich Kulawiec) writes:
>In article <5053@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
>>In article <17580@bellcore.bellcore.com> johno@dduck.UUCP (John OBrien) writes:
>>>The sequent architecture does automatic multiprocessing
>>across the available processors.
>>>The "Parallel Processing" is not done automatically!
>>
>>Oh?      What's the difference?  [*if you think this terminology is bad,
>>I can refer you to other vendors with bad terminology...*]
>
>Here's the deal:
>
>If you and I each launch a dozen processes or so on a ten processor
>machine, the kernel scheduler worries about which to run where, and
>silently handles getting our 24 jobs done on 10 processors.
>
>However, if I want to run a DSP application in parallel on 4 processors,
>then I have to embed the appropriate parallel directives in my code
>at compile-time, ie. the compilers won't generate parallel code for me.
>
>---Rsk

And, if you and I each launch a parallelized application involving 10
processes on a 16 processor machine, the scheduler does _not_ assure
that either all my processes or all your processes are running.  In
this situation a process can spend an entire time slice waiting busily
for a lock to clear while the process that could clear it is not
occupying a processor.  This leads to poor and erratic performance.

But wait, Sequent provides the capability for tacking a process to a
processor (preempted by only a few system activities), thereby
improving single-application performance (and making it repeatable).
This is called "processor affinity."

At LLNL software was developed in 1986-87 that scheduled "gangs" of processes
together, preempting entire gangs when a new gang appeared or when
a looooong time slice elapsed.  This is a very nice approach if
generalized to schedule more than one gang when possible.  Sequent
spoke of doing this, but I know nothing of the status of this thing.


Rod Oldehoeft                    Email: rro@CS.ColoState.EDU
Computer Science Department      Voice: 303/491-5792
Colorado State University        Fax:   303/491-2293
Fort Collins, CO  80523

In article <5053@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:

>>The sequent architecture does automatic multiprocessing
>across the available processors.
>>The "Parallel Processing" is not done automatically!
>
>Oh?      What's the difference?  [*if you think this terminology is bad,
>I can refer you to other vendors with bad terminology...*]

A reasonable question.  Here's the definition I've been using to explain
the terms "multi-processing" and "parallel-processing."  They've worked
well in the context of my talks, papers, etc.  Of course, they can
be generalized to death if you like.

"multi-processing" occurs when several processors within the same architecture
are running different, loosely coupled processes or programs.  These
programs/processes are NOT closely related to each other, although they may
communicate with each other via IPC or shared memory or such.

"Parallel Processing" is the decomposition of a single program or process
into several smaller, tightly coupled processes.  These are closely related
and use more sophisticated techniques for IPC such as spin locks, barrier
setting etc.

As stated above, either of these definitions can be extended to cover the
other if you please.  I show a picture with these definitions to clear
up any ambiguity in my meaning.  The multi-processing one shows several
processes running disjoint on several processors.  The parallel processing
one shows a large program being broken up, run, and then being put back
together.



John O'B


John J. O'Brien
ISCP (Integrated SCP)
ctt!johno or johno@ctt
RRC 4B-307
699-8788