HDTenEightyP/NetNews huggingface dataset:
From: ajit@iitb.ernet.in (Ajit K. Jena)
Subject: FORMAL METHODS IN MULTIMEDIA SYNCHRONIZATION (SUMMARY of RESPONSES)
Organization: Indian Institute of Technology, Bombay
Date: Thu, 17 Dec 1992 09:38:53 GMT

HI,

The response to my query on MULTIMEDIA SYNCH was very poor. The number
of people interested in the summary far exceeded the number of responses
Anyway, here is the summary of whatever little I got.

--ajit

-------------------------------------SUMMARY------------------------------
Dan Frankowski (dfrankow@cs.umn.edu) writes :

>Delay Jitter Control Scheme for Packet-Switching Internetworks,
>D. Ferrari, Computer Communications, Vol. 15, No. 6, July/August 1992,
>pages 367-373.

>Meta-Scheduling for Distributed Continuous Meda, D. Anderson,
>Report No. UCB/CSD 90/599, October 1990, Computer Science Division
>(EECS), University of California, Berkeley, CA.

My Comments :

The above two are very good schemes for controlling real-time
packet delay and jitter. But they do not deal with MULTIMEDIA 
SYNCHRONIZATION at a process interaction under a FORMAL SEMANTIC 
model.

Scott R. Swix (swix@prism.gatech.edu) writes :

>Try to obtain a copy of the IBM OS/2 MMPM/2 (Multimedia Presentation 
>Manager/2) documentation for programmers.  MMPM includes quite a bit
>of synchronization support, based upon the current industry methods 
>such as master/slave devices, pre-roll (deterministic and non-deterministic)
>etc.  
           
>I also recommend you try to find information about the VideoMedia V-LAN
>system, which provides even more complex and powerful synchronization
>functions.

My Comments :

I dont have access to these. Can anybody please give me any pointers
to its availability ?

Frank Dawson (FDAWSON@DALHQIC2.VNET.IBM.COM) says :

>If you haven't yet, you may want to look at the HyTime international standard.
>You can get a copy from your national standards body representatives.  It is
>numbered ISO 10744-1992.

My Comments :

Have not yet received the above document. Cant comment on its usefulness.

-------------------------------------SUMMARY END------------------------------
-- 
------------------------------------------------------------------------------
Ajit K. Jena                                 Email: ajit@gateway.iitb.ernet.in
Software Engineer                            Voice: +91-22-5783177
Computer Centre                                     +91-22-5782545 (x 2750)
Newsgroups: comp.specification,comp.multimedia,comp.mail.multimedia,comp.software-eng
From: ajit@iitb.ernet.in (Ajit K. Jena)
Subject: FORMAL METHODS IN MULTIMEDIA SYNCHRONIZATION...
Organization: Indian Institute of Technology, Bombay
Date: Tue, 15 Dec 1992 07:27:27 GMT

Hello all,

I am a researcher interested in multimedia communication.

I am looking for reference material in the following area:

"Application of Formal Techniques in specification and
design of synchronization schemes in Multimedia Communication
environment".

Since our newsfeed is not very stable and this topic may
not be of general interest, please mail me all your responses.
I will summarise on the net if there is enough interest.

Thanks.

--ajit (ajit@iitb.ernet.in)
-- 
-----------------------------------------------------------------------
Ajit K. Jena                                    Email: ajit@iitb.ernet.in
Software Engineer                               Voice: +91-22-5783177
Computer Centre                                        +91-22-5782545
Newsgroups: comp.parallel
From: mlevin@husc8.harvard.edu (Michael Levin)
Subject: how to split up task on CM-2 best?
Organization: Harvard University Science Center
Date: 16 Dec 92 14:44:58 EST


    I have a question on how best to organize a task which will run on
the Connection Machine 2 (in C*). I am going to write a genetic
algorithm. Thus, I will have to evaluate a whole bunch of functions, which
can be done in parallel. However, the evaluation of each function
involves computing something which can also be done in parallel very
well (an operation on a large array of independent values). 
Thus I have two independent loops, both of which can potentially be
parallelized over all available processors (the external loop, and the
one in the f() function):

for each formula,
  result = f(array);

So, my choices in coding this thing to run on the CM-2 seem to be:
1) evaluate the functions in parallel - have each processor do the
whole function evaluation by itself
2) do the computation in parallel - have the algorithm do each
function one at a time, but do the computations in parallel
3) do them both in parallel
   I know I can't get something for nothing, but maybe there are
considerations of which I am not aware. Are there any benefits to
following any of these strategies over the others, and if so, why?
Please reply to mlevin@husc8.harvard.edu.

Mike Levin

Newsgroups: comp.parallel
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Subject: Re: Wanted: efficient software lock
Keywords: mutual exclusion, memory models, locks
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development
Date: Thu, 17 Dec 92 22:50:25 GMT

agn@bovic.Eng.Sun.COM (Andreas G. Nowatzyk) writes:
>It might be of interest to note that the above algorithm (and many similar
>ones) assume that memory operations are sequentially consistent (SC). There
>is a significant performance advantage for systems that provide SC memory
>only when needed. These weaker memory models generally require ordering or
>synchronization instructions to appear SC.

>For example, if Peterson's algorithm were used on a Sparc based
>multiprocessor, without using an atomic instruction (swap, test-and-set or
>compare-and-swap), you would still need ordering instructions. In the current
>version 8, this means adding a store-barrier instruction *and* a "swap" that
>is used as a load-barrier (it is not possible to implement this particular
>algorithm without "swap" or "ldstub" on V8 machines). Eventually, in the next
>version of the Sparc architecture, a generalized ordering directive (membar)
>can be used to implement Peterson's Algorithm correctly in all supported
>memory models (TSO, PSO and RMO).

When one adds performance considerations (e.g., cache utilization, cache
coherence and memory bus traffic) to memory consistency considerations (which
determine whether software locking schemes implemented with ordinary
instructions _can_ work), I believe that all software locking schemes should
be comparatively inefficient even with the use of a "membar" instruction...
both getting a word atomically on a system which was the last to update it and
spinning on an unavailable word should be better optimized in atomic
operations than in an implementation of Peterson's algorithm (at least in any
chip I would want to build a shared-memory MP with).

Also, in a non-atomic memory system with instructions like "membar", atomic
instructions may be weakened so that they only guarantee the consistency of
synchronization variables... one might use one technique (e.g., atomic
instructions, Peterson's algorithm with "membar") to control a critical region
_and_ an instruction like "membar" to guarantee the memory consistency of
non-synchronization variables used within it.  In an operating system
environment, one frequently wants to update a shared variable (e.g., a
counter) without entering a critical region... so if one had an atomic
operation to attempt this without synchronizing other memory operations, it
would gain.

I don't know how much consistency the existing atomic instructions will
provide on a Sparc once "membar" is available... I would guess that, due to
compatibility issues, what they do now would be preserved...  maybe Sparc will
implement weaker versions of atomic operations?

--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

Newsgroups: comp.parallel
From: 00160910@ysub.ysu.edu
Subject: Re: uestion: Memory Addressing
Apparently-To: comp-parallel@relay1.uu.net
Organization: Youngstown State University
Date: Sat, 12 Dec 1992 15:49:09 GMT

As far as I know, this problem has not been fully solved yet. I worked
with transputer networks and there each transputer has its own localized
memory. The information is passed around between processor over the
serial links. But of course, I could be out of touch.
-Rick

Newsgroups: comp.parallel,comp.arch
From: wilson@moonshine.llnl.gov (Mike Wilson )
Subject: Re: BBN Monarch
Apparently-To: uunet!comp-parallel
Organization: Magnetic Fusion Energy - LLNL
Date: Mon, 14 Dec 1992 19:04:04 GMT

johnsson@cs.chalmers.se (Thomas Johnsson) writes:


>Whatever happened to the BBN Monarch, the (supposedly) massively parallel
>shared memory multiprocessor?
>-- Thomas Johnsson

If you mean the TC2000, we are still using ours.  I've heard the BBN Division 
that produced it was fairly well along in developing a successor, when it
folded.  I'd call 128 nodes mpp, btw.  

Newsgroups: comp.parallel
From: lenos@tardis (Scott Leno)
Subject: Kiendal Square machine with >32 nodes
Summary: do KSR machines work with more than 32 nodes
Keywords: KSR 32 NODES
Organization: Union College, Schenectady, NY
Date: Sun, 13 Dec 1992 00:37:15 GMT

I have heard that Cornell and NCSC have KSR machines with 128 and 64 nodes
each. What I was wondering was how they do when they have to reference nodes
on another ring of 32. I have seen info on how a program does on a single
ring of 32 nodes, but nothing about how it does when it is spread over more
than one ring of nodes (ie >32 procs). Thanks for any info you might have.
   peace,
      Scott

Newsgroups: comp.parallel
From: steved@lion.inmos.co.uk (Stephen Doyle)
Newsgroups: comp.parallel
Subject: Re: transputers
Date: 17 Dec 92 10:14:52 GMT
Organization: INMOS Limited, Bristol, UK
Apparently-To: hypercube@hubcap.clemson.edu

In article <1992Dec15.134641.8093@hubcap.clemson.edu> cnews@umr.edu (UMR Usenet News Post) writes:
>First a rather silly question.  I know functionally what they are
>but is 'tranputer' a generic term for parllel processors produced
>by SGS Thompson?  (What is it there chip number, ??800, or something)
>Also I hear they will soon be releasing a new chip, ??9000.??
>
>Now my real question(s):
>	Who deals in these things?  I'm looking for implementations on 
>	PC's with both ISA and EISA buses.
>
>	What about the amiga, are there transputer implemetations out there
>	for the amiga (say Zorro IIIbus)?

transputer is a trademark of INMOS Limited, a member of the SGS-THOMSON
Microelectronics Group of Companies.

The transputer family consists of a number of products, the T225 is a 16-bit
architecture, T425 is 32-bit (with a low cost variant the T400), 
T805 is 32-bit + on-chip floating point unit. All transputers incorporate
communications links and on-chip memory. The latest T9000 processor
provides additional ease of use, high performance communications links
and an order of magnitude CPU performance increase.

There is a motherboard for the PC ISA bus available under the INMOS
iq Systems brand name - this family of products covers board level products
based around the transputer and software products for transputer programming.

The transputer is sold and supported through SGS-THOMSON regional sales
offices and authorised distributors. There are too many to list here and
so if anyone wants to be put in touch with their local sales outlet please
email me and I will forward appropriately.

regards,

Steve Doyle

Steve Doyle, Software Marketing, INMOS Ltd   | Tel +44 454 616616
1000 Aztec West                              | 
Almondsbury                                  | UK: steved@inmos.co.uk
Bristol BS12 4SQ, UK                         | US: steved@inmos.com
Newsgroups: comp.parallel
From: jet@nas.nasa.gov (J. Eric Townsend)
Subject: Re: Info on SHPCC?
Apparently-To: comp-parallel@ames.arc.nasa.gov
Organization: Numerical Aerodynamic Simulation, NASA Ames
Date: 17 Dec 92 11:34:42

"jet" == J. Eric Townsend <jet@nas.nasa.gov> writes:

jet> Apparently-To: comp-parallel@ames.arc.nasa.gov


jet> Anyone have electronic copy of an announcement/schedule for SHPCC
jet> '93 and '94?


And the answer is, there will be no SHPCC in '93.  I still don't have
a location for '94.


--
             J. Eric Townsend --  jet@nas.nasa.gov -- 415.604.4311
              '92 R100R, DoD# 0378, BMWMOA, AMA, ACLU, EFF, CPSR
                                "HotHead Rules!"

Newsgroups: comp.parallel,comp.arch
From: johnsson@cs.chalmers.se (Thomas Johnsson)
Subject: BBN Monarch
Apparently-To: comp-parallel@uunet.UUCP
Organization: Dept. of CS, Chalmers, Sweden
Date: Fri, 11 Dec 1992 17:34:20 GMT


Whatever happened to the BBN Monarch, the (supposedly) massively parallel
shared memory multiprocessor?
-- Thomas Johnsson
-- 
Thomas Johnsson  (johnsson@cs.chalmers.se)
Dept. of CS, Chalmers University of Technology, S-412 96 Goteborg, Sweden
phone: dept: +46 (0)31 721088.

Newsgroups: comp.parallel
From: strang@besos.corp.sgi.com (Bill Strangman)
Subject: Info request for Parmacs
Apparently-To: comp-parallel@uunet.uu.net
Keywords: Parmacs
Organization: Silicon Graphics, Inc.
Date: Thu, 17 Dec 1992 19:12:32 GMT


If anyone can mail me info on "Parmacs" (a package from Argonne Labs)...
where to get it, who to contact, what it does...I would be most appreciative.     

Please reply to me directly:  strang@sgi.com.


Thanks in advance,
Bill Strangman





Newsgroups: comp.parallel
From: Thomas Zurek <s_zurek@ira.uka.de>
Subject: Re: Connection Machine C* programming problem - linked lists
Keywords: Connection Machine, C* C star, CM
Organization: University of Karlsruhe, FRG
Date: 	Wed, 16 Dec 1992 14:19:57 +0100

In article <1992Dec15.134619.7889@hubcap.clemson.edu>, hackeron@athena.mit.edu (Harris L Gilliam) writes:
|> 
|> Hi,
|> 
|> 	Has anyone found an efficient solution to the restriction that C*
|> imposes, namely no parallel variables or pointers as structure members ?  One of
|> the most common C data structures is the linked list, and a very usefull one, but
|> this restriction elliminates the common implementation of linked lists.  Has
|> anyone found a way around this ?


Earlier this year I was implementing an experimental relational
database system using the following declarations:

    typedef int:physical columntype;

    struct columnlist { columntype         *column;
                        struct columnlist  *next;
                      };

So the solution is to use a pointer to a parallel variable (as
a member of the structure) rather than the parallel variable
itself.
I hope this will help you.

Cheers

Thomas

---------------------------------------------------------------
Thomas Zurek
Fakultaet fuer Informatik           Dep. of Computer Science
Universitaet Karlsruhe              University of Karlsruhe
Deutschland                         Germany


Newsgroups: comp.parallel
From: kcsmith@mtu.edu (Smith)
Subject: p4 error messages
Organization: Michigan Technological University
Date: Thu, 17 Dec 1992 20:25:38 GMT

Does anyone out there know if the error messages generated by p4 are
documented?  If so, where can I get the documentation?

I have seen errors such as

bm_list_403: Listener: Unable to interrupt client pid=32094
rm_l_1_31273: p4_error: interrupt SIGINT:2

I am a new user to p4, and I am running it on the Alliant Campus system.
If anyone has any ideas what these errors mean or has any suggestions,
please respond by e-mail.

I will be out of town over the holidays, so e-mail responses will be
appreciated.  (Otherwise, I may miss the postings.)

Thanks,

Kurt Smith
kcsmith@mtu.edu

Newsgroups: comp.parallel
From: engler@cs.arizona.edu (Dawson R. Engler)
Subject: Wanted: efficient software lock
Keywords: locks
Organization: Clemson University
Date: 14 Dec 92 07:07:45 GMT


I need the algorithm for an efficient software lock that does not use
atomic instructions (except perhaps assignment).  Fairness is unnecessary:
in the situation I need this for, ~90% of the accesses are by the same
process, and if the accesses are by someone else, they are allowed to 
have extra overhead.

If anyone can suggest such an algorithm that has worked well for them
in practice, I would be grateful.

Regards,
	Dawson
	engler@cs.arizona.edu

P.S. An alternative solution would be a lock that is very effective in 
     the case of two processes.  Since each lock will belong to a 
     specific process, there is a natural dichotomy between the owner and
     "everyone else".  From this distiction, two logical processes can 
     be created ("me" and "them").

Newsgroups: comp.parallel,comp.arch
From: gottlieb@allan.ultra.nyu.edu (Allan Gottlieb)
Subject: Re: BBN Monarch
Organization: New York University, Ultracomputer project
	<1992Dec15.134558.7762@hubcap.clemson.edu>
Date: 15 Dec 92 16:45:26

In article <1992Dec15.134558.7762@hubcap.clemson.edu> wilson@moonshine.llnl.gov (Mike Wilson ) writes:

   johnsson@cs.chalmers.se (Thomas Johnsson) writes:

   >Whatever happened to the BBN Monarch, the (supposedly) massively parallel
   >shared memory multiprocessor?
   >-- Thomas Johnsson

   If you mean the TC2000, we are still using ours.

No the Monarch was different.  Bit serial network interface, MANY
processors.  It was viewed as having a research component unlike the
TC2000, which was planned as a product.  (The second sentence is
somewhat speculation on my part)

Allan Gottlieb

Newsgroups: comp.parallel
From: nadkarni@Solbourne.COM (Sanjay Nadkarni)
Subject: Parallel simulators and debuggers for distributed architectures
Organization: Clemson University
Date: Mon, 14 Dec 92 12:12:32 MST

For a parallel debugger..checkout Ned or Network extensible debugger. 
There was a paper presented at the last Usenix. 

-Sanjay

-- 
Sanjay Nadkarni					nadkarni@solbourne.com 
Solbourne Computer					or
1900 Pike Road, Longmont, CO 80501		uunet!solbourne!nadkarni
303-447-2861 x 550

"my thoughts and opinions.."

Newsgroups: comp.parallel
From: jet@nas.nasa.gov (J. Eric Townsend)
Subject: Info on SHPCC?
Apparently-To: comp-parallel@ames.arc.nasa.gov
Organization: Numerical Aerodynamic Simulation, NASA Ames
Date: 16 Dec 92 11:49:29


Anyone have electronic copy of an announcement/schedule for SHPCC '93
and '94?
--
             J. Eric Townsend --  jet@nas.nasa.gov -- 415.604.4311
              '92 R100R, DoD# 0378, BMWMOA, AMA, ACLU, EFF, CPSR
                                "HotHead Rules!"
From: dongarra@cs.utk.edu
Subject: Message Passing Interface Forum
Organization: Clemson University
Date: Thu, 10 Dec 92 14:26:52 -0500


Dear Colleague,

As you may aware, a process is underway to define a standard message
passing interface for applications on distributed memory concurrent
computers. This process formally began with a workshop held in Williamsburg
in April 1992. Following this a Working Group was formed to carry the
standardization process forward, and a draft standard for message passing was
proposed by Dongarra, Hempel, Hey, and Walker. This proposed standard,
called Message Passing Interface 1 (MPI1), was discussed at a second meeting
held in Minneapolis in November. At this meeting it was decided to
accelerate the standardization process by forming subcommittees to examine
different aspects and to make recommendations, taking MPI1 as a reference
point. The subcommittees will meet approximately every 6 weeks, with the
objective of finalizing the standard by July 1993. The following
is a list of the subcommittees:

	1. Introduction subcommittee
	2. Point-to-point communication subcommittee
	3. Collective communication subcommittee
	4. Process topology subcommittee
	5. Language binding subcommittee
	6. Formal language description subcommittee
	7. Environment inquiry subcommittee

In general, we shall follow the organization and procedures of the 
High Performance Fortran working group. 

For the standard to be a success input from the research community is
essential. I am therefore writing to ask if you would like to assist in
defining the message passing standard by joining up to two of the above 
subcommittees (it has been decided that no individual should be a member 
of more than 2 subcommittees). It is important that the subcommittee members
play an active role in the standardization process, and attend most or all
of the meetings, so please only offer to join a subcommittee if you able
to devote sufficient time to its activities.

Please let me know which, if any, of the subcommittees you would like to join,
and I shall send you you further information on the current status of the
standardization process.

Please note that the next meeting of the subcommittees will take place at the
Bristol Suites Hotel, 7800 Alpha Road, Dallas, Texas. It will start after 
lunch on Wednesday January 6, 1993, and finish at noon on Friday, January 8, 
1993. Reservations are $89 per night and may be made by calling (214) 233-7600 
(mention MPI meeting). The meeting registration fee will be $75. An agenda will
be sent out soon to all subcommittee members.

With Best Regards,
David Walker
Executive Director of the MPI Working Group


Xref: sparky comp.parallel:2760 comp.arch:11742
From: uh311ae@sunmanager.lrz-muenchen.de (Henrik Klagges)
Newsgroups: comp.parallel,comp.arch
Subject: Re: BBN Monarch
Date: 16 Dec 92 21:20:44 GMT
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Apparently-To: comp-parallel@news.Germany.EU.net


Nice computer, the TC2000, BTW. Really worked. Good parallel unix.
Henrik
(henrik@robots.ox.ac.uk)
Newsgroups: comp.parallel
From: " (Stephan Gutzwiller)" <gutzi@ifi.unibas.ch>
Subject: parallel algorithm classification
Apparently-To: comp-parallel@cernvax.cern.ch
Reply-To: baks@ifi.unibas.ch
Organization: Institut fuer Informatik
Date: 15 Dec 92 10:06

==================
Hello netters, 

 we would like to announce the availability of a technical
report from the university of Basel (Switzerland) entitled:

	'BAKS: Basler Algorithmen Klassifikations-Schema'

at the moment there is only a german version of this report
available - we are working on the english translation - via
anonymous ftp from:

	lucy.ifi.unibas.ch          (131.152.81.1)

in the directory 'baks', where a compressed postscript file 
can be found (434 kB).

The report introduces a systematic approach to classifications
of parallel algorithms. 

chapter 1 is a general justification for the need of a classi-
          fication of algorithms and consequences of such an
			 approach to parallel programming. 
chapter 2 introduces the terminology which is later used for
          different classifications of parallel algorithms and
          explains its use by means of a simple example.
chapter 3 shows different possibilities for the classification
          of parallel algorithms emerging from the terminology
          introduced in chapter 2; thus is it possible to focus
          on certain aspects of parallel algorithms.
          We also show how our approach can be used to program
          and evaluate existing machines (i.e. existing
          commercially or public-domain available (virtual) machines
          like express or pvm). On the one hand we briefly 
          introduce a tool that generates from a given specification of 
          an algorithm a program skeleton for a given machine. Thus 
          algorithm portability across different machines is achieved.
          On the other hand a system for creation of synthetic
          benchmarks according to user specifications is sketched.
          Thus a machine can be (synthetically) tested on those
          classes of algorithms which seem relevant to the users.
chapter 4 gives a future outlook.

This technical-report emerged from research projects currently done
at the university of Basel and we are very interested in feedback
from the parallel processing community. To us 'BAKS' seems to be
unique so far, if you know about any other calssification scheme for
parallel algorithms please let us know. Reply any results,
questions, problems etc. to 

	baks@ifi.unibas.ch

----------------------------------------------------------------------------
stephan gutzwiller           phone: 0041 (0)61 3219991
institut fuer informatik     fax:   0041 (0)61 3219915
mittlere strasse 142         email: gutzi@ifi.unibas.ch (NeXT mail accepted)
ch-4054 basel

Newsgroups: comp.parallel