Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.databases Subject: Re: status of Ingres Message-ID: Date: 7 Nov 90 19:58:06 GMT References: <2987@canisius.UUCP> <2992@canisius.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 145 Nntp-Posting-Host: teachk In-reply-to: pavlov@canisius.UUCP's message of 4 Nov 90 20:21:47 GMT On 4 Nov 90 20:21:47 GMT, pavlov@canisius.UUCP (Greg Pavlov) said: pavlov> In article , pavlov> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> Because you have chosen the wrong platforms. Sorry about saying pcg> that. DEC 5000, 5800, etc... systems are [ ... ] as full of holes pcg> as emmenthal. Well, things are improving fairly fast, and maybe "full of holes as emmenthal" is too much -- but they are far from mature. You can now run timesharing type operations without too many suprises, and the system anyhow comes up quickly enough :-). pavlov> Do YOU actually use one of these systems every day or is this Yes -- I also occasionally assist the system managers in fairly frequent problem resolution. These systems were very correctly described by DEC as experimental machines, at the moment of the sale about one year ago. The chance taken was IMNHO perfectly justified -- the price was great, the performance was great, tight reliability and maturity were not needed. Some crash here and there is nothing for a timesharing service, and users are patient... pavlov> another one of those rumors you are so fond of cluttering up pavlov> comp.arch with ? Would you please demonstrate how can I clutter up comp.arch with rumours? aren't you exxagerating a bit here? should not you be more cautious with what you say and gross generalizations thereof? You seem very quick at attacking people (first Ingres then me). pavlov> We run a variety of applications, from simple to complex, for a pavlov> rather large number of people. We do not have problems with the pavlov> stability of anything but INGRES. Our systems and other pavlov> applications crash rarely; INGRES crashes daily. Maybe you have not reflected on the idea that Ingres is an extremely complex application. Maybe you are not familiar with the architecture of a large DBMS. It actually is about as complex as the OS itself, indeed much more, and taxes the underlying OS services and the hw very severely. In particular recent DBMS technology uses otherwise little used aspects of the sw and hw, e.g. to implement multithreading, high bandwidth server/client data sharing, etc... A large DBMS is not just like a large application program -- it is far more sophisticated. It is a systems program. The result is that most (probably all) large database managers contain workarounds for many OS bugs or hw problems that are not exercised by any other program, even on mature systems. Think about this: when BSD Unix was first ported to the VAX, it had to contain a few workarounds for hardware problems that were never tickled by VMS, at thousands of sites. pavlov> In November of last year, Uh oh. November last year I would not have run 'cat' on a DECsystem if I had to depend on it :-). When were these machines officially announced? I think that one year ago they were still unofficial. I tried to port some of the GNU sw there and it sort-of worked. I was happy enough, even if I had to battle the compilers, and a buggy processor board. To the best of my knowledge DEC themselves November last year described the MIPS based systems as alpha/beta releases. Also, since November one year ago there have been many major and bug fix Ultrix and processor board releases. Are you sure you and the Ingres guys are running exactly the same release of both hw and sw? If not, they may have serious difficulties reproducing your problems, and thus they may dismiss your reports. pavlov> INGRES sold us licenses for DEC RISC machines. What's written on those licenses? Usually something like "you pay your money you take your chances". The chances seem to be pretty poor when you speak of running a newly released port of a major package on a newly released hardware running newly released systems software. A lot of people are still spitting blood trying to port major packages to SunOS 4.x on the SPARC, or to AIX 3.x on the RS/6000, etc... I remember somebody saying that to port a very large application just from one compiler release to the next on a mature system took 200 programmers one year and a half of work... This was for 7 million lines of code. It turns out that is 300 man years, or 24 thousand lines retested and updated per man year. Probably a bit low -- if you are lucky you can do it faster. Ingres probably is an order of magnitude smaller (hundreds of thousands of lines of code, not millions), and admittedly complexity decreases more rapidly than size. But we have not just change of compile release; we have problems across the entire hw/sw platform. This means probably much more than a few man years. Did Ingres have the time (not just the will) to deploy even just a few man years before the release of their product? Uhmmmm. The Ingres DBMS is IMNHO generally very good; and DEC MIPS based systems are IMNHO very good too, just not mature enough for critical service. So, I would not bet *my* reputation on a combination of just released platform and just released DBMS port. Nobody does miracles. No matter what they say: pavlov> It also demands and receives annual maintenance fees. Which normally entitle you to *report* bugs. You may, ex gratia, also receive some updates, which may or may not fix those bugs; the media on which the updates are sent to you are guaranteed defect free. pavlov> There was no mention of the product being so unstable that we pavlov> need to have a programmer stand by round the clock to recover pavlov> from and clean up after server crashes. Does it work for one hour for one user? Well, it *works* :-). Everything else is your problem. I would venture to predict that if you offer Ingres enough cold cash they will send to you their entire implementation team just to work on your machine and configuration to make it work to your specification, getting around any OS or hw bugs, and ignore any other work they are doing. At moments you seem to be arguing that you should not have to bother about all this -- you pay, you have a contract, you want a product with few problems and prompt service on them. Hahahahahahahahahaha. Good one. Now, if you instead told us how it crashes and your analysis of the problems maybe we could try to guess how much hope to have that DEC or Ingres will fix them up soon, at least on the technical side. For example: many DMBSes exert very badly the virtual memory subsystem of the OS. Ultrix has known problems in that area, which DEC seems unconcerned with (they can be solved by adding more memory :->). Also, many DBMSes do things with the IPC primitives that nobody else does (I read a report of one doing thousands semaphore operations per seconds). If SysV IPC is being used, that can be a problem: many BSD/SysV hybrids have many bugs in that lightly used area. Which release of the compiler was used to compile Ingres? This can be a fairly important bit of information. And so on. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk