HDTenEightyP/NetNews huggingface dataset:
From: poag@blues.rtp.dg.com (Coleman Poag)
Subject: Re: What exactly does PMGR do?
Date: Mon, 13 Apr 92 13:27:44 GMT
Distribution: na
Organization: Data General Corporation, Research Triangle Park, NC

In article <1992Apr8.175050.22842@ceadg>, michael@ceadg writes:
|> Can anyone give me a good explanation of what PMGR does?  We are having
|> a problem at one of our customer's where PMGR is using 2-3 times as much
|> cpu as we expect (I used CPUTIME from DG's Performance Monitor).  The 
|> machine with the problem is an MV/1000 with 2 printers on the system
|> board and a LAC16-II (RS422) with 7 RS422 terminals and the modem/printer
|> ports on the LAC connected to input devices.  The RS232 inputs on the LAC
|> are not part of the problem, because the condition still exists when the
|> ports are empty.  There are no unterminated lines either.

I'm no VS internals expert, but I have been a AOS/AOSVS/AOSVSII user since 
1979.  In the old days, PMGR used to be involved in passing characters to 
and receiving characters from all character-oriented devices (i.e. anyhting
that's not block-oriented).  Beginning with AOS/VS II rev 2.10, terminal 
services has moved to the kernel and is no longer part of PMGR.  

If I was having the problem you describe, I would use the DG Performance
Monitor to see how many characters PMGR was handling.  I'd probably also use
the LINE_MONITOR program to see if there was an excessive number of characters
coming in on a particular line.  You might also want to look at your parallel 
printer port and the DUART ports on the system board.  

|> I was hoping that information on what PMGR does would help us determine
|> why it is so busy on this system.  Any other suggestions about this 
|> situation would be appreciated, also.
|> 
|> Thanks,
|> mike

-- 

Coleman Poag                     Internet: poag@dg-rtp.dg.com
ECLIPSE Commercial Software      UUCP:     {world}!mcnc!rti!dg-rtp!poag
Data General Corporation
62 T.W. Alexander Drive
RTP, NC. 27709                   Phone:    919-248-5974
From: ms@unity.ncsu.edu (Mark Stubbs)
Newsgroups: comp.os.aos
Subject: Availability of AOS 7.0 distribution for ECLIPSE S130
Summary: Looking for Eclipse s130 distribution of AOS rev 7
Keywords: Aos Distribution Eclipse
Date: 9 Apr 92 16:37:15 GMT
Followup-To: ms@unity.ncsu.edu
Distribution: usa
Organization: Computing Center, North Carolina State University
Originator: ms@ccvr1.cc.ncsu.edu


Hello,

I was wondering if anyone knows where I can get a copy of the system
tape for AOS Rev. 7.0.  I have an Eclipse S130 that I will be resurrecting
this summer and I would like to get a copy of the system.  I have
magtapes onto which the system could be placed.  

I did have a distribution tape for this revision back in 1988,  but
someone took that tape and 'recycled' it into a backup tape.  I know
this revision is out there somewhere,  but I just don't know how to find
it.

Thank you,
Mark Stubbs
ms@unity.ncsu.edu
From: pete@medea.rice.edu (Louis Wu)
Newsgroups: comp.os.research
Subject: Async comm. vs RPC (was Re: Have we....)
Date: 9 Apr 92 18:17:36 GMT
Organization: Whatsamatta U
Originator: osr@ftp


ken@cs.cornell.edu (Ken Birman) writes:
> I agree entirely with this.  What we favor is a "virtual" approach in
> which the user sees the simplest possible user interface, while the
> system cleverly sends messages asynchronously in such a way that nobody
> notices.
> 
> With regard to RPC, though, the problem is that the actual semantics of
> RPC are that the call is "done" when the caller regains control of the
> processor.  So, this very strong semantic really limits the degree to
> which an implementation can be clever...

There are two different types of RPC, those that don't return values and
those that do. The former class gives you the same optimization
opportunities as explicit msg-passing.

The latter class is a little more complicated. In some cases, RPC's
performance could not be improved upon anyway, as the RPC is just an
explicit poll for information that must be acquired before the program
continues. 

If the RPC returns information that is *not* needed immediately, there are
two ways to get performance comparable to async communication:

	1) Restructure the program (values are returned by separate RPCs)
	2) Futures

Futures allow RPC to be used intuitively *and* the RPC to succeed
immediately w/o violating the semantics of the program. Futures are very
efficient w/ tag memory support. However, futures can also be transparently
supported through classes (C++ or otherwise) on systems w/o hardware
support.

--
=============================================================================
Pete Keleher   "Relax! Don't worry! Have a homebrew!"        pete@cs.rice.edu
=============================================================================
From: glew@pdx007.intel.com (Andy Glew)
Newsgroups: comp.os.research
Subject: Re: microkernel layers (was Re: A challenge)
Date: 12 Apr 92 04:12:23 GMT
Article-I.D.: darkstar.32794
Organization: Intel Corp., Hillsboro, Oregon
Originator: osr@ftp


	    Since we're doing challenges, I'd like someone to explain to
    me why a microkernel architecture is any more portable than a monolithic
    kernel that has been designed to be modular, with test-racks that permit
    separate components to be tested in isolation. I just don't see the
    difference. Either I'm stupid, and I'm missing something, or the
    main justification I keep hearing for microkernels (portability) is
    a bogon.

The only reason that microkernels may be moderately more portable is
that they typically allow the different modules to be placed in
separate address spaces - so they *can't* muck with each other's data
structures, even if they wanted to.

Of course, all commercially realistic microkernel operating systems
put most of the server threads in the same address space, so now they
can muck with each other's data structures. Maybe things are a little
bit better, because it is hard to muck with shared data structures in
a multithreaded environment - but I'll bet that we'll soon see a
series of portability problems of the form "Server Thread A mucked
with Server Thread B's address space, and it worked on system XYZ -
but on system ABC the memory architecture was different (read, the
distributed memory implementation exposed a different coherency model)
and now this causes a bug."

Portability comes from modularity. Modularity comes from good initial
design, and preservation of modularity during software maintenance.
Separation of address spaces is the best way known to preserve
modularity during the maintenance phase of a software project's
library.

Unfortunately, shared address spaces lead to efficient implementations
on uniprocessors and tightly coupled multiprocessors.

What is needed is efficient hardware support for multiple protection
domains within the same address space. 

--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: craig@sics.se (Craig Partridge)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 17:55:41 GMT
Organization: Swedish Institute of Computer Science, Kista
Originator: osr@ftp


Well, I'm a networking person who dabbles in systems rather than
a systems person who dabbles in networking, so perhaps I've got
a different perspective.  (I recall a comment by a prominent researcher
to the effect that "you can make a systems person into a networking person
but it takes several years" -- the perspectives are very different).

> GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
>    - RPC is a good idea to base your system on

I think there has been consensus that the RPC interface is one that
application writers like.  However, I think there's also an emerging
consensus that classic RPC (Birrell-Nelson plus obvious extensions) has
about reached the end of its useful life -- gigabit networks and
billion-instruction per second computers mean that a single local
RPC call will take thousands or millions of instruction cycles to
complete.  (Put another way, if you do one RPC call, there's a good chance
you'll spend more time waiting for that RPC call than all the time you'll
spend executing instructions).  Now if you really needed to get a particular
item of data from the remote system, you have to eat the time to cross the
network.  However, classic RPC may require you to make multiple
requests of the same machine to get the data -- and that's *clearly* busted.

However, all that being said, one can retain the RPC interface and
change the protocols underneath and get optimal performance in a gigabit
environment.  (I.e. You only cross the network when you have to).
I showed this in my doctoral dissertation, building on existing work
like REV.  (If you can be patient and not ask for a copy of the thesis, I'd
appreciate it -- I've got a paper summary in the works).

>    - Atomic group communication (broadcast) is highly useful

Well, if you'd said "multicast" instead of broadcast I'd agree.
There's a considerable part of the data networking community that believes
broadcasting is a horrible idea whose time has past.  (Shouting at everyone
in your favorite protocol to reach only some people -- at minimum you ought
to only shout at people who understand the protocol -- better yet is
communicating only with those folks who are interested).

>    - Distributed shared memory in one form or another is a convenient model

I can't agree with this view.  Distributed shared memory has the same
latency problems as RPC and while I've seen some innovative ideas about
relaxing consistency rules, I've yet to see work that suggests that 
one doesn't at least sometimes get badly delayed by consistency requirements.

Craig Partridge
Editor, IEEE Network Magazine
Research Scientist, BBN
Visiting Lecturer, Stanford
(yes I'm too busy...:-)
craig@aland.bbn.com
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 10 Apr 92 10:05:26 GMT
Originator: osr@ftp



 >In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
 >   GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
 >      - The client-server paradigm is a good one

this is about as interesting as saying modular programming is nice -
sure a caller and callee is easiuer to understand than a peer n to n
communicating system - just compare most transaction systems with most
routing algorithms - its peasy to understand even atomic
causal broadcast/replacited former compared to latter
 
 >      - Microkernels are the way to go

this also doesnt say much except that "small is beautiful"
or that the common agreed functionalty is so little that 
the common bit is small - so what? Lindsay Marshall had the idea ages
ago...(viz RESCUE/RiscUnix...)

 >      - UNIX can be successfully run as an application program

hmm - what exactly is unix? what is an "applciation program"?
soudns like a dangerously circular definition...
 
 >      - RPC is a good idea to base your system on
so is X windows based streamed messaging:-)
also, as Craig says, Really Big Networks (like the Internet - say
around 1 million hosts) have latencies and traffic control
requirements that favour streams over request/response...

 >      - Atomic group communication (broadcast) is highly useful
no-one has written the definitive multicast applications support
system really - 

what is really needed here is about 5 years experience with a multicast
TCP socket implementation before we can really tell what people find
useful/easy...

 >      - File server replication is an idea whose time has come
in one sense it came ages ago - many sites i know of replicate s/w 
installations on local disks throughout there LAN/campus net...
in another, where we care about data we use replcated disks on clever
controllers (i.e. we trust hardware engineers a lot further than we
can throw a distributed systems programmer:-)

 >      - Message passing is too primitive for application programmers to use

disagree - why?  its a question of how they are trained and what the
application is...

 >      - Synchronous (blocking) communication is easier to use than asynchronous

again depends on the application...and the programmers

most of my students read Stevens on Unix network programming and start
writing asynch message passing applications with little trouble like a
duck takes to water...

 >      - New languages are needed for writing distributed/parallel applications

yes - i find SR is a pretty nice candidate ...
----------------
i think the really interesting areas now are in combining correctness
arguments with timeliness arguments so we can build reliable
multi-media systems:-)

thanks to Tanenbaum for starting the most interesting debate on a
bboard i've seen since a while!

jon
From: cdash@moet.cs.colorado.edu (Charles Shub)
Newsgroups: comp.os.research
Subject: Controversy
Date: 7 Apr 92 19:35:45 GMT
Article-I.D.: darkstar.32327
Organization: University of Colorado at Colorado Springs
Originator: osr@ftp

Thanks to all the posters for valued comments on both sides of many
issues for several reasons:
1.  you say things that help crystallize the tradeoffs for
    articulation in a classroom , a seminar room, and/or a lab.
2.  you provide articulate statements that help convince me i'm not 
    a lone voice in the wilderness on one side of some topics.
3.  you help me understand a rejection notice saying "why would
    anybody in their right mind take that approach" is more reflective
    of the bias of the referee (or my own inability to provide enough
    context for the concept) than a comment on the worth of the idea.
-- 

charlie shub  cdash@cs.Colorado.EDU      -or-        (719) 593-3492     
  or even  cdash@colospgs (BITNET)  if the above address won't work
From: crispin@csd.uwo.ca (Crispin Cowan)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 17:37:04 GMT
Organization: Department of Computer Science, University of Western Ontario, London
Originator: osr@ftp

In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>Instead,
>for the second act, I hereby challenge all the people who have commented
>on my list to do better.
Ok, taking up the challenge:

1.  We have invented a whole bunch of interesting new computing
    paradigms, including but not limited to Andy's Top Five list.

2.  We have evolved better and better ways to implement these paradigms.

3.  We CANNOT agree on which of them in competing circumstances is best.
    This is the jist of my smart-ass comment about "have to plug your
    own system."  The fact that so many of the leaders of this field
    felt it necessary to weigh in and argue that their favourite
    paradigm was better than the other guy's CLEARLY indicates that
    there is no such agreement on these issues.

The true intent of Andy's question was "Have we settled on anything
being an *optimal* way to do thing X?"  I suggest that there are very
few such answers.  A Few that I can think of:

1.  We can do a lot more with compilers than we thought.  RISC is the
    result.  Perhaps we can do more, esp. WRT distributed systems.

2.  Source-level compatability is a way to get portability across
    architectures.  This was the lesson of UNIX, and it has been proven
    in practice over the years.  NOTE:  this was only made possible
    because a lot of the issues of imperitive programming languages for
    local processing were settled, and we *could* pick a few stable
    languages (C, Pascal, and later Ada, etc.) to use as our portability
    framework.  We're NOT going to get such portability across
    distributed systems until we settle on a few distributed processing
    paradigms.

There may be a few other things that we can all agree on, that we didn't
know 20 years ago, and that aren't trivial, but not many.

>As you can see, all of my points relate to one theme: making it easier to
>build and use distributed systems.
Perhaps my comments also build towards a theme.  We know how to build
distributed systems, but we can't agree yet on which way is best, or
even what "best" means.

Crispin
-----
Crispin Cowan, CS grad student, University of Western Ontario
Phyz-mail:  Middlesex College, MC28-C, N6A 5B7
E-mail:     crispin@csd.uwo.ca		Voice:  519-661-3342 
"If you want an operating system that is full of vitality and has a
great future, use OS/2."  --Andy Tanenbaum




Newsgroups: comp.os.research
From: rcbc@cs.cornell.edu (Robert Cooper)
Subject: Re: A challenge
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Thu, 16 Apr 1992 21:04:53 GMT

In article <33002@darkstar.ucsc.edu> artg@minnow.watson.ibm.com (Art Goldberg) writes:

>    |> 1. If it's not written in C, nobody wants to hear about it.
>    |> 2. If it's not Unix or similar to Unix, nobody wants to hear about it.
>    |>
> 
>    Get real guys.  Just because the only computers you've used run
>    Unix doesn't mean that that's what the world uses.  There are
>    84 MILLION personal computers in the world.  Here is the breakdown
>    of the operating systems they run in 1991 (Source: InfoCorp via NY Times)
> 
>    71% DOS alone
>    9% DOS with Windows
>    7% Macintosh
>    9% Proprietary
>    2% Unix
>    1% OS/2
>   1% Other

What really bothers me about a lot of OS research is how insular much of it
is.  On the one hand many OS researchers do not have experience with
non-Unix operating systems and are unable to recognize the difference
between Unix system development and more general research. Many commercial
systems did think of some things before Unix did. Examples include threads,
virtual memory, virtual machines, typed files. (I'm not saying these are
all *good* ideas, but people should be aware of them.)

On the other hand, we have wildly successful commercial PC operating
systems like DOS which imposes memory restrictions on programs that are
orders of magnitude smaller than both primary and secondary storage limits
on current hardware, and provides not even rudimentary security features. 

This is a recipe for continually relearning five important things every
decade. 
                         -- Robert Cooper
--
--
From: caliban!ig@uunet.UU.NET (Iain Bason)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 22:50:11 GMT
Organization: none
Originator: osr@ftp

In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>   1. Microkernels are the way to go.
>         For the system to work, the kernel has to be reliable.  Putting the
>      file system and other user services inside makes it harder to get right
>      and less flexible.  The performance loss is (guess) less than a factor
>      of two.  If you worry about factors of two, I humbly suggest you write 
>      all your code in assembler henceforth.

A. For the system to work, the file system has to be reliable too.

B. People aren't interested in whether the system works, they're interested
   in whether the software (and hardware) they use works.  That includes
   applications.

C. A and B don't mean microkernels are bad, but they do mean Andy's
   justification for microkernels is unconvincing.

D. I don't see why we need a kernel at all.  The whole idea of a
   user/kernel dichotomy just serves to obscure issues like security
   and modularity.



-- 

			Iain Bason
			..uunet!caliban!ig
From: glenn@ready.eng.ready.com (Glenn Kasten)
Newsgroups: comp.os.research
Subject: Re: Microkernels and Nanokernels
Date: 10 Apr 92 06:37:11 GMT
Organization: Ready Systems
Originator: osr@ftp


In article <32501@darkstar.ucsc.edu>, bsmith@ecst.csuchico.edu (Charles Bennett Smith) writes:
|> In article <32425@darkstar.ucsc.edu> glenn@ready.eng.ready.com (Glenn Kasten) writes:
|> >
|> >A microkernel is usually defined as a relatively small kernel which is
|> >primarily intended to be used in implementing higher-level operating
|> >systems, rather than application programs.  Ready Systems uses the term
|> >"Nanokernel", to mean an even smaller kernel which is primarily
|> >intended to be used in implementing microkernels.
|> 
|> Ok, so what kind of services are provided by a nanokernel?  What kind of
|> services are provided by a microkernel?
|> 
|> Scheduling, semaphores, monitors, memory management, interrupt management?
|> What else?
|> 
|> Can someone give a concise picture of the layering and what is at each
|> level?

The "nanokernel" which Ready Systems is currently developing (it has so
far only been announced by our marketing dept. as a technology, and not
yet as a product) contains all of the features you have suggested, with
one proviso:  The memory management features only include memory
allocation, not memory mapping (protection).  The reason memory mapping
is omitted at the nanokernel level, is to keep the code size small, and
also because memory mapping is not needed for many embedded realtime
applications.  We plan on supporting memory mapping at the
"microkernel" level, if needed by the system.

A concise picture of the planned layering is:

 -------------
| application |
 -------------
|     O.S.    |
 -------------------------------------
| microkernel |      embedded         |
|             | real-time application |
 -------------------------------------
|             Nanokernel              |
 -------------------------------------

Note that the "nanokernel" can either be used to help implement a
"microkernel", or it can also be used directly by some applications.

This is just one definition of the term "nanokernel"; there may
be other definitions.

-- 
Glenn Kasten
Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 
glenn@ready.com (408) 522-7357
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 01:53:40 GMT
Article-I.D.: darkstar.32232
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

In article <32100@darkstar.ucsc.edu> rminnich@super.super.org (yours truly) writes:
>to ftp the OS white paper we have here at super.org, you will find that
    ^^^^^^^^^^^^^^^^^^^^^^^^

Folks, sorry about this, the paper is at 
met.super.org

Don't ask me why not super.org. This is for hysterical reasons. 
You will find in the pub directory
os-workshop (which is where the white paper is)
   (note that this which paper mentions supercomputers, but in fact the 
    issues discussed are in most sections farther-reaching)
mether (which has papers on the DSM i mentioned)
rs6000 (if any of you need a /dev/klog for your AIX systems :-))
Among other things. 

>We shall see. So far, many claims, but I still can't get a useful
>OS based on a microkernel, despite many attempts. 
Now, I really hate to bring this up, but I realized that there
is a very successful microkernel in use on a "popular" workstation.
I.e. you boot a kernel, it successively loads in components
as required to build you a functional operating environment. 
Components include networking,  enet interface, 
nfs, keyboard, mouse, console device, etc. Sounds pretty micro-kernel-like,
huh? BUT, none of you are going to like the answer, so I will make
it possible for you to avoid seeing it :-)

AIX on the rs/6000. Yes, I knew you would not like this answer. I 
don't either. BUT, AIX does have most if not all of the attributes
that people see as desirable in a microkernel. 
Now, if only I could get it to DO something useful.
Note that my above caveat about getting a USEFUL uKernel implementation 
still holds. 

BTW, if there are any AIX wizards reading this, 
anybody out there understand how mmap() in AIX 3.2 maps to device driver
operations at page fault time (i.e. NOT map time, I have that figured out)? 
Any examples of a device driver that supports mmap available? 
ron