olson@anchor.esd.sgi.com (Dave Olson) (02/14/91)
In <9102131750.AA08632@scripps.edu> jwk@SCRIPPS.EDU (John Kupec) writes: | I just got a fax from SGI heralding the CD-ROM offer. | | They tell me that the CD-ROM drive itself is currently only | available for PI systems. I have a PI but it may not be around | for long. My question is this: | | If I have "hot-wired" a 3rd-party 8mm drive to the SCSI bus of a 210, | shouldn't I be able to similarly attach this so-called PI-only CD-ROM | drive to a 210? Yes, but we won't support it if it doesn't work for you :) The problem is that most of the earlier 4D machines (4D[678]0, not the 4D85, or the 4D[123]X0 machines) had a somewhat incorrect SCSI bus cabling scheme (the stubs for the drives were much too long). The 4D[123]X0 still don't have it completely correct, but it is much better. Still, these machines are more prone to problems with external scsi devices. By the way, the CDROM drive(s) we end up supporting will have custom proms in the drive, in order to support booting from existing CPU proms. The main change is to default to 512 byte blocks instead of 2048, and secondarily to claim in the inquiry command that they are device type 0 (hard disk). Re-powering the drive, or a SCSI bus reset will cause it to revert to the hard-disk mode (it has to do it on a bus reset for installs to work correctly after an init 0 without re-powering the CPU). Newer machines (IP12, aka 4D35) will work even if the type is 5 (CDROM), however they still require a default block size of 512 bytes. I've heard rumors that this is basicly what Sun did also. The standalone programs, and the newer CPU proms issue a SCSI command to cause the CDROM to revert (except for the block size) to looking like a CDROM on the inquiry command, etc. For those who might care, the command is a 10 byte command, all zeros, except for the first byte, which is 0xc9. All the drives we are qualifying support playing audio media out the headphone jack, and can be controlled over the SCSI bus with vendor specific commands. In other words, you won't be able to buy a random CDROM and use it for installing bootable software, although you may be able to use it for other purposes. One more point: the bootable CDROM media will look very much like a hard disk, in that it will have a standard SGI volume header, and an EFS filesystem. Future software releases of products that don't require booting from the CDROM may be in some other format, such as ISO-9660. -- Dave Olson Life would be so much easier if we could just look at the source code.
tg@utstat.uucp (Tom Glinos) (02/14/91)
In article <1991Feb14.021900.8427@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: >In <9102131750.AA08632@scripps.edu> jwk@SCRIPPS.EDU (John Kupec) writes: > > >By the way, the CDROM drive(s) we end up supporting will have custom >proms in the drive, in order to support booting from existing CPU >proms. The main change is to default to 512 byte blocks instead of >2048, and secondarily to claim in the inquiry command that they are >device type 0 (hard disk). Re-powering the drive, or a SCSI bus reset >will cause it to revert to the hard-disk mode (it has to do it on a bus >reset for installs to work correctly after an init 0 without >re-powering the CPU). > Why not change the boot proms on the CPU side instead? Convince me that this would be more expensive than the charging scheme that I see on the back of the CD-ROM jewel case.
olson@anchor.esd.sgi.com (Dave Olson) (02/15/91)
In <1991Feb14.155649.20613@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: | In article <1991Feb14.021900.8427@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: | >In <9102131750.AA08632@scripps.edu> jwk@SCRIPPS.EDU (John Kupec) writes: | > | > | >By the way, the CDROM drive(s) we end up supporting will have custom | >proms in the drive, in order to support booting from existing CPU | >proms. The main change is to default to 512 byte blocks instead of | >2048, and secondarily to claim in the inquiry command that they are | >device type 0 (hard disk). Re-powering the drive, or a SCSI bus reset | >will cause it to revert to the hard-disk mode (it has to do it on a bus | >reset for installs to work correctly after an init 0 without | >re-powering the CPU). | > | | Why not change the boot proms on the CPU side instead? | | Convince me that this would be more expensive than the charging scheme | that I see on the back of the CD-ROM jewel case. I don't know anything about the fees that will be charged for CDROM software updates, except that they are supposed to be less than for tape. Upgrading CPU proms has 2 main problems, of which the first is probably the most significant to the engineering community, and the second to the bean counters: 1) creating AND testing new proms for every machine and configuration out there would be a huge engineering job, and one that no one wants to do (we would rather give you new features on existing machines, and new machines). 2) changing cpu proms would require an FE for many sites (not all). Any time you open up a machine and take out the boards, you tend to expose problems that were lurking (heat stress, oxidized connectors, etc., etc., and then you are looking at downtime for the customer and even more expense. someone has to pay for it, either directly, or indirectly in higher costs on future products. NOTE: as always, these are my opinions, and not the official opinion of SGI... -- Dave Olson Life would be so much easier if we could just look at the source code.
tg@utstat.uucp (Tom Glinos) (02/16/91)
>I don't know anything about the fees that will be charged for CDROM >software updates, except that they are supposed to be less than >for tape. CD-ROM $20/month, CD-ROM&Drive $60/month, Tape $60/month >Upgrading CPU proms has 2 main problems, of which the first is probably >the most significant to the engineering community, and the second to >the bean counters: >1) creating AND testing new proms for every machine and configuration > out there would be a huge engineering job, and one that no one > wants to do (we would rather give you new features on existing > machines, and new machines). This means adding code to already existing proms. I don't see it as all that difficult if there is space in the proms. You did leave extra space in the proms, didn't you :-) >2) changing cpu proms would require an FE for many sites (not all). > Any time you open up a machine and take out the boards, you tend > to expose problems that were lurking (heat stress, oxidized connectors, > etc., etc., and then you are looking at downtime for the customer Only if the design and manufacture is questionable. The machine has to go down anyway to install the drive. > and even more expense. someone has to pay for it, either directly, > or indirectly in higher costs on future products. Err, umm... that's what maintenance contracts are for! To pay for hardware and software upgrades. Correct me if I'm wrong. But after a year I've paid $720 for a drive I probably can't use anywhere else. A set of proms, I'm sure, costs far, less. Call me cynical, but the charging structure above suggests that SGI stands to make a fair bit of money on this program.
olson@anchor.esd.sgi.com (Dave Olson) (02/17/91)
In <1991Feb15.212655.4645@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: | >I don't know anything about the fees that will be charged for CDROM | >software updates, except that they are supposed to be less than | >for tape. | | CD-ROM $20/month, CD-ROM&Drive $60/month, Tape $60/month Surely there is a purchase option of the drive also? There is supposed to be. Some sites prefer monthly/yearly charges, others outright purchase. The tradeoff varies. The CDROM is useful for things other than installation also. | >1) creating AND testing new proms for every machine and configuration | > out there would be a huge engineering job, and one that no one | > wants to do (we would rather give you new features on existing | > machines, and new machines). | This means adding code to already existing proms. I don't see it as | all that difficult if there is space in the proms. You did leave | extra space in the proms, didn't you :-) No, it means retrofitting a LOT of changes to PROMS made under perhaps 9 or 10 different build environments (over the course of 5 years), or using the current source. Either way, a LOT of engineering and test time would be required. The company has made the decision (which most engineers agree with) that it simply isn't a good use of engineering time, etc. Also, there simply ISN'T any room left in some PROM's. Even new machines suffer from this problem. It costs to add support for multiple types of cpu/graphics/disk/etc. to a PROM. Believe it or not, a 256Kbyte prom has now become marginal. (PLEASE, don't started bloated software wars here, confine them to comp.arch, etc.). | > Any time you open up a machine and take out the boards, you tend | > to expose problems that were lurking (heat stress, oxidized connectors, | > etc., etc., and then you are looking at downtime for the customer | Only if the design and manufacture is questionable. | The machine has to go down anyway to install the drive. Sorry, but this is simply a fact of life. Yes, design and manufacture play a part, but the older a board and chips are, the more likely you are to see problems introduced by removing, servicing, and replacing the board. Powering the machine off and on really isn't relevant. | > and even more expense. someone has to pay for it, either directly, | > or indirectly in higher costs on future products. | | Err, umm... that's what maintenance contracts are for! | To pay for hardware and software upgrades. I believe that hardware upgrades aren't covered under most service contracts, but are instead billed as part of the upgrade (I could certainly be wrong, and services contracts are sometimes customized). PROMs are usually not covered under software maintainence, to the best of my knowledge. | Call me cynical, but the charging structure above suggests that SGI | stands to make a fair bit of money on this program. Our hope (I sat in on some of the planning meetings) is that we can save money on software distribution costs, and pass that on, either through cost reductions, or through postponing increasing the cost of software upgrades (our costs for tape distribution go up every release, even on a per tape basis). We also hope that CDROM will speed up installation of new software, through higher transfer rates, and fewer media swaps. ========================== Standard disclaimer: I speak only for myself, not for the company, notwitstanding the use of the plural (we/our) above. ========================== -- Dave Olson Life would be so much easier if we could just look at the source code.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/19/91)
Since SGI became profitable and the venture capitalists stopped pouring money into the company, each and everything SGI does is paid for by exactly one source, customers. The money for installing new PROMS on all machines, or just developing the new version comes from customers. My previous employers budgeted $600 to $1,000 to pay for getting a technican to and from a customer site. That did not include spare parts. That was what it cost, not what customers paid. I don't know what SGI figures, but since I have not changed jobs for 5 years, I bet it is not less. Are you sure a field service call to make a an existing $720 drive work is a good way to spend your money? You might convince SGI to delay recovering the cost until the next time you purchased support, hardware, or software, but you would eventually pay. Vernon Schryver, vjs@sgi.com