Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!pacbell!lll-tis!oodis01!uplherc!sp7040!obie!wsccs!terry From: terry@wsccs.UUCP (Every system needs one) Newsgroups: comp.unix.xenix Subject: Re: Xenix 2.1.3 slowdown on 286 clone Message-ID: <553@wsccs.UUCP> Date: 28 May 88 06:38:44 GMT Article-I.D.: wsccs.553 References: <5114@cup.portal.com> <10782@steinmetz.ge.com> <235@sdba.UUCP> Lines: 51 Summary: yo, adrianne In article <235@sdba.UUCP>, stan@sdba.UUCP (Stan Brown) writes: > > In article <5114@cup.portal.com> compata@cup.portal.com writes: > > | Several of my customers are running Xenix 2.1.3 on a 1 MB AT clone. They have > > | complained that the system seems to begin running more slowly after it has > > | been up for several days. Even to the point where response to a haltsys > > | requires ten minutes. The problem can be easily cured by rebooting. There are a number of possible problems, the most likely of which is probably the creation of process ID's. We have the same problem on the Ultrix system I'm writing this from. After a while, system performance goes way down and anyone trying to log in via a LAT terminal gets the message "Insufficient node resources". Finally tracked this down to having PID's on interactive sessions "too far apart". The soloution? kill all the getty's and let init restart them. Problem goes away and LAT logins are allowed again. Sheesh! I can live with the stupid parity and virtual device bugs, but this is ridiculous! > > > > I run as long as 20-30 days between boots on both 2.1.3 (286) and 2.2.1 > > (386) systems. I see no slowdowns. I think you have something else going > > on. If you are not running a lot of users, the explanation above explains the discrepancy. Another possibility is: Are your customers using "Smart" ports? These are multiport cards which offload serial I/O processing to "speed up" the CPU. In someone's infinite wisdom, the size of the clist structs went and changed from SCO 2.1.3 to 2.2.x (the modern version of the OS :-). If you are running 2.2.x drivers with 2.1.3, you make have some kernel tromping going on. > You might look for a loose cable to a terminal. Historicaly > on UNIX(tm) machines a loose wire here (which can send random noise > in the port) will drastcly slow down the system as each character > (or what the system thinks are characters) will have to be looked > at by the kernel. Nice try, but SCO put out the message "line noise on tty1A, shutting down port", at least on my system. Besides, if that were the trouble, it would happen immediately, not gradually build up. Even worse, if they are using correct smartports and drivers, each garbage character in would NOT cause an interrupt. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'Admit it! You're just harrasing me because of the quote in my signature!' |