jimmy@denwa.info.com (Jim Gottlieb) (07/02/90)
I have been working with 2.2 for a few days now, and I'm starting to
wonder if we should have bothered upgrading. Some of the problems
listed below have been mentioned by others. I repeat them for
completeness.
* Once I configure the HPDD to know about our Adaptec 1542 and Archive
2150s tape drive, the machine will refuse to boot. It says "Booting
The Unix System..." but it lies.
* I told mailmgmt that we have both TCP/IP and UUCP connections and
that I want to use smail, but only if an address ends in .UUCP does
it send it to smail. Otherwise, it fails with a name look-up error.
Did someone at Interactive think that all UUCP addresses end in
.UUCP? I'm not a sendmail guru so I don't know how to fix this.
* When local mail is sent, 'rmail -i username' is invoked. The mail
is properly delivered but the process never dies, so ps shows tons
of 'rmail's lying around.
* Slowness. The system seems to be noticably slower than 2.0.2 and
this bothers me. Commands that used to pop something onto the
screen immediately now pause for a second or two before doing
anything. Also noticably slower is video output. We have a
hercules adapter and whereas before when I was using 'more' or 'pg'
the next page would almost just appear in a very fast smooth scroll,
the screen now jerks as it scrolls a line at a time. I was hoping
this was just my imagination, but I now have our 2.2 machine right
next to a 2.0.2 machine, and I now know I'm not going crazy.
As far as mail is concerned, I can't figure out why vendors never seem
to be able to get it right. It's the one facility that almost every
Unix system user uses and yet it is screwed up more often than not. It
must be given a real low priority.
And slowness really bugs me. We run many voice processing applications
under 2.0.2 and I'm kind of afraid to "upgrade" them now. Maybe
someone has a reasonable explanation.
I was really looking forward to the new release, but my joy has been
severely dampened.
The facts: AT&T 6386E (Olivetti M380/XP-5) with 16 megs of 80ns RAM
and an AT&T mono display adapter. 135 meg (28ms) ESDI hard
disk.
--
Jim Gottlieb
E-Mail: <jimmy@denwa.info.com> or <jimmy@pic.ucla.edu> or <attmail!denwa!jimmy>
V-Mail: (213) 551-7702 Fax: 478-3060 The-Real-Me: 824-5454trb@haddock.ima.isc.com (Andrew Tannenbaum) (07/02/90)
I have been using beta 2.2 for several months, and it has been rock solid. Several people in my office have been using released 2.2 for a few weeks. 2.2 is at least as fast as previous Interactive UNIX systems for the 386. (I haven't checked benchmarks, but it certainly seems similar in speed to 2.0.2.) The problems that Jim Gottlieb mentions in his complaint may be attributed to configuration problems, I don't know, it's hard to say without taking a close look. We support many different hardware combinations, so it is possible to misconfigure the system by setting up boards at conflicting vectors or something. As anyone who has set up a sendmail config file knows, it's not for the faint of heart. We have many 386's running sendmail pretty cleanly, but everyone's setup will be a little different - ISC's sendmail is the latest 4.3BSD one that I know of (5.61), we haven't changed anything about the config files. If a 386 can't keep up with a scrolling screen, something is seriously wrong, and to say that it's because 2.2 is a bad release is a weak statement. That's sort of like buying a new car, tuning it up (the equivalent of the configuration process which is necessary because of the array of hardware we support), and then condemning the car model because maybe your timing or valves or spark plug gap or distributor cap is out of alignment. Again, my 2.2 beta system runs great. Gottlieb's system has problems, and I can sympathize with him, but until he understands the problems, it's not reasonable for him to shoot down 2.2 in public, and I would have preferred if I'd seen his system's problems described in a more explicit and evenhanded manner. It certainly doesn't make me feel inclined to want to help him after I see a message that says, essentially, "your system is slow, I regret the fact that I upgraded, I want everyone to know" when I've not seen or heard of such problems before and I don't think he's even sure that it's a problem with our release. Andrew Tannenbaum Interactive Cambridge, MA +1 617 661 7474
jimmy@denwa.info.com (Jim Gottlieb) (07/03/90)
After posting my recent impression of Interactive 2.2 being horribly slow, I decided to do a simple unofficial comparison between 2.2 and 2.0.2. I know this isn't scientific but it gives an idea. I started 10 yes(1) programs in the background and immediately ran a 'ps -ef'. The following is how long each machine took to finish giving the ps(1) reseults. 6386E with 4 meg of RAM and 2.0.2: 6 seconds 6386E with 16 meg of RAM and 2.2: 31 seconds Both machines were not heavily loaded at the time. In fact, I was the only user on either, and if anything the 2.0.2 machine was more loaded as it was running 24 channels of voice mail when I ran this test and still came out much quicker. Also note the RAM difference. When I tried running the voice mail on the 2.2 machine, the hard disk light stayed on constantly and it tooked 20 seconds just to get a Password: prompt after entering my login. At Interactive Hollis's suggestion, I tried boosting NPROC and NBUF with no noticable difference. Do I just have a bad copy, or is something wrong with the release? I'm hoping it's something simple like a tunable parameter is wrong, but...
tim@comcon.UUCP (Tim Brown) (07/03/90)
In article <382@denwa.uucp>, jimmy@denwa.info.com (Jim Gottlieb) writes: > > I have been working with 2.2 for a few days now, and I'm starting to > wonder if we should have bothered upgrading. Some of the problems > listed below have been mentioned by others. I repeat them for > completeness. [ HPDD stuff ] > * I told mailmgmt that we have both TCP/IP and UUCP connections and > that I want to use smail, but only if an address ends in .UUCP does > it send it to smail. Otherwise, it fails with a name look-up error. > Did someone at Interactive think that all UUCP addresses end in > .UUCP? I'm not a sendmail guru so I don't know how to fix this. > > * When local mail is sent, 'rmail -i username' is invoked. The mail > is properly delivered but the process never dies, so ps shows tons > of 'rmail's lying around. My problem is similiar but it is sendmail that won't die. > > * Slowness. The system seems to be noticably slower than 2.0.2 and > this bothers me. Commands that used to pop something onto the > screen immediately now pause for a second or two before doing > anything. Also noticably slower is video output. We have a > hercules adapter and whereas before when I was using 'more' or 'pg' > the next page would almost just appear in a very fast smooth scroll, > the screen now jerks as it scrolls a line at a time. I was hoping > this was just my imagination, but I now have our 2.2 machine right > next to a 2.0.2 machine, and I now know I'm not going crazy. > Your not crazy! I see it too. The only thing that seems "better" is that TCP seems to work now. It *really* pi---- me off when I called to ask about these things and learned of the "support" policy. I am seriously looking at ESIX like never before! Tim Brown {}!nstar!comcon!tim
tim@comcon.UUCP (Tim Brown) (07/03/90)
In article <16996@haddock.ima.isc.com>, trb@haddock.ima.isc.com (Andrew Tannenbaum) writes: > I have been using beta 2.2 for several months, and it has been rock > solid. Several people in my office have been using released 2.2 for a > few weeks. 2.2 is at least as fast as previous Interactive UNIX > systems for the 386. (I haven't checked benchmarks, but it certainly > seems similar in speed to 2.0.2.) Ok, try to see it from our point of view (at least mine). We are running along famously with 2.0.2, are putting up with some minor problems (hoping 2.2 will fix them) not needing installation support anymore. Now along comes the long awaited 2.2 and we all scramble for it, run into these problems, granted minor for the most part and we are told we now need a support contract just to get the new version installed! It is not fair, I don't care how you want to defend it. ISC is showing an attitude that seems to say, buy the product new or buy a support contract or don't talk to us. Upgrade at your own risk. You got me this time, you won't again. > > The problems that Jim Gottlieb mentions in his complaint may be > attributed to configuration problems, I don't know, it's hard to say > without taking a close look. We support many different hardware Hardware configuration isn't going to make sendmails (or rmails) refuse to die. > Again, my 2.2 beta system runs great. Gottlieb's system has problems, > and I can sympathize with him, but until he understands the problems, > it's not reasonable for him to shoot down 2.2 in public, and I would > have preferred if I'd seen his system's problems described in a more > explicit and evenhanded manner. It certainly doesn't make me feel > inclined to want to help him after I see a message that says, > essentially, "your system is slow, I regret the fact that I upgraded, I > want everyone to know" when I've not seen or heard of such problems > before and I don't think he's even sure that it's a problem with our > release. We have been talking about mail problems "evenly" for weeks, this is the first ISC has responded.... Tim Brown {}!nstar!comcon!tim
cpcahil@virtech.uucp (Conor P. Cahill) (07/03/90)
In article <384@denwa.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: >After posting my recent impression of Interactive 2.2 being horribly >slow, I decided to do a simple unofficial comparison between 2.2 and >2.0.2. I have installed 2.2 and do not see the same slowdown that you have seen. Your test is very dependent upon the scheduling priority for each of the processes (i.e. if the background jobs have been niced, ps will get a bigger portion of the cpu, and presumably finish earlier). Plus there is also a factor of how long the yes processes were running before the ps process was started. >6386E with 4 meg of RAM and 2.0.2: 6 seconds >6386E with 16 meg of RAM and 2.2: 31 seconds Another factor is what did ps have to do? (i.e. if it had to rebuild /etc/ps_data due to some change on the system, that would slow it down, OR if there were more lines of output, that would also slow it down). >Do I just have a bad copy, or is something wrong with the release? >I'm hoping it's something simple like a tunable parameter is wrong, >but... I have not seen the same problem (although I don't run on the console of my system) so I would guess that the problem is associated with the setup and/or hardware. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
rli@buster.irby.com (Buster Irby) (07/04/90)
jimmy@denwa.info.com (Jim Gottlieb) writes: >After posting my recent impression of Interactive 2.2 being horribly >slow, I decided to do a simple unofficial comparison between 2.2 and >2.0.2. >I know this isn't scientific but it gives an idea. I started 10 yes(1) >programs in the background and immediately ran a 'ps -ef'. The >following is how long each machine took to finish giving the ps(1) >reseults. >6386E with 4 meg of RAM and 2.0.2: 6 seconds >6386E with 16 meg of RAM and 2.2: 31 seconds [ more description deleted ] >Do I just have a bad copy, or is something wrong with the release? >I'm hoping it's something simple like a tunable parameter is wrong, >but... I have seen similar performance problems related to the timestamps found on several important files used by ps(1). If any of the critical files have a bad timestamp, ps will rebuild the file /etc/ps_data every time you run it, causing the system to seem verrrrry slooooow indeed. If the timestamp on any of the following files or directories is incorrect, it can cause the type of behavior you have observed. / /dev /dev/console /dev/kmem /dev/mem /dev/syscon /dev/systty /etc /etc/passwd /unix -- Buster Irby buster!rli
jackv@turnkey.tcc.com (Jack F. Vogel) (07/05/90)
In article <382@denwa.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: >* I told mailmgmt that we have both TCP/IP and UUCP connections and > that I want to use smail, but only if an address ends in .UUCP does > it send it to smail. Otherwise, it fails with a name look-up error. > Did someone at Interactive think that all UUCP addresses end in > .UUCP? I'm not a sendmail guru so I don't know how to fix this. Sendmail internally takes any uucp-style "bang" address and converts it to a .UUCP in ruleset 3 so I don't think this is the problem. I should say that I am not using the new Interactive sendmail or smail since I have the pathalias patches to sendmail such that it does the lookup itself, thus eliminating the need for smail. However I have looked over the cf files that they supplied and the problem is in how they have integrated smail usage. The rules in ruleset 0 that resolve to the uucp mailer look as follows: R<@$=V.UUCP>:$+ $#uucp$@$1$:$2 @host.UUCP:... R$+<@$=V.UUCP> $#uucp$@$2$:$1 user@host.UUCP The problem with this is that the token $=V means that only hosts in class V will match and if you look elsewhere you will find that this is those sites listed in your Systems file. Therefore if you use smail as your uucp mailer its whole purpose in life is shortcircuited, only sites you already know about are ever passed to smail! One possible way to remedy this is to change the rules to look as follows: R<@$+.UUCP>:$+ $#uucp$@$1$:$2 @host.UUCP:... R$+<@$+.UUCP> $#uucp$@$2$:$1 user@host.UUCP Now any host.UUCP will be passed to smail and let it do its job. Of course, in my opinion, putting pathalias lookup direct into sendmail is far cleaner, maybe if enough customers clammor for this we can get ISC to put in the patches and distribute an update :-}. On the matter of the name-lookup failure keep in mind that 5.61 sendmail to its core is designed to work with the nameserver, if you are running a network I would strongly suggest considering running named. Of course, the problem then is you need both a sendmail guru AND a nameserver guru :-}. >* When local mail is sent, 'rmail -i username' is invoked. The mail > is properly delivered but the process never dies, so ps shows tons > of 'rmail's lying around. Sounds to me like someone screwed with your cf file since the ones that I pulled off the distribution disks don't call rmail for local delivery, they call lmail. rmail should never be used for such a purpose it is the uucp mail delivery agent, also since supposedly the new rmail is just the BSD code I have no idea what the '-i' is, the Berkeley code recognizes no such flag. Change your local mailer definition as follows: Mlocal, P=/bin/lmail, F=lsDFMhumS, S=10, R=20, A=lmail -s $u >As far as mail is concerned, I can't figure out why vendors never seem >to be able to get it right. It's the one facility that almost every >Unix system user uses and yet it is screwed up more often than not. It >must be given a real low priority. Sorry, but I have to take issue with this sentiment. If one delivers a simple-minded mail package, say like what SCO used to provide with Xenix then it might make sense, but then we know what everybody does with that mailer, right :-}. When you provide something as flexible and sophisticated as sendmail there just is no way that it can be configured "out of the box" correctly for everyone. It is like uucp, it just has to be configured for the local site requirements and that will inevitably take some amount of knowledge on the administrators part. ISC has at least attempted to make things easier by providing 3 different prototype cf files, and BTW these are very close to what Berkeley distributes so its not like they went and broke something. Well, anyway, if I can be of further assistance on your problems send me some email and I will see what I can do. Disclaimer: These sendmail meanderings are my responsiblity, not my employer's -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
dbullis@cognos.UUCP (Dave Bullis) (07/06/90)
In article <384@denwa.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: >I know this isn't scientific but it gives an idea. I started 10 yes(1) >programs in the background and immediately ran a 'ps -ef'. The >following is how long each machine took to finish giving the ps(1) >reseults. > >6386E with 4 meg of RAM and 2.0.2: 6 seconds >6386E with 16 meg of RAM and 2.2: 31 seconds > >At Interactive Hollis's suggestion, I tried boosting NPROC and NBUF >with no noticable difference. In a previous life I was working with Convergent Technologies Mitiframes (68020, SysV.2). Normally with ran with 5-7 Megabytes. We boosted that to 15 one day and performance dropped thru the floor. Turns out the buffer cache increased so the kernel was spending all its time looking thru the cache! We cut down NBUFS and all was fine. Have you tried 2.2 on the the 4 meg machine? You could also try sar or kernel profiling. Good luck. Dave -- Dave Bullis Cognos, Inc VOICE: (613) 738-1440 3755 Riverside Dr. P.O. Box 9707 FAX: (613) 738-0002 Ottawa, Ontario, CANADA K1G 3Z4 UUCP: uunet!mitel!sce!cognos!dbullis "I didn't know the terminals were haunted. The salesman didn't tell us."
howardl@wb3ffv.ampr.org ( WB3FFV) (07/07/90)
From article <384@denwa.uucp>, by jimmy@denwa.info.com (Jim Gottlieb): > > After posting my recent impression of Interactive 2.2 being horribly > slow, I decided to do a simple unofficial comparison between 2.2 and > 2.0.2. > > 6386E with 4 meg of RAM and 2.0.2: 6 seconds > 6386E with 16 meg of RAM and 2.2: 31 seconds > > Both machines were not heavily loaded at the time. Hello, I am not sure what is happening on your machine, as I now have the Interactive 2.2 Workstation Developer installed on my DTK-386 machine. I am using a full configuration with almost every option except the 2K file system installed (Interactives FFS is much better). I just shelled out to run the above 'ps' test, and the system was under considerable load (unbatching NEWS, 3 UUCP connections, 2 users, and one X window session). The first invocation of ps took about three seconds, while a repeat call to ps took under one second. I truly believe that you must have a problem in the system setup, or possibly somthing strange going on in the hardware. I wish I could offer some suggestions to your problem, but I don't think you can say that the 2.2 release is the cause of the problem you are having. I almost forgot, this system is running with 8 meg of RAM, so it should be some middle ground based on the above information you provided... ------------------------------------------------------------------------------- Internet : howardl@wb3ffv.ampr.org | Howard D. Leadmon UUCP : wb3ffv!howardl | Advanced Business Solutions TELEX : 152252474 | 210 E. Lombard St - Suite 410 Telephone : (301)-576-8635 | Baltimore, MD 21202
baxter@zola.ics.uci.edu (Ira Baxter) (07/08/90)
In <8581@cognos.UUCP> dbullis@cognos.UUCP (Dave Bullis) writes: >In article <384@denwa.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: >>I know this isn't scientific but it gives an idea. I started 10 yes(1) >>programs in the background and immediately ran a 'ps -ef'. The >>following is how long each machine took to finish giving the ps(1) >>reseults. >> >>6386E with 4 meg of RAM and 2.0.2: 6 seconds >>6386E with 16 meg of RAM and 2.2: 31 seconds >> >>At Interactive Hollis's suggestion, I tried boosting NPROC and NBUF >>with no noticable difference. >In a previous life I was working with Convergent Technologies >Mitiframes (68020, SysV.2). >Normally with ran with 5-7 Megabytes. We boosted that to 15 >one day and performance dropped thru the floor. >Turns out the buffer cache increased so the kernel was spending >all its time looking thru the cache! We cut down NBUFS and all was fine. Looking through the cache? I thought it had hash tables to do this, so it should take negligable time (O(1)). Only systems as stupid as MSDOS have a single buffer chain :-{. It appears that 2.0.2 has a fixed number of hash buckets (NHBUF), so if you increase the memory size a lot, the *length* of hash bucket chains can start to be unreasonable. I don't have any experience with this, but it seems like raising NHBUF by a factor equal to your memory increase should keep the loading on the hash table constant; then at least "looking through the cache" would not be a problem. Why doesn't UNIX set NHBUF dynamically? Estimating the right value is trivial: NHBUF = RAMSIZE/BUFSIZE/AVGDESIREDCHAINLENGTH. Desired average chain length should be 1 or 2. -- Ira Baxter
fischer@utower.gopas.sub.org (Axel Fischer) (07/08/90)
tim@comcon.UUCP (Tim Brown) writes: >Your not crazy! I see it too. The only thing that seems "better" is >that TCP seems to work now. You're both right. 2.2 is noticeable slower then 2.02. Esspecially the screen output and my SCSI drives. Maybe it is possible to tune the SCSI drives. TCP works absolutly superb. We have had several V.32 SLIP connections for several hours and it was absolutly superb. Does anyone has tested the new NFS release? But I can live with a little slowness, if the software works. And TCP works as I have hoped for release 1.2. -Axel -- fischer@utower.gopas.sub.org / fischer@db0tui6.BITNET / fischer@tmpmbx.UUCP Class of '93 That is not dead, which can eternal lie Yet with strange aeons, even death may die.
shwake@raysnec.UUCP (Ray Shwake) (07/11/90)
In article <384@denwa.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: > >After posting my recent impression of Interactive 2.2 being horribly >slow, I decided to do a simple unofficial comparison between 2.2 and >2.0.2. But then again... I installed 2.2 last week on a system horribly limited (memory-wise) - 2 (two) MB 32-bit, 2 (two) MB 16-bit. Ran the BENCH program, source for which appeared in Unix/World, February 1989. Using the examples, one forks five processes, each of which writes 1000 512-byte blocks, or forks twenty processes, each of which writes 200 512-byte blocks. Each test ran from forks to completion in less than 15 seconds, which is somewhat faster than it ran under 2.0.2, notably faster than SCO Xenix on the same system and SCO UNIX on my office system. (What? You want numbers? You want details? Hey, this isn't going into the ACM Journal!) But then, I'm the guy who wrote an article years ago questioning whether benchmarks REALLY indicated what they claimed to indicate. The only conclusions I've drawn to date are: 1) ISC's Fast File System is a genuine enhancement; and 2) ISC 2.2 is somewhat faster than 2.0.2 in disk performance, though it takes somewhat more memory.
smarc@mas.UUCP (Marc Siegel) (07/11/90)
In article <1990Jul03.113340.17976@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > In article <384@denwa.uucp> jimmy@denwa.info.com (Jim Gottlieb) writes: [discussion of ver 2.2 slowdown probs deleted] > > >6386E with 4 meg of RAM and 2.0.2: 6 seconds > >6386E with 16 meg of RAM and 2.2: 31 seconds > > Another factor is what did ps have to do? (i.e. if it had to rebuild > /etc/ps_data due to some change on the system, that would slow it down, OR > if there were more lines of output, that would also slow it down). > On some systems, at least on AT&T 3b2 machines, /etc/ps_data is rebuilt at boot time. In /etc/rc.d I belive, a ps > /dev/null is run while the machine is coming up. I would think that the kernel configuration would affect the time needed to rebuild /etc/ps_data. Have you any major differences in kernel configuration? _ ' )--,--, | Marc Siegel / / / __. __ _ | Emtronix Data Services / / (_(_/|_/ (_(_' | Randallstown, Maryland | {uunet}!wb3ffv!mas!smarc I know, it's only rock-n-roll, | smarc@mas.wb3ffv.AMPR.ORG but I like it.
small@quiche.cs.mcgill.ca (Alain PETIT) (07/12/90)
That one will be short... Did ANYBODY in this world have make work the WD7000-FASST with ISC V2.2 from a previouly (good running) installation of V2.0.2. I already waste $50 in long-distance with peoples from Columbia Data Products, Inc. who make the driver for V2.0.2 and the answer was: "That suppose to work!" Na! That kind of answer is not good... For a proof, I have a 8bit Future Domain and spear disk, after Installation and KConfig a make a "ld errors free" brand new kernel make me a new "boot" for 2.2 and restart my installation of 2.2 the kernel start and so the installation process after 5 mins of mounting the install prgram got me in the Upgrad options but can't "get/write the disk parameters" from any of my device I plug on this "______" card... I anyone have a answer, very Very VERY Thank you! (So BTW can I have a cook list of what I need for plug my Box into this net directly... Thanks...) -- ------------------------------------------------------------------ small@quiche.cs.mcgill.ca | McGill University | Life is the primary cause for Death. Montreal, Quebec |
cpcahil@virtech.uucp (Conor P. Cahill) (07/13/90)
In article <25@mas.UUCP> smarc@mas.UUCP (Marc Siegel) writes: > >On some systems, at least on AT&T 3b2 machines, /etc/ps_data is rebuilt >at boot time. In /etc/rc.d I belive, a ps > /dev/null is run while >the machine is coming up. I would think that the kernel configuration >would affect the time needed to rebuild /etc/ps_data. Have you any >major differences in kernel configuration? /etc/ps_data is rebuilt anytime one of the following events occur: /unix is modified /etc/passwd is modified /dev is modified /etc/ps_data is missing or empty The kernel configuration will not make a measureable difference to the time it takes to run. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
robert@towers.UUCP (Robert Hoquim) (07/13/90)
fischer@utower.gopas.sub.org (Axel Fischer) writes: >TCP works absolutely superb. We have had several V.32 SLIP connections >for several hours and it was absolutely superb. Could you or someone please post a SLIP login script and any other associated files. I do have a "marginal" script running but since the creation script in sysadm is broken when adding a SLIP driver as the second connection I don't think I have everything set up right. I would appreciate any information that you can shed on this (perhaps even a fixed sysadm script for 2.2) >Does anyone has tested the new NFS release? I have it running and had no failures at all for over 3 weeks. Even when a connected system is rebooted the NFS mount is right there when it comes back up. Seems almost error free. I have not yet received the yellow pages (that I suggest everyone to send for since it is a slick part of NFS in a small or large network and it is FREE!) and being able to set groups and ownership Network wide is a real plus. >But I can live with a little slowness, if the software works. >And TCP works as I have hoped for release 1.2. I saw a speed decrease due to the RAM demand being higher, but adding another 8 megs of ram and a little kernel tuning brought performance right back up again. Make sure your not in a constant swap situation since 2.2 uses more ram than was needed under 2.02. -- Robert Hoquim Small Systems Specialists (317)-255-6807 8500 N. Meridian ..!nstar!towers!robert Indianapolis, IN. 46260