kemp@uiatma.atmos.uiuc.edu (John Kemp) (04/16/91)
Well, now that the Snake is out of the bag...
Would anyone care to comment on the diskless
clusterability of the Snakes?
Example: can 720 boot diskless off a 730?
can an 835 boot off of a 730?
-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu
----- ( ( __) decnet - uiatmb::kemp
--- univ of illinois (_ ( __) bitnet - {uunet,convex}
-- dept of atmos sci .(____). !uiucuxc!uiatma!kemp
- 105 s gregory ave ... phone - (217) 333-6881
- urbana, il 61801 ... fax - (217) 444-4393munir@hpfcmgw.HP.COM (Munir Mallal) (04/18/91)
> Would anyone care to comment on the diskless > clusterability of the Snakes? > > Example: can 720 boot diskless off a 730? It will be able to with HP-UX 8.05 released later this year. > can an 835 boot off of a 730? The 835 is not able to boot diskless! > Munir Mallal My opinions are my own.
perry@hpfcdc.HP.COM (Perry Scott) (04/18/91)
>Well, now that the Snake is out of the bag... > >Would anyone care to comment on the diskless >clusterability of the Snakes? Clusters are in 8.05. 8.01, which was a limited release for software vendors, doesn't have clusters. We have a few test clusters up and running in the Lab, one of them about four feet away from me. (Can you say "FAST" ?) The goal is to ship 8.05 in systems being ordered today - the ones with the 90 day lead time. Needless to say, we're motivated. >Example: can 720 boot diskless off a 730? No sweat. > can an 835 boot off of a 730? The 700 lacks cache size to be an effective server. The 800, on the other hand, is built to be a multiuser (or server) machine - it has the big cache, I/O throughput, etc. So, the conventional wisdom here is that the combination doesn't make sense. (Except for the fact that the 700 blows the doors off the 800. The right thing to do is make an 800 with the 700 chipset to get cache + I/O + Specs.) Conventional wisdom has been wrong in the past. If 835 clients on a 730 is a big deal for you, tell us why so we don't get laughed out of our boss's office when we ask to do it. 800/700 clusters are not a no-brainer because PA-RISC (CDFs) have been used in the past to mean "800". The 700 filesystem is different in several ways, which makes the job more interesting. >-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu Perry Scott HP Ft Collins Disclaimer: "If HP paid me enough money to really know about release schedules and feature sets, I wouldn't have time to read News."
alex@sapphire.idbsu.edu (Alex Feldman) (04/18/91)
In article <5570608@hpfcdc.HP.COM> perry@hpfcdc.HP.COM (Perry Scott) writes: >700 blows the doors off the 800. The right thing to do is make an 800 >with the 700 chipset to get cache + I/O + Specs.) > It is my understanding that such a beast will be announced in June. Does anyone know any more about this? -- --alex alex@opal.idbsu.edu Boise State University doesn't have any opinions. Therefore, these are not the opinions of Boise State University.
cag@hpfcso.FC.HP.COM (Craig Gleason) (04/19/91)
>> can an 835 boot off of a 730? > >The 700 lacks cache size to be an effective server. The 800, on the >other hand, is built to be a multiuser (or server) machine - it has the >big cache, I/O throughput, etc. Sounds like Munir's answer made this a moot point, but I need to set this straight. The 835 has a 128kB unified I/D cache, two-way set associative. The 730 has 128kB I-cache and 256kB D-cache, direct-mapped. The whole point of staying with off-chip caches was to make them large enough to handle real applications, server or otherwise. You can argue expandability, but the cache on a 730 will outperform that on the 835 in virtually all cases. Craig Gleason
tml@tik.vtt.fi (Tor Lillqvist) (04/19/91)
In article <5570608@hpfcdc.HP.COM> perry@hpfcdc.HP.COM (Perry Scott) writes:
The 700 filesystem is different in several ways, which makes the
job more interesting.
This is something new. Please tell us more!
--
Tor Lillqvist,
working, but not speaking, for the Technical Research Centre of Finlandkemp@uiatma.atmos.uiuc.edu (John Kemp) (04/19/91)
Now I am really confused... Perhaps if I rephrase the question.
If you had an 835, a couple 720's, and a 730, how would you put
them together?
If I assume that the 835 will not operate in a cluster with the
700's, my guess is that the two 720's served diskless off of the
730 would be the most economical arrangement. The 835 would have
to be accessed via NFS and remote commands.
To complicate the problem, say you have 4 600 MB SCSI disks, a
CD-ROM, a DAT, and an optical jukebox. Where would you put them?
Or better yet, where would they be most accessible and provide
the best performance overall to the cluster?
-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu
----- ( ( __) decnet - uiatmb::kemp
--- univ of illinois (_ ( __) bitnet - {uunet,convex}
-- dept of atmos sci .(____). !uiucuxc!uiatma!kemp
- 105 s gregory ave ... phone - (217) 333-6881
- urbana, il 61801 ... fax - (217) 444-4393ccrth@lut.ac.uk (Rob Thirlby) (04/19/91)
Organization : Loughborough University, UK. Keywords: Information of a technical nature on the 700s is very sketchy in the UK even for serious customers! We have heard that "Task Broker" support for the 700s (and the 800s??) will be available later in 91, ie not in 8.0x. Can anyone confirm this. we are considering an informal cluster (ie not necessarily pure disc/discless arrangements) involving some of our large 800s(3x855, 1x870) and a set of several 750s. The role of the 750s would be as computational engines for the multiaccess 800s. On a related matter, can anyone comment on the future of FDDI in the 800 world? We gather than a board for the 700s is not too far away. Yrs, Rob Thirlby
darrylo@hpnmdla.hp.com (Darryl Okahata) (04/20/91)
In comp.sys.hp, cag@hpfcso.FC.HP.COM (Craig Gleason) writes: > >> can an 835 boot off of a 730? > > Sounds like Munir's answer made this a moot point, but I need to set this > straight. .... I've been waiting for someone to post an "authoritative answer", but I haven't seen one, and so I'll post the following (note that it is *SECONDHAND* information, which I believe to be correct, but I'm not sure): Currently, you cannot mix 800s with 700s in a diskless cluster. You *probably* will in the future, but you cannot do so today (*part* of the reason is that new instructions were added to the 700's instruction set). Here is a matrix describing the CURRENT set of possible CPU combinations (this was copied, without permission, from an HP-internal newsgroup): Servers clients s300/400 s700 s600/800 | v 300/400 yes yes yes s700 no yes no s800 no no no (Note that the S800 client/S800 server entry *might* be slightly incorrect -- I'm under the impression that, while this is generally true, an 815, and only an 815, can be a diskless client. Perhaps someone who knows will clarify this.) Please, don't send me any comments -- I'm just passing on some information, and I have absolutely no connection with the RISC or OS folks. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
perry@hpfcdc.HP.COM (Perry Scott) (04/20/91)
>The 835 has a 128kB unified I/D cache, two-way set associative. >The 730 has 128kB I-cache and 256kB D-cache, direct-mapped. > >Craig Gleason I think the 730 has pointed out this flaw in the 800 "servers" quite well. I wouldn't expect the next generation of 800 server-class machine to have the same flaw. Let's just say the job you guys did on the 700 is causing no small amount of head scratching, even inside HP. For now, a 700 server with a bevy of 700 clients is our best performing cluster at a very reasonable price. Perry Scott
mike@UC780.UMD.EDU (Mike Santangelo) (04/24/91)
In article <5570608@hpfcdc.HP.COM>, perry@hpfcdc.HP.COM (Perry Scott) writes: >>Well, now that the Snake is out of the bag... >> >>Would anyone care to comment on the diskless >>clusterability of the Snakes? > >Clusters are in 8.05. 8.01, which was a limited release for software >vendors, doesn't have clusters. We have a few test clusters up and >running in the Lab, one of them about four feet away from me. (Can you >say "FAST" ?) The goal is to ship 8.05 in systems being ordered today - >the ones with the 90 day lead time. Needless to say, we're motivated. > > >>Example: can 720 boot diskless off a 730? > >No sweat. > > >> can an 835 boot off of a 730? > >The 700 lacks cache size to be an effective server. The 800, on the >other hand, is built to be a multiuser (or server) machine - it has the >big cache, I/O throughput, etc. So, the conventional wisdom here is >that the combination doesn't make sense. (Except for the fact that the >700 blows the doors off the 800. The right thing to do is make an 800 >with the 700 chipset to get cache + I/O + Specs.) > >Conventional wisdom has been wrong in the past. If 835 clients on a 730 >is a big deal for you, tell us why so we don't get laughed out of our >boss's office when we ask to do it. 800/700 clusters are not a >no-brainer because PA-RISC (CDFs) have been used in the past to mean >"800". The 700 filesystem is different in several ways, which makes the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The 'filesystem' is different??? Or do you mean that their is 700-specific code (HPPA1.1 stuff) that the 800 series won't run that is used at boot time? >job more interesting. > >>-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu > >Perry Scott >HP Ft Collins > >Disclaimer: "If HP paid me enough money to really know about release > schedules and feature sets, I wouldn't have time to read News." +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Michael F. Santangelo + Inet: mike@uc780.umd.edu VMS / UNIX Systems + mike@socrates.umd.edu Academic Computing UMUC + Bnet: MIKE@UC780 (The University of Maryland, + MIKE@UMUC (not visited often) University College) +<Your clever net-phrase here>
jim@tiamat.fsc.com ( IT Manager) (04/25/91)
In article <430042@hpnmdla.hp.com>, darrylo@hpnmdla.hp.com (Darryl Okahata) writes: > Servers > clients s300/400 s700 s600/800 > v > s800 no no no > > (Note that the S800 client/S800 server entry *might* be slightly > incorrect -- I'm under the impression that, while this is generally > true, an 815, and only an 815, can be a diskless client. Perhaps > someone who knows will clarify this.) We have an 815, and the docs for it include info on setting it up as a diskless client. We are debating whether to use that feature is worthwhile (i.e. we're replacing the 815 with an 832, and might put all disk resource in the 832, and have the 815 boot diskless, but I'm not sure learning how to handle diskless machines is worth consolidating the disk space, and not having two copies of the OS loaded). I don't know for sure, but I'd bet the 808 can go diskless, too. ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651
bigmac@erg.sri.com (Bryan McDonald) (05/03/91)
In article <5570612@hpfcdc.HP.COM> perry@hpfcdc.HP.COM (Perry Scott) writes: >Maybe "different" is the wrong word here. At the lowest level, both are >McKusik, except the 300/700 implements only one partition. You can take >a 300 or 700 disk and mount it on 300, 700, or 800. > >The 700 is meant to be a workstation, so it follows the 300 way of doing >things. Thus, you don't get partitions, you use "config" instead of >uxgen, don't have disk mirroring, etc. Previously, we could get away >with just using CDFs in clusters to select the right behavior, but with >both 700 and 800 using HP-PA, things will have to change a bit. I was under the impression that the next HP-UX release was going to have disk partitioning for the 300 series, so can I assume that the 700's will as well? And when will I see this? -------------------------------------------------------------------- Bryan McDonald | Computer, Hardware, And Operations Support bigmac@erg.sri.com | CHAOS | ITAD - SRI International
jsadler@misty.boeing.com (Jim Sadler) (05/04/91)
>/ misty:comp.sys.hp / bigmac@erg.sri.com (Bryan McDonald) / 3:39 pm May 2, 1991 / >In article <5570612@hpfcdc.HP.COM> perry@hpfcdc.HP.COM (Perry Scott) writes: >>Maybe "different" is the wrong word here. At the lowest level, both are >>McKusik, except the 300/700 implements only one partition. You can take >>a 300 or 700 disk and mount it on 300, 700, or 800. I never have understood why the 300 was like this. >> >>The 700 is meant to be a workstation, so it follows the 300 way of doing >>things. Thus, you don't get partitions, you use "config" instead of >>uxgen, don't have disk mirroring, etc. And I still don't understand it. Why wouldn't a workstation want the flexability to chose partitions if it is appropriate for their situation/application ? > >I was under the impression that the next HP-UX release was going >to have disk partitioning for the 300 series, so can I assume that >the 700's will as well? And when will I see this? I was under the same impression. I hope my impression is correct. jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
rer@hpfcdc.HP.COM (Rob Robason) (05/15/91)
jim sadler> And I still don't understand it. Why wouldn't a jim sadler> workstation want the flexability to chose partitions if it jim sadler> is appropriate for their situation/application ? Not that I'm to blame for not having partitions on workstations, but I've never seen any real benefit. I've seen lots of problems result from fixed system partitions filling up and having to be tinkered with to recover. There have been things that HP-UX lacked in the past, like ARPA services, NFS, etc, all of which we now have. I missed those terribly, so I consider myself to be realistic in my expectations. But I've never had partitions on my workstation and I've never felt like I was missing out on anything (other than the missed pain of outgrown disk partitions, which I've managed to suplant with the pain of outgrown disks). Given that many of our workstations are managed by the using engineer, who mostly wants HP to simplify her life, and that many more of them are diskless and unaffected by partitions vs. non-partitions, ... What IS the big advantage to partitions on a workstation? Rob "Yes, I work for HP, but ignore what I say here: it's strictly my own."
ianhogg@cs.umn.edu (Ian J. Hogg) (05/16/91)
In article <5570633@hpfcdc.HP.COM> rer@hpfcdc.HP.COM (Rob Robason) writes: > >What IS the big advantage to partitions on a workstation? 1. You can prevent users from filling up entire disks. 2. Mirroring on a partition basis and on-line backups. 3. I hope their aren't too many out there, but I've heard some application like to talk to a raw disk partition and manage it themselves. 4. I can keep a partition from being mounted via NFS. If there is no advantage to having partitions why are they supported on the 800's? It would be reasonable to have the default configuration be one giant partition but ultimately the customers should be able to configure the system the way they want. > >Rob > >"Yes, I work for HP, but ignore what I say here: it's strictly my own." -- =============================================================================== Ian Hogg ianhogg@cs.umn.edu (612) 225-1401
jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (05/16/91)
There have been things that HP-UX lacked in the past, like ARPA
services, NFS, etc, all of which we now have. I missed those terribly,
so I consider myself to be realistic in my expectations. But I've never
had partitions on my workstation and I've never felt like I was missing
out on anything (other than the missed pain of outgrown disk partitions,
which I've managed to suplant with the pain of outgrown disks).
That's a strange attitude that I've seen on comp.sys.hp a few times
already.
Just because you don't think something is useful or desirable, it does
not mean that your customers will agree with you. Please let us make
our own decisions by giving us the functionality and perhaps some
caveats about why we should think hard before we use the facility.
As someone already suggested, there are multiple reasons why we may
want them. You may not agree that the solution we desire is the best
for our situation, but that is for us to decide, not you.
In our case, we happen to have an application that can manage its own
disk, so we have to have two disks on every machine that want to be
able to use it in this mode. Since buying two disks for each
workstation is not necessarily feasible, partitions would come in
handy.system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (05/16/91)
> There have been things that HP-UX lacked in the past, like ARPA > services, NFS, etc, all of which we now have. I missed those terribly, > so I consider myself to be realistic in my expectations. But I've never > had partitions on my workstation and I've never felt like I was missing > out on anything (other than the missed pain of outgrown disk partitions, > which I've managed to suplant with the pain of outgrown disks). I too have encountered several problems with systems that require different partitions for paging, /tmp, user files, etc. - one of the nice things about the Apollo Domain/OS is that there are no partitions (unless you want there to be partitions) so we can run programs that have a very large address space, programs that want >500MB scratch disk space (or both) without headaches for users or sysadmins. I agree that it is desirable that the option exist for those who want to use it (it is a quick way to ensure programs don't go wild and fill your whole disk, and the system probably boots faster). Mike. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
rampson@flash (Michael T. Rampson) (05/16/91)
> What IS the big advantage to partitions on a workstation? > It is nice to have a local partition for swap, this can speed up a workstation quite a bit not having to rely on the network to do swapping, especially if you run applications that are resource hogs like VUE, softbench, etc. "There is no dog" -- A dislexic atheist.... rampson@uswat.uswest.com
jsadler@misty.boeing.com (Jim Sadler) (05/16/91)
/ misty:comp.sys.hp / rer@hpfcdc.HP.COM (Rob Robason) / 4:06 pm May 14, 1991 / >Not that I'm to blame for not having partitions on workstations, but Well I wouldn't blame anyone (who me?) but, I would like to put the person who made the decision into my shoes at times. >I've never seen any real benefit. I've seen lots of problems result from >fixed system partitions filling up and having to be tinkered with to recover. I would much rather "tinker" with a /tmp, /usr/tmp, /usr/spool/* partitions than the / partition. >so I consider myself to be realistic in my expectations. But I've never >had partitions on my workstation and I've never felt like I was missing >out on anything (other than the missed pain of outgrown disk partitions, >which I've managed to suplant with the pain of outgrown disks). I've found that on HP-UX systems, we out grow the partitions because we can't size them to the application/use of the system. (Any chance of LVM by 8.5 ?) >Given that many of our workstations are managed by the using engineer, ^^^^^^^^^^^^ This is your use and maybe the majorities use it is not everyones use. The 300/400 make good solid platforms for servers, multiuser, and data collection/analasise systems. Here they are VERY seldom used as workstations. >What IS the big advantage to partitions on a workstation? It depends on what you are doing. Be flexible. Let the customer implement policy and give her the tools to do the job. >Rob >"Yes, I work for HP, but ignore what I say here: it's strictly my own." Thank you very much. I don't know about anyone else but I value HP employee's opinions more than HP's. ---------- jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
chan@hpfcmgw.HP.COM (Chan Benson) (05/21/91)
> There have been things that HP-UX lacked in the past, like ARPA > services, NFS, etc, all of which we now have. I missed those terribly, > so I consider myself to be realistic in my expectations. But I've never > had partitions on my workstation and I've never felt like I was missing > out on anything (other than the missed pain of outgrown disk partitions, > which I've managed to suplant with the pain of outgrown disks). > >That's a strange attitude that I've seen on comp.sys.hp a few times >already. > >Just because you don't think something is useful or desirable, it does >not mean that your customers will agree with you. Please let us make >our own decisions by giving us the functionality and perhaps some >caveats about why we should think hard before we use the facility. I think you may have misunderstood. I don't think Rob was saying "I don't need partitions, so nobody else does." Rather "I don't need partitions; I wonder why anybody else would." Then you can come along and say > In our case, we happen to have an application that can manage its own > disk, so we have to have two disks on every machine that want to be > able to use it in this mode. Since buying two disks for each > workstation is not necessarily feasible, partitions would come in > handy. BTW, someone mentioned that partitions are good for local swap (i.e. not swapping over the net. HP-UX on the 300/400/700 does separate swap and file system space, so swap is partitioned. -- Chan "Mr. Snide" Benson
perry@hpfcdc.HP.COM (Perry Scott) (05/21/91)
>As someone already suggested, there are multiple reasons why we may >want them. You may not agree that the solution we desire is the best >for our situation, but that is for us to decide, not you. Given there is a non-zero cost for implementing and supporting these features, are you willing to pay more for an HP system with partitions on it ? In a commodities market like Un*x, a vendor implements those features with highest ROI. That means either high returns in terms of leveraging sales and/or low investment in terms of R&D and support. Apparently, partitions for workstations didn't make the cut. Granted, you may think (and I can't disagree) this is a lousy argument for not doing partitions for workstations when they already exist on the 800s. But I'm sure you can appreciate not having to pay for other extra bells and whistles you don't need. Whenever a feature is added, the engineering time must be recouped by surcharging the customer. If you don't, you won't stay in business. I won't even begin to weigh the technical merits of partitions vs their drawbacks. That argument has been around the net once already. Perry Scott "Not representing the opinion of HP." *UNIX is a trademark of AT&T
jim@tiamat.fsc.com ( IT Manager) (05/21/91)
In article <1991May16.011210.17043@cs.umn.edu>, ianhogg@cs.umn.edu (Ian J. Hogg) writes: > If there is no advantage to having partitions why are they supported on > the 800's? It would be reasonable to have the default configuration be > one giant partition but ultimately the customers should be able to > configure the system the way they want. When we used (please don't laugh) Altos computers as our main machines, the Altos's did not support disk partitions or symbolic links. Adding a disk to the system meant you had to add the entire disk under one directory. This was not very convenient from an organizational standpoint. Under HP-UX, symbolic links help to resolve this, but I still prefer partitions. I only wish HP's partition scheme was more flexible. We have several SCO Xenix and Unix machines, which allows complete control over the partition sizes. Under HP-UX 7.0, it was not possible to simply divide a disk drive in half. :-( ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651
scheinin@mrlaxa.mrl.uiuc.edu (Alan Scheinine) (05/21/91)
In article <5570641@hpfcdc.HP.COM> perry@hpfcdc.HP.COM (Perry Scott) writes: >>As someone already suggested, there are multiple reasons why we may >>want them. You may not agree that the solution we desire is the best >>for our situation, but that is for us to decide, not you. > >Given there is a non-zero cost for implementing and supporting these >features, are you willing to pay more for an HP system with partitions >on it ? In a commodities market like Un*x, a vendor implements those >features with highest ROI. That means either high returns in terms of >leveraging sales and/or low investment in terms of R&D and support. >Apparently, partitions for workstations didn't make the cut. > >Perry Scott Do not, I repeat, do not, make arguments based on cost vs. benefit without providing accurate figures on costs. If the cost to HP of implementing a feature is proprietary, then it cannot be used as a basis for an argument in a discussion.
marc@marcal.uucp (Marc Veeneman) (05/21/91)
>Given there is a non-zero cost for implementing and supporting these >features, are you willing to pay more for an HP system with partitions >on it ? In a commodities market like Un*x, a vendor implements those >features with highest ROI. That means either high returns in terms of >leveraging sales and/or low investment in terms of R&D and support. >Apparently, partitions for workstations didn't make the cut. Typical engineer's view of economics. In the real world, the extra cost is paid by normal margins on extra sales, not extra price. Look at the HP12C, sales have been so wonderful that margins could be re- duced (price cut) to increase sales even more. Face it, HP (the world's largest Un*x vendor) is IN the commodities market. -- -------------------------------------------------------------------------------- Marc Veeneman Marcal Systems Corporation voice: 1 708 516 4555 marcal.uucp!marc 720 Industrial Dr, Unit 123 fax: 1 708 516 4411 Cary, IL 60013 U.S.A.
se@snert.ikp (Stefan Esser) (05/22/91)
In article <5570641@hpfcdc.HP.COM>, perry@hpfcdc.HP.COM (Perry Scott) writes: |> Given there is a non-zero cost for implementing and supporting these |> features, are you willing to pay more for an HP system with partitions |> on it ? In a commodities market like Un*x, a vendor implements those There are other companies, that include features into their products, not to sell them more expencive, but to sell more of them. |> features with highest ROI. That means either high returns in terms of |> leveraging sales and/or low investment in terms of R&D and support. |> Apparently, partitions for workstations didn't make the cut. And, well you know, you can cut your cost to about zero, if you stop producing (and selling and supporting ...) anything. ( 1/2 :-) ) We bought a 9000/835 two years ago, and this machine was so disappointing, that I couldn't imagine to buy any HP computer again! Reasons where low performance (because of the HP-IB hard discs) and lots of problems with omissions from the BSD derived kernel. (Things like variable disc partitions, kernel variables like lotsfree, desfree, missing adjtime(), renice(), and lots more.) From these omissions resulted a lot of problems in my daily work as sysadmin. (I don't want to go into detail, but I had A LOT of unnecessary work !) And some features were promised but never delivered ... (There is a rumour from time to time, that SCSI will become available for the HP 9000/835 ... After all these years, I don't know if I am interested anymore ...) And so we didn't even look on HP products, when we bought any computers thereafter. (And we got what we expected, none of the problems we had with the 9000/835!) NOW, with the 9000/7xx, there is a very fast machine. HP-UX looks very interesting. IF we knew, that something has changed in the way HP treats 'features with non-zero cost', we might be interested in HP products again. BTW: making SAM work with non-HP terminals (as was just announced in another article) is another small step into the right direction ... Stefan -- Stefan Esser, Institute of Nuclear Physics, University of Cologne, W. Germany se@ikp.Uni-Koeln.DE [134.95.192.9]
martelli@cadlab.sublink.ORG (Alex Martelli) (05/23/91)
perry@hpfcdc.HP.COM (Perry Scott) writes:
:Given there is a non-zero cost for implementing and supporting these
:features, are you willing to pay more for an HP system with partitions on it?
Let's put it this other way instead: I am willing to buy other workstations,
although they are less powerful or nice, rather than HP 9000/700, because HP
has not seen fit to allow me to partition my disks.
This is a strictly personal technical judgment, expressed by me, not by
the firm I work for; however, my opinion carries some weight here, so we
are probably going to buy from DEC or Soulbourne (this is not a hypothetical
situation - we are indeed about to buy some).
The tradeoff is similar to Sun's prohibition of more than 4 disks on a SCSI
port (4 disks, 2 tapes, 1 CDROM, rather than any 7 SCSI devices), which is
THE reason Sun is not going to be the supplier I recommend.
How much more would it cost, per HP 9000/750, to have the disk partitioning
ability of all other Unix systems - 0.1%?
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).perry@hpfcdc.HP.COM (Perry Scott) (05/23/91)
>>Given there is a non-zero cost for implementing and supporting these >>features, are you willing to pay more for an HP system with partitions >>on it ? In a commodities market like Un*x, a vendor implements those >>features with highest ROI. That means either high returns in terms of >>leveraging sales and/or low investment in terms of R&D and support. >>Apparently, partitions for workstations didn't make the cut. > >Typical engineer's view of economics. In the real world, the extra >cost is paid by normal margins on extra sales, not extra price. I've seen both ends in the analysis - both leveraged sales and opportunity for increasing the profits. In this business, higher profits occur when list price decreases more slowly than manufacturing costs. You're right, I'm not an economist. However, I understand there is no such thing as a free lunch. Perry
conca@handel.CS.ColoState.Edu (michael vincen conca) (05/23/91)
>In article <5570641@hpfcdc.HP.COM> perry@hpfcdc.HP.COM (Perry Scott) writes: >>Given there is a non-zero cost for implementing and supporting these >>features, are you willing to pay more for an HP system with partitions >>on it ? In a commodities market like Un*x, a vendor implements those >>features with highest ROI. That means either high returns in terms of >>leveraging sales and/or low investment in terms of R&D and support. >>Apparently, partitions for workstations didn't make the cut. >> >>Perry Scott > > Do not, I repeat, do not, make arguments based on cost vs. benefit > without providing accurate figures on costs. If the cost to HP of > implementing a feature is proprietary, then it cannot be used as > a basis for an argument in a discussion. Why not? Just because I know something that others may not does not mean I am prohibited from using that information. Besides, I don't think Perry was making his argument based on any hard facts that he would be able to post assuming they even existed. He was merely making the logical argument that adding extra features has to cost the company somewhere, and that in order to keep the cost down, certain trade-offs need to be made. Disk partitions may have been one of these trade-offs. -Mike -=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=- Mike Conca, Computer Science Dept. * conca@handel.cs.colostate.edu Colorado State University * conca@129.82.102.32 "Everyday, as the network becomes larger, the world becomes smaller."
scheinin@mrlaxa.mrl.uiuc.edu (Alan L. Scheinine) (05/24/91)
History ------- Perry Scott writes in article 6317: > Given there is a non-zero cost for implementing and supporting these > features, are you willing to pay more for an HP system with partitions > on it? In a commodities market like Un*x, a vendor implements those > features with highest ROI. That means either high returns in terms > of leveraging sales and/or low investment in terms of R&D and support. > Apparently, partitions for workstations didn't make the cut. Alan Scheinine (me) writes in article 6319: > Do not, I repeat, do not, make arguments based on cost vs. benefit > without providing accurate figures on costs. If the cost to HP of > implementing a feature is proprietary, then it cannot be used as > a basis for an argument in a discussion. Mike Conca writes in article 6377: > Why not? Just because I know something that others may not > does not mean I am prohibited from using that information. > Besides, I don't think Perry was making his argument based > on any hard facts that he would be able to post assuming they > even existed. He was merely making the logical argument that > adding extra features has to cost the company somewhere, and that > in order to keep the cost down, certain trade-offs need to be made. > Disk partitions may have been one of these trade-offs. Rebuttal -------- I apologize for sloppy logic in my previous posting. The cost of implementing a feature is important. For the sake of discussion, we need a dollar amount. Anyone out there with operating system writing management experience, please offer an estimate. I see two flaws in Perry's argument. The first flaw is indicated by the phrase, "Given there is a non-zero cost ..." Perry's argument could be used to dismiss any feature. A certain level of abstraction can be useful in a discussion. But Perry's level of abstraction is stratospheric. The second flaw is the use of HP management's decision-making as a justification for a lack of partitions. Not just an explanation, but a justification. ("Apparently, partitions for workstations didn't make the cut.") Faith in HP management's decision-making must come from experience. I think it likely that many HP users have not found that faith. Mike summarizes the situation well when he writes, "Besides, I don't think Perry was making his argument based on any hard facts that he would be able to post assuming they even existed." Mike's sentence seems to be saying several things simultaneously -- I'll leave it for the reader to consider. Philosophy ---------- If HP dismisses too many features, they seem cheap w.r.t. quality. One wonders what else will be found missing if one makes the "Power Shift." The capability to make disk partitions is often found in UNIX OS's. To argue against them in HP-UX is to provide an example that HP-UX is below average w.r.t. breadth of features. However, that is not the key point. The key point is that if Perry's view of the decision-making on OS features is an accurate description of how HP management thinks, then HP is an unattractive vendor. (To paraphrase John Le Carre's George Smiley, "I've heard all the excellent reasons to do nothing, but ...") By way of contrast, the Series 700 hardware represents a large investment in development. The philosophy seems to be that: being the best will pay back in sales. Software decisions could be made with a similar philosophy. The statement that "a vendor implements those features with highest ROI," does not need to be the most important criterion. Stefan Esser stated the idea more concretely in article 6332. > And, well you know, you can cut your cost to about zero, > if you stop producing (and selling and supporting ...) > anything. We bought a 9000/835 two years ago, and this > machine was so disappointing, that I couldn't imagine to > buy any HP computer again! Reasons where low performance > (because of the HP-IB hard discs) and lots of problems with > omissions from the BSD derived kernel. A discussion based on implementation cost and the effect on sales, with dollar estimates, would elevate the discussion. I made these paragraphs separate to emphasize that this philosophy is not a replacement for facts, but rather, is a separate approach. Needed ------ Perry's argument is an HP archetype. It shuts-down further discussion. The overriding factor is said to be a market analysis beyond the review of most users. I realize that Perry cannot reveal proprietary cost figures. Yet, we must find a productive way to discuss the issue of OS features when cost is cited as a major factor. This will sound impolite, but Perry's choice of words gave me the impression that he did not have any facts concerning the decision not to implement disk partitions. I agree with Mike Conca, "Just because I know something that others may not, does not mean I am prohibited from using that information." (I was wrong.) What is needed is an honest summary -- short of revealing proprietary information. I felt that Perry's remarks were too facile and not actually based on information. Alan Scheinine, Graduate Student email: u10534@uy.ncsa.uiuc.edu Loomis Laboratory of Physics Phone: 217-333-1065 1110 West Green Street FAX: 217-333-9819 Urbana, IL 61801
poulton@hpl-opus.hpl.hp.com (Ken Poulton) (06/06/91)
> In our case, we happen to have an application that can manage its own > disk, so we have to have two disks on every machine that want to be > able to use it in this mode. Since buying two disks for each > workstation is not necessarily feasible, partitions would come in > handy. I believe that on one s300/400 (and I assume 700) disk you can have 1) a file system, 2) swap space, 3) raw space. The norm is to choose the file system size with newfs(1m) and swap fills the rest, but I think you can configure your kernel to say how much to use for swap; the rest is available as "raw disk". Ken Poulton poulton@hpl-opus.hpl.hp.com
poulton@hpl-opus.hpl.hp.com (Ken Poulton) (06/06/91)
>> Given there is a non-zero cost for implementing and supporting these >> features, are you willing to pay more for an HP system with partitions on it? > > How much more would it cost, per HP 9000/750, to have the disk partitioning > ability of all other Unix systems - 0.1%? I think that no one is going to change the price of the 700's based on the cost of adding particular software features. In reality, we have several labs that do HP-UX software; their budgets are set based on the financial performance of that portion of HP and management's view of whether they are adequately staffed to do their assigned jobs. These views and budgets don't tend to change very rapidly. The net result is that at any particular time, there is simply a finite amount of resources (personpower, $$) available to be applied. Whether a given feature makes it into a given release is based on a prioritization of features. There always is a long list and there is a cut line (that tends to move up or down the list as releases get behind or ahead of schedule). Partitions for the s300 just never made it above the cut line. The prioritization tends to be done by management and marketing. That's where you come in: tell your sales rep, or much better, write a letter to the relevant marketing manager when you have particular unmet needs. I don't think that posting here is very effective; it mainly reaches lab folks. My own opinion is that this system tends to freeze out many smaller features (like disk partitions) in favor of a few larger ones (e.g., NFS). I can't judge the correctness of that, just note that marketing is in the driver's seat. If you care about something, let *them* hear it. Lost sales with dollar figures attached speak louder than anything else. Ken Poulton poulton@hpl-opus.hpl.hp.com "Take two standard disclaimers and call back in the morning."