Hi,
[... stuff deleted ...] > The VM has been reworked quite a bit. Did you hit swap during any of your > tests? Also, is this EV6 or EV67? Reworked is good - it's rather a total rewrite ;-) The VM is one of my suspects, but I also question the new scheduling policies. As all UP2000's being EV-67 ( or 68 ), mine is a EV-67, 667Mhz and 2Mbytes L2. The system comes with 1.5Gig RAM, which should ( and does ) ensure, that swap isn't reached. [ ... on kernel 2.2.19 crashing ...] > Take out the RTC and see if that helps. I've had problems with it on my > UP2k here and there. I don't think that it is a good solution, > personally, but if it works... Good, i'll try that. I obviously have CONFIG_RTC set. On that issue: It used to be the case, that the Alphas encountered clock-skews without that option set in earlier 2.2 kernels, that could be overcome by setting RTC. Is that resolved ? Having the correct time is quite critical in my setup ( time-based services running across several NFS exports ). > What other cards do you have in the system? Oh, also, bear in mind that > the Adaptec driver has changed in 2.4.x, IIRC, so that may explain things > by itself :-) It's 3 adaptecs in there, plus one 3COM networking card ( 905B ). I've seperately ran tests on all harddrives, using bonnie, hdparm and my own stuff. All results indicated no difference in drive performance and associated CPU consumption. All disks are in fact SCSI disks. I had one IDE drive with an SCSI-to-IDE adaptor being connected to it;s own adaptec ( since it can't do TCQ ), but that was completely disabled during the tests. I am aware, that there is a completely new aic driver in 2.4.4, which gave the reason to test disk performance. I do like the fact, that the new driver is apparently able to determine the optimum TCQ depth during run-time. However, i prefer to set things via boot-parameters. Anybody ever figured out, how to do that with the new driver ? On the issue of the performance difference, i have had tests, that measure process CPU consumption with both, times(2) and getrusage(2). The ones with getrusage(2) show strange behaviour, by giving user-times on kernel 2.2.19, that are questionable. Has anybody ever found evidence, that getrusage() reports strange user-times ? The most bizarre thing is, that real- as well as system time seem OK, as well as times(2) times ;-) Anyway, this _is_ weird.... Regards, Kirk -- Thomas Weyergraf [EMAIL PROTECTED] My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S ) "br.ret.spnt.few" - got back from getting beer, did not spend a lot.
