Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!shodha.enet.dec.com!alan
From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.unix.ultrix
Subject: Re: 58n0
Summary: Listen vs. Official Channels.
Message-ID: <1740@shodha.enet.dec.com>
Date: 1 Oct 90 02:42:07 GMT
References: <1990Sep26.095834.3744@ircam.ircam.fr> <2906@canisius.UUCP> <1990Sep30.123350.14441@ircam.ircam.fr>
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 57

In article <1990Sep30.123350.14441@ircam.ircam.fr>, mf@ircam.ircam.fr (Michel Fingerhut) writes:
> Since "DEC" is listening to this group, and sometimes even responding,
> what about a response about this very serious problem (58n0 under
> Ultrix 4.0)?  I.e.:

	"DEC" is a very big company and many of us that are
	listening don't have access to the wide variety of
	hardware needed to test customer problems.  Many of
	those that respond do so because we happen to know
	the answer.  Please don't confuse us with the people
	in the development group who's job it is to test and
	fix these sorts problems.  Occasionally someone in
	Engineering does respond, but usually they're working
	on the bug fixes and new features of the next version.

	If you have a problem the appropirate way to report is
	to submit a Software Performance Report and/or go through
	the Customer Support Center nearest you.
> 
> 1.  What are the problems as known to DEC today (so that we're less
>     pissed off when we encounter them).  That would be *some* help.
>     I am rather upset that the local support tells me, when I call them
>     with this problem "oh yeah we knew this from the start, why don't
>     you just turn all but one CPUs off until further notice...".  If
>     they knew it from the start, don't send us 4.0 or warn us.
> 
	Most problems that we know about go into the release notes,
	but sometimes the problems aren't found until after the
	release notes have been printed.  It would be nice if there
	were a nice easy way to report verified problems back to
	you.

> 2.  What they do or intend to do in order to solve them (other than
>     suggesting we buy another machine and/or go to another vendor, as
>     has already been suggested here).

	Hopefully fix the problem once we know what's wrong.  Of
	course until the people that own the problem know about
	it they can't do anything.  If they don't happen to be
	reading this newsgroup then it might be a while before
	they find out about it.  I won't report a problem to them
	until >>>I<<< can verify it.  Since I don't have a 58xx
	to test with there isn't much I can do.

	One thing that would help is a better description of "slow".  
	What is the program doing?  Lots of system calls, disk I/O,
	network I/O, lots of memory use, paging?  I suggest looking
	at cpustat(1), iostat(1), netstat(1) and vmstat(1).  One of
	these days I'll see if I can put a source archive of monitor
	for V4 on gatekeeper.dec.com.
> 
> Michael Fingerhut


-- 
Alan Rollow				alan@nabeth.enet.dec.com