HDTenEightyP/NetNews huggingface dataset:
From: wjabi@libra.arch.umich.edu (Wassim M. Jabi)
Subject: Re: CD-ROM question
Date: Sun, 26 Jul 92 16:56:22 EDT
Organization: The University of Michigan, Ann Arbor
Reply-To: wjabi@libra.arch.umich.edu
Distribution: usa

In article <1992Jul24.200942.9644@fnbc.com> lemson@fnbc.com (David Lemson)  
writes:
>...
>Or, you can always use your NeXT CD-ROM player as an audio player (it has  
>a headphone jack and can be controlled via software to play audio CD's)
>
>--
>David Lemson                                           (312) 732-4741
>FNBC Sys Admin (Summer) UIUC NeXT Campus Consultant(rest of the time)
>E-mail to: lemson@fnbc.com                          NeXTMail accepted

Is there any difference in the sound quality/output??
--
Wassim M. Jabi                            (313) 936-0229
Doctoral Program in Architecture, University of Michigan
2000 Bonisteel Boulevard  Ann Arbor  Michigan 48105-2313
wjabi@libra.arch.umich.edu             NeXTMail-friendly
Newsgroups: comp.sys.next.hardware
From: lemson@ux1.cso.uiuc.edu (David Lemson)
Subject: Re: Power Consumption
Organization: University of Illinois at Urbana
Date: Wed, 22 Jul 1992 04:05:39 GMT

sanguish@digifix.com (Scott Anguish) writes:

>Brad Nelson writes
>> In article <1992Jul21.093433.21998@monu6.cc.monash.edu.au>  
>> ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson) writes:
>> > 
>> > Can anybody tell me how much Power my 040 cube with monitor uses?

>> is likely to be? I just used: (.91 X 114 X 24 X 30) / 1000 = 74.7 KWH.


>	Can't you figure this out by what NeXT says are the maximum amounts of  
>power required?

>	150W for the NeXTstations
>	150W for the Color Monitor

No, the original poster's usage of an ammeter in series with the
computer is much more reliable.  150W is, as you might imagine, a
very general number.  The power supply is rated at that, meaning
that it can draw that much if necessary.  If you have no OD in a
cube, for example, it is certainly going to use less power.  But
your power supply is the same! (300W on my old cube)
Also, stating a wattage assumes a certain voltage, which is why the
original poster gave a load in amps and a voltage.  You get watts by
multiplying volts*amps.   .91*114, in this case. (note that this is
103.74, which is MUCH below the 300W that the cube's power supply
can draw if needed) 
-- 
David Lemson                                                 (217) 244-1205
University of Illinois NeXT Campus Consultant  / CCSO NeXT Lab System Admin
Internet : lemson@uiuc.edu                 UUCP :...!uiucuxc!uiucux1!lemson 
NeXTMail accepted                                   BITNET : LEMSON@UIUCVMD
From: alex@cs.umd.edu (Alex Blakemore)
Newsgroups: comp.sys.next.hardware
Subject: Re: looking for source for ZyXel V.32bis/FAX modem
Keywords: modem v.32bis fax
Date: 29 Jul 92 14:01:15 GMT
Distribution: usa
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

In article <mfausett.712374480@kirin> mfausett@bbn.com (Mark Fausett) writes:
> I'm looking for a V.32bis data + fax modem.  I've been warned against the
> supra.  Any suggestions to a source for the XyXel?

Boston Computer has very good prices on ZyXel modems (just over $300) and
had them in stock as of last week.  (617)-551-0166
Boston Computer  cant answer very technical questions
but ZyXel has free phone support

The ZyXel 1496E supports v32b/42b and group 3 FAX
and comes with a 5 year warranty in US and Canada.

I'm not affiliated with them - just a satisified customer

-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted
Newsgroups: comp.sys.next.hardware
From: gvh@metrosoft.com (Gordon Van Huizen)
Subject: Re: Mono -> Sound box
Reply-To: gvh@metrosoft.com (Gordon Van Huizen)
Organization: Metrosoft
Date: Tue, 21 Jul 1992 06:38:21 GMT

In article <4376@rosie.NeXT.COM> John_Graves@next.com (John Graves)  
writes:
> In article <1992Jul15.233600.6607@wcraft.wimsey.bc.ca>  
> jchin@wcraft.wimsey.bc.ca (Joseph Chin) writes:
> > Hello folks,
> > 
> > I have an unused sound box that I want to hook up to a headless cube  
so  
> > that I can use the sound i/o ports for the CallLink answering software  
> > from Quest Technologies. The monitor connector on the system board is  
a  
> > D19 and so is the connector on the sound box. Do you think it is okay  
to  
> > use a normal NeXT monochrome monitor cable to connect the sound box to  
the  
> > system board? Any warnings? I want to get some opinions before I try  
to  
> > fry the system board :-)
> 
> It won't hurt anything.  The sound board in the monochrome monitor is  
the same  
> as that in the Sound Box.
> 
> --
> 
> John Graves
> Hardware Engineering
> NeXT Computer, Inc

What an expensive answering machine!!!
-- 
----------------------------------------------------------------
Gordon Van Huizen           vox: 619.488.9411  fax: 619.488.3045
Metrosoft                   gvh@metrosoft.com [NeXTmail welcome]
----------------------------------------------------------------
From: rsherme@nswc-wo.navy.mil (Russel Shermer)
Newsgroups: comp.sys.next.hardware
Subject: External Bernoulli's and DOS/unix disk formats
Date: 24 Jul 92 20:50:51 GMT
Organization: Naval Surface Warfare Center - White Oak


We installed a 90 Meg Bernoulli drive on our NeXT and
have been quite happy with it until today.  I inserted a disk
that had been formatted on a DOS machine and found that the
NeXT can't read it.  A window opens up as normal and the NeXT
recognizes the disk is a DOS disk but can't read or write it.

You may not be surprised, but considering that Bernoulli's transport
across different unix systems, the Mac can read DOS Bernoullis, and
the NeXT can read DOS floppies.  It WOULD seem reasonable that the
DOS drivers on the NeXT could handle any drive on the SCSI bus.

Is there a special driver one must get from either NeXT or Iomega to
remedy this?

Thanks.

	---Russ Shermer
From: mfausett@bbn.com (Mark Fausett)
Newsgroups: comp.sys.next.hardware
Subject: looking for source for ZyXel V.32bis/FAX modem
Keywords: modem v.32bis fax
Date: 29 Jul 92 01:48:00 GMT
Distribution: usa
NNTP-Posting-Host: kirin.bbn.com

I'm looking for a V.32bis data + fax modem.  I've been warned against the
supra.  Any suggestions to a source for the XyXel?

Mark Fausett
mfausett@bbn.com
From: hss@bigbird.bu.edu (Himanshu Sinha)
Newsgroups: comp.sys.isis
Subject: Array Indexing with addresses
Date: 22 Jul 92 23:20:12 GMT
Distribution: usa
Organization: Computer Science Department, Boston University, Boston, MA, USA

I need to maintain a queue of messages sent by each member of a process group.
When a process receives a message it enqueus it in the queue for the sender of
the message. I want a fast way of finding out which queue to enque it in - so a
associative search in the list of members (using addr_isequal) is not a
preferred solution. I would rather have an array of queues but I do not know
what to use to index this array. I think I can use the pg_rank() of the sender
but I have two questions.

1) The pg_rank() of a process can change if the group membership changes. I
assume that a process will receive all abcasts, cbcasts and fbcasts sent by a
failed process atomically i.e. all members will get them before the groupview
changes or none of them will get them. Can I make any such assumptions about
mbcasts()? (I don't think so.)

2) What is the overhead of pg_rank()? My group will have at most 25 members,
most of them running on backbone machines. Am I better off doing an associative
search? 

Thanks
Himanshu
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Array Indexing with addresses
Date: 23 Jul 92 14:09:41 GMT
Distribution: usa
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

In article <91672@bu.edu> hss@bigbird.bu.edu (Himanshu Sinha) writes:
>I need to maintain a queue of messages sent by each member of a process group.
>When a process receives a message it enqueus it in the queue for the sender of
>the message. I want a fast way of finding out which queue to enque it in...

Unless the number of processes becomes huge, a linear search will be the
cheapest solution.  pg_rank, which you asked about, does a linear search
over the members of the groupview, applying addr_isequal on each, so
it won't be faster. 

If the number does become large (say, 50 or 100 possible senders), 
my advice would be to design a hashed data structure.  Actually, there
is such a thing in the toolkit itself, but not documented.  The
has index should be computed from:
	addr->addr_process -- (low 16 bits of) pid of the sender
	addr->addr_site, addr->addr_incarn -- place it lives
	addr->addr_portno -- UDP port number it is using.

Actually, since hashing is just approximate, you can probably just use
the addr_process information for the hash index and then use addr_cmp
to scan the queue this indexes to.

By the way, SVR4 has 32 bit process-id's and we will go to 32
bits in ISIS V3.0.7 this fall.  Meanwhile, ISIS V3.0.6 can run on
Solaris but will only track the low 16 bits of the pid.  This 
doesn't affect correctness of ISIS itself, since the portno 
is certain to be unique on a given machine, but it could lead to
confusion if Solaris actually generates long pid's on a casual basis.


-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: gdykes@theory.TC.Cornell.EDU (Gene Dykes)
Subject: Isis Employment Opportunity
Organization: Isis Distributed Systems, Inc.
Date: Thu, 23 Jul 1992 20:11:26 GMT

(The following is a copy of a recent posting in the
 misc.jobs.offered newsgroup.)

Isis Distributed Systems is looking for one or two programmers
to work on design and implementation of distributed software with the
Isis Distributed Systems Toolkit.

Isis Distributed Systems is involved in a number of activities
that push the leading edge of distributed computing technology.  The
successful candidate for these positions will have exceptional systems
programming skills, extensive knowledge of UNIX and/or MACH, and will
be aggressive in undertaking challenging assignments.  Experience in
distributed systems programming or network protocol implementations is
desired.  Candidates must be skilled in programming languages, operating
systems, and networking.  Primary development will be done in C on
Sun SparcStations.

An advanced degree or significant relevant work experience is required.

This is a high profile position with strong growth potential.  Starting
salary will be $40K - $45K, plus benefits.

Please send resumes to gwd@isis.com or via snail mail to:

	Dr. Gene W. Dykes
	Isis Distributed Systems, Inc.
	111 S. Cayuga St.
	Ithaca, NY 14850

Either method of communication will receive equal consideration,
but only e-mail will be acknowledged.




-- 
Gene Dykes, gdykes@theory.tn.cornell.edu
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.isis
Date: Thu, 30 Jul 1992 15:12:02 -0400 
From: Sean.Levy@cs.cmu.edu
Subject: task arguments

The man page for isis_entry(3) in ISIS 2.2/3.0.5 implies that you can
associate an argument with a task (e.g. a closure). However, it does not
say any more about it other than the rather cryptic usage info:

...
SYNOPSIS

	int isis_task(task,name)
	int isis_entry(entry,handler/MSG_ENQUEUE,name)
		void (*task)(arg)
		void *arg;
....

The code does not look like it does anything of the sort, e.g. tasks
don't get arguments. Is this something that used to be in the code and
was deleted, something that is coming, or just a typo? I'm trying to
write a generic Tcl interface to ISIS, and closures for tasks are really
needful; I can fake it with a static linked list, but I dislike such
solutions on principle (plus they always end up biting you on the butt
later on if you move to a real multiprocessor).

In general, I would like to see any sort of indirect function calls
anywhere in the system always be accompanied by closures, however and
wherever they are, ala Tk, Xt, and other toolkits for even-driven
environments. It makes life much easier, and you burn at most the size
of a pointer per indirect function, which isn't too bad when you
consider what you gain.

Just my $0.02. Of course, if I'm wrong and there is a way to do this,
please let me know. I *still* think ISIS is the best thing since sliced
bread for building distributed systems (there, now can I get my coffee
mug?? :-)

Cheers,
		-- Sean
--
Sean Levy, n-dim Group, EDRC, CMU, 5000 Forbes Ave, PGH, PA 15213
Email: snl+@cmu.edu, Phone: +1 412 268 5221, Fax: +1 412 268 5229
From: dwf@acl.lanl.gov (David W. Forslund)
Newsgroups: comp.sys.isis
Subject: Postdoctoral researchers sought
Date: 21 Jul 92 05:46:04 GMT
Reply-To: David W. Forslund <dwf@acl.lanl.gov>
Organization: Advanced Computing Lab, LANL, NM


	Distributed Computing Research Position at LANL

The Advanced Computing Laboratory at Los Alamos National Laboratory,
one of two Dept. of Energy High Performance Computing Research
Centers, is promoting technology transfer in advanced computing to
industry, academia, and other national laboratories through the
operation of an experimental computational laboratory.  We are
supporting an advanced computational environmental for computational
scientists working together in interdisciplinary teams to solve
today's Grand Challenges, forming the building blocks of tomorrow's
computing environment, and educating others in the tools of the trade.
We are currently seeking highly qualified Postdoctoral candidates for
an aggressive research program in distributed computing involving high
performance networks (gigabit/sec) and large scale parallel machines
(64K CM-200, 1024 node CM-5).  This environment is envisioned to
support not only Grand Challenges, but provide a fundamental
capability for simulations appropriate to a wide variety of industrial
applications.  If this opportunity is of interest to you please send
a brief resume including your research interests to:


David Forslund
Deputy Director
Advanced Computing Laboratory
MS B287
Los Alamos National Laboratory
Los Alamos, NM 87545

Voice:(505) 665-1907
FAX: (505) 665-4939
EMAIL: dwf@lanl.gov



--
David Forslund
Advanced Computing Laboratory
MS B287
Los Alamos National Laboratory
Los Alamos, NM 87545

Voice:(505) 665-1907
FAX: (505) 665-4939
EMAIL: dwf@lanl.gov
From: hss@bigbird.bu.edu (Himanshu Sinha)
Newsgroups: comp.sys.isis
Subject: Getting client dumps
Date: 21 Jul 92 19:48:14 GMT
Distribution: usa
Organization: Computer Science Department, Boston University, Boston, MA, USA

The manual says that I can get a client dump if I send the HANGUP signal to the
client. When I do that all I get is a "Hangup" message and the process exits.
I can't find a <pid>.log file anywhere.

What am I doing wrong?

Thanks
Himanshu
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Minor "gotcha"
Date: 28 Jul 92 17:31:28 GMT
Article-I.D.: cs.1992Jul28.173128.9845
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

The V3.0.6 release notes neglect to point to a change to a fairly
obscure Isis interface.

The isis_transport() interface is used to tell ISIS to use special
protocols to talk to remote processes, for example TCP instead of
the normal ISIS UDP layer.  Few users have worked with this interface
although we use it ourselves for hardware multicast (ether) support.

The V3.0.6 notes should have indicated that the "newview" function
of an ISIS transport package is now passed the groupview structure
as an argument instead of the ginfo structure, as was done in the
past.  Thus, where you used to have to say:

tcp_newview(gip)
  ginfo *gip;
  {
	groupview *gv = gip->gi_bypassview;
	...

you now say:
tcp_newview(gv)
  groupview *gv;
  {
	....
  }

Obviously, this is much more natural to most users, since the ginfo
structure is internal and undocumented...  We regret the omission
in the release notes and hope it didn't cause problems for anyone.

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: ISIS 3.0.5 & Round trip time (Bug ?)
Date: 21 Jul 92 15:44:15 GMT
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

In article <1992Jul21.135255.28380@dxcern.cern.ch> fabien@sun2.cern.ch (Fabien Collin) writes:
>	Between 1 and 14624, the time varies linearly from 6 ms to 55 ms.
>	Suddenly, between 14624 and 14625, it takes 0.5 seconds more
>	to do the round trip. The same phenomenon is repeated each time
>	you add 14800 bytes. 
>
>	I suppose the discontinuity is due to the size of a buffer.
>	But half a second each 14800 bytes seems to be enormous to me.
>	Is it a bug ? 
>	If it is, is it fixed in 3.0.6 ?

Yes, it is a bug -- a problem in our flow control code, which got
confused, fixed its confused state after a half-second timeout, and
repeated this if the pattern causing the problem recurrs.

And, yes, we fixed it in V3.0.6/V2.2.6

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Contents of the archive
Date: 25 Jul 92 02:24:52 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

I have created a file pub/comp.sys.isis/802-876.TAR.Z on ftp.cs.cornell.edu
with the articles listed below in it.  (Older postings are also available)
802: LISBOA '92: An Advanced Course on Distributed Systems.
803: Simulation; NIGEN++
804: Limits on "TCP" connections to ISIS
805: Question on groupview
806: Horus?
807: Re: Question on groupview
808: Re: Horus?
809: News Service performance numbers.
810: Hardware multicast
811: Re: Horus?
812: *** CFP 5th ACM SIGOPS European Workshop ***
813: ISIS over the internet
814: Re: ISIS over the internet
815: Question about %f
816: ISIS V3.0.6/V2.2.6 (pre-announcement)
817: V3.0.6 on some new platforms
818: Virtual reality system based on ISIS
819: fbcasts and abcasts
820: Re: fbcasts and abcasts
821: Osiris SE
822: Isis version 2.2 available ? 
823: Re: Isis version 2.2 available ? 
824: Re: Isis version 2.2 available ?
825: Time warp ?
826: Re: Isis version 2.2 available ?
827: Re: Osiris SE
828: Re: Time warp ?
829: Re: Isis version 2.2 available ?
830: Re: Isis version 2.2 available ?
831: State transfer FROM the new member
832: Re: State transfer FROM the new member
833: Tasks scheduling & ISIS 
834: Re: Tasks scheduling & ISIS 
835: ISIS header file naming conventions
836: Re: ISIS header file naming conventions
837: Re: ISIS header file naming conventions
838: ISISV3.0.6-OBSC.TAR.Z
839: Re: ISISV3.0.6-OBSC.TAR.Z
840: problems with isis_define_type
841: Re: problems with isis_define_type
842: shared libraries
843: Drink your coffee in real style...
844: tech report on ISIS resource mgr available
845: V3.0.6/V2.2.6 -- a minor delay
846: Re: V3.0.6/V2.2.6 -- a minor delay
847: Re: Drink your coffee in real style...
848: Paralex ?
849: Resource and Appointment Scheduling System in ISIS
850: Re: Resource and Appointment Scheduling System in ISIS
851: ISIS programs needed
852: Isis 2.1 and XView 3.0
853: t_pass token tool
854: Re: Isis 2.1 and XView 3.0
855: Re: t_pass token tool
856: Re: Isis 2.1 and XView 3.0
857: Re: Isis 2.1 and XView 3.0
858: ISIS V3.0.6/V2.2.6 release announcement
859: Task scheduling using the Isis light weight task system
860: Re: Task scheduling using the Isis light weight task system
861: Replies to message
862: Late breaking ISIS V3.0.6 news
863: Re: Replies to message
864: Crashing coordinator (V2.1)
865: Re: Crashing coordinator (V2.1)
866: Unread bcast msg overhead?
867: Re: Unread bcast msg overhead?
868: Postdoctoral researchers sought
869: ISIS 3.0.5 & Round trip time (Bug ?)
870: Re: ISIS 3.0.5 & Round trip time (Bug ?)
871: Getting client dumps
872: Re: Getting client dumps
873: V2.2.6/V3.0.6 "grid" demo
874: Array Indexing with addresses
875: Re: Array Indexing with addresses
876: Isis Employment Opportunity
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: fabien@sun2.cern.ch (Fabien Collin)
Subject: ISIS 3.0.5 & Round trip time (Bug ?)
Organization: European Laboratory for Particule Physics (CERN) Switzerland
Distribution: comp
Date: Tue, 21 Jul 1992 13:52:55 GMT

	I did a benchmark to evaluate ISIS round trip time.
	I used ISIS 3.0.5 with two SUN 4C under SunOS 4.1.1 connected by
	Ethernet.

	I have two processes (a master and a slave) which belong to the same
	group (Bypass facility is used).
	The following operation is repeated n times :

	The master send a message (size = s) with a cbcast to the slave.
	The master then waits for a reply. The slave replies by sending
	a message (size = r). 

	I did a test with s = r and the mean time for the round trip was
	measured, I obtained the following results :


	Msg Size (s,r) (bytes)		Round trip time (ms)
	1				6
	14624				55
	14625				550

	29424				600
	29425				1100

	44224				1150
	44225				1650

	59024				1750
	59025				2250

	...

	Between 1 and 14624, the time varies linearly from 6 ms to 55 ms.
	Suddenly, between 14624 and 14625, it takes 0.5 seconds more
	to do the round trip. The same phenomenon is repeated each time
	you add 14800 bytes. 

	I suppose the discontinuity is due to the size of a buffer.
	But half a second each 14800 bytes seems to be enormous to me.
	Is it a bug ? 
	If it is, is it fixed in 3.0.6 ?
	It it isn't, how do you explain this huge amount of time ?

	PS: I obtained the same results with a abcast. It is not surprising
	since I used only 1 destination and only this event exists in the system.

	PS2: Same results with two asynchronous cbcast (or abcast).


	Cheers,

								Fabien

-- 
-------------------------------------------------------------------------
 COLLIN Fabien				| Computing & Networking Division	
 Email: fabien@sun2.cern.ch		| Building 31, 3-013		
 Voice: + 41-22-767-2487		| CERN 1211 Geneva 23		
 Fax :	+ 41-22-767-7155		| Switzerland			
-------------------------------------------------------------------------
Newsgroups: comp.sys.isis
From: kpt@fig.citib.com (Kevin P. Tyson)
Subject: A question about network partition on process groups
Organization: IISA
Date: Thu, 23 Jul 1992 19:00:06 GMT

I am very new to ISIS so please forgive me if this is a FAQ.  I am interested
in using ISIS to implement replicated resource managers.  My understanding is
that the Client-Server Group mechanism is the technique to use for this type
of processing and that the logging facility is the mechanism to use when new
replicas need to be added to the group.

My question concerns the effect of network partition on the server members of
the process group.  Suppose we have a server process group running on four
nodes on a single ethernet segment.  Each node has at least the Protos process
and the server process running.  Each server process is responding to all rpc
calls made to the group.  At some point the segment is split into two segments
of two nodes each.  I assume that the Protos processes on each node will
detect the missing nodes and on the segment which now lacks the primary server
will promote one of the two remaining server processes to the role of primary.
The result of this will be two server process groups, each of which will
continue to operate.

At some point the segments will have to be re-united.  What support is there
in ISIS for detecting the changes that may have gone to one but not both of
the server groups while the network was partitioned?  What support is there
for merging the two server groups into a single server group?

Thanks in advance,
-- 

Kevin P. Tyson		Phone:  212-657-5928	Fax:    212-825-8607
E-Mail: kpt@fig.citib.com
Newsgroups: comp.sys.isis