nick@bilpin.UUCP (nick) (07/25/90)
Forgive me if this subject has already been flogged to death here, but I have only just started receiving this news group. We recently installed a Tower 32/500 into one of our customer sites and experienced some tty performance problems. System: Tower 32/500 16MB Ram 380MB SCSI Hpsio-16 R:1.00.01 Tower 32/700 OS App s/w: Uniplex V:7.00 (32/6x0 R:3.XX.XX executable) Sun Accounts (MF Cobol ET) (32/6X0 R:2.XX.XX executable) S-Message (32/500 native executable) The Problem: Users complained of poor cursor movement and long type ahead delay when using the Uniplex spreadsheet and wp. Both of these were obviously operating in raw mode. Sar produced the following figures: %usr %sys %wio %idle 69 31 0 0 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s 750 100 25 0.00 0.00 14033 601 'ps' revealed a single Sun Account process running (actually the MF Cobol runtime) spinning away clocking up loads of cpu. RTFM (Sys Admin Advanced Tasks 12-22) "A TOWER can typically handle 175 to 250 system calls (if the system is I/O bound) with an upper limit of 400. So we have a process doing loads of sys calls but not reads,writes forks or execs. Now as luck would have it we did not supply the accounting software. However the suppliers typical response was: "It works ok on the 32/600, and NCR says the 32/500 is binary compatible", read "it's not our problem !!!" (anyone heared that before ?) We contacted NCR and received a patch to a couple of kernel modules, one of which was the STREAMS module 'os.o', installed it and, thankyou NCR, things seem to have got better, *but* we need to put up to twenty users on this system, of which at least five will be running this accounting program. Right now I am in discussion with the supplier trying to persuade them that a port to the 68030 line would be a in their interest , but they keep ringing NCR who tell them of the wonderful Tower binary compatibility etc etc.... Anyway I believe that the MF Cobol is broken, in fact, having tested the same code on a 32/600 (R:2.XX) and got the same figures my guess is that it was broken on this release also, *but* impacted less on the tty subsystem and was less noticable. Actually it says a lot for how good Towers have been at spreading a little cpu a long way, but I digress .. Now for the questions : * What system calls is this run-away process making ? * What specifically in the STREAMS code (in os.o) was repaired ? * Is there a compatible Cobol compiler for the 32/500, and is it any better ? * Just how compatible is "binary compatible" ? * Anyone know of any other products that exhibit this behaviour ? and a few remarks : Tower binary compatibility has been a considerable strength and has allowed NCR to generate a large body of third party software at relativly little expense. However the same strength is also a fundamental weakness; this software is often out of date and performs badly. So to round up, thankyou NCR for producing reliable, good quality hardware, and bothering to provide OS upgrades for old machines etc, because a lot of manufacturers don't and wouldn't, but *please*, *please* pay the same attention to your third party software, instead of just concentrating on a small number of supported packages. ISV's and VAR's must be told exactly, both in terms of compatibility and performance what binary compatible really means if they too are to produce the same quality software. -- _______________________________________________________________________________ Nick Price SRL Data || Apple link : UK0001 1 Perren Street London NW5 3ED || UUCP : nick@bilpin.uucp Phone: +44 1 485 6665 || Path : nick@bilpin.co.uk
wescott@Columbia.NCR.COM (Mike Wescott) (07/27/90)
In article <164@bilpin.UUCP> nick@bilpin.UUCP (nick) writes: > The Problem: > Users complained of poor cursor movement and long type ahead delay > when using the Uniplex spreadsheet and wp. [ ... ] > So we have a process doing loads of sys calls but not reads,writes > forks or execs. > Now for the questions : > * What system calls is this run-away process making ? Probably a read on a tty in a non-blocking mode, either with O_NDELAY set or with VMIN and VTIME both zero. > * What specifically in the STREAMS code (in os.o) was repaired ? Heaven knows ... streams/os.o is compiled from streamio.c. If you received a full fledged patch there should be a release definition file along with it. Check out /etc/RELDEF for documentation. The (major) bugs fixed are listed. But you may not be able to pin down which goes with os.o. > * Is there a compatible Cobol compiler for the 32/500, and > is it any better ? I don't know. > * Just how compatible is "binary compatible" ? Good question, impossible to answer precisely. What it means in practice is that we take pains not to break object compatibility where it can be avoided. This even includes objects that are not fully linked making it hard even to modify some of the /usr/include files. We can't always be successful because programmers can be too clever sometimes. I generally see the issue from the standpoint of what we can't change: + some *.h files + size, alignemnt and ordering of structures + major semantics of system calls + system call numbers + many minor ones + some errno returns + filesystem layout (in some cases) Obviously a program that depends on a bug will in turn break when the bug is fixed. This has happened and leads to heated disagreement on what the proper behavior of the system should be. We aren't always successful in maintaining backward compatibility nor do we always get to introduce changes as soon as we would like. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM