mike@ai.etl.army.mil (Mike McDonnell) (11/11/89)
Please excuse me if some of these questions have been answered here before, but I just became aware of the incredible prices I can get a 3B2/600 for under an Air Force contract and I need some information about the computer that the contract literature did not provide. Here they are: 1. What is the (approximate of course) MIPS rating of the 3B2/600 with a 24MHz CPU board? What is the MFLOPS? 2. What is the "industry standard bus" used? 3. RFS comes with the computer. Is NFS available from somewhere? 4. Can programmers get at the other processors that you get with the multiprocessor board or is this just used invisibly by the kernel to do I/O or some such? It would be nice to try out some parallel programming. 5. Do the internet programs "named" and "egp" or their equivalents run on the 3B2? If they do, where do I get them? I don't want to go back to copying host tables. 6. Is anybody working on porting the FSF C compiler, gcc, to the 3B2? What about g++? 7. Anybody compiled the X Window System public distribution (X11.3) on the 3B2? 8. Finally, are there archives for comp.sys.att where I can look stuff up for myself? Thanks for taking the time to answer. These computers look pretty good but I have to know how much of our current environment (VAX, 4.3BSD, X, Arpanet) I can retain if I buy one. -- Mike McDonnell at the U.S. Army Engineer Topographic Laboratories, Bldg. 2592 Fort Belvoir, VA 22060-5546 TEL:(202)355-2716 NET: mike@etl.army.mil
woods@eci386.uucp (Greg A. Woods) (11/15/89)
In article <367@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: > > 3. RFS comes with the computer. Is NFS available from somewhere? Why would you want it? :-) > 6. Is anybody working on porting the FSF C compiler, gcc, to the 3B2? > What about g++? I am. I am also VERY interested in hearing from anyone else who may be embarking on a similar effort. I'm not very far along yet, as the time I have available to this task is limited, and I do already have a C compiler for the 3B2! At this point I'm still reading the processor manual, though I do have most of the sources for GCC and friends, and have started reading the GCC manual as well. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
rwa@cs.AthabascaU.CA (Ross Alexander) (11/22/89)
In article <1989Nov15.155346.25197@eci386.uucp> woods@eci386.uucp (Greg A. Woods) writes: >In article <367@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: >> 3. RFS comes with the computer. Is NFS available from somewhere? >Why would you want it? :-) I see the smiley, so you're somewhat off the hook. Somewhat. Could you name vendors of RFS for (oh, let's see now...) Vax/VMS, SunOS (any version at all), CDC NOS, or Apple Macintosh? Dec Ultrix? HP/Apollo? IBM AIX or even (shudder) VM/CMS? I see some real interoperability problems here :-), not everyone is prepared to chuck their current hardware after picking up a 3b2/<nnn>. Of course, there's always BNS (uucp to the unwashed :-). I admit that many of these machines don't run un*x. But as far as I know, they will all run NFS (not always as servers, mind, and corrections welcome.) RFS is no speed daemon :-) either, and has real problems when the server or client crashes. I ran one for a while, and every time we lost a node, I had to shut it down on all the others, reboot the deader, and then start it up again all around the net. And Now, the "Truth In Flaming" Section!! ========================================= I _do_ like the way RFS allows sharing periperals like tape drives. That's really handy. RFS does much more correctly support un*x filesystem semantics. It does locking without funky locking and status daemons (lockd and statd). It doesn't hand little suprise gotcha's to the sysadmin (howz'about some filenames with '/' in the the _path components_ :-). It's just a pain in a multivendor environment, that's all. In a purely homogenous environment RFS is Not A Bad Thing. r
les@chinet.chi.il.us (Leslie Mikesell) (11/23/89)
In article <1262@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: [re: RFS] >I see some real interoperability >problems here :-), not everyone is prepared to chuck their current >hardware after picking up a 3b2/<nnn>. [...] >RFS is no speed daemon :-) either, and has real >problems when the server or client crashes. I ran one for a while, >and every time we lost a node, I had to shut it down on all the >others, reboot the deader, and then start it up again all around the >net. If your machines crash often enough to be a problem maybe you *should* replace them... Anyway, you should not have to restart RFS because any single node goes away. As long as the primary name server is running, you should be able to reboot any other machine and the automatic adv's and mounts will take care of themselves. If you designate one or more secondary nameservers you can also reboot the primary and have it pick up the currently advertised names by doing an "rfadmin -p" at the secondary. Without a secondary namserver you would still only have to re-advertise everything after rebooting the primary. Currently active links between other machines would not be affected. You do lose any processes that happen to be using an RFS directory that goes away. >I _do_ like the way RFS allows sharing periperals like tape drives. >That's really handy. Actually I think this is a bad idea compared to providing server programs that know how to handle both the network and device efficiently. There are also problems with ioctl()'s to devices when the CPU's are different. >RFS does much more correctly support un*x >filesystem semantics. It does locking without funky locking and >status daemons (lockd and statd). This is indeed nice, as is the ability to make a FIFO that appears on multiple machines and works with programs that think it is an ordinary file. Les Mikesell les@chinet.chi.il.us
scj@casux4.uucp (Steve Johnson) (11/24/89)
In article <1989Nov22.162738.10433@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: ... >If your machines crash often enough to be a problem maybe you *should* >replace them... > Except that when WE run RFS between machines that COEXIST with MANY other (non-AT&T, heterogenous) machines on the same ethernet LAN, *crashes* of our machines are often related to RFS crashes. It seems that packets NOT destined for RFS or even our boxes *somehow* cripple our (nearly new, current software) 3B2/(600,700,1000*) machines into panic'ing (stream resource related panics). Tuning is not an issue (for instance, /etc/crash shows no failures for strstat, no other errors either, either from crash or other daemons and logs). >Anyway, you should not have to restart RFS because any single node >goes away. Agreed, you *should* not have to restart. But, on the same LAN as mentioned above, *with* a secondary properly defined, our entire RFS network often comes down, HARD, when the primary server RFS crashes. Additionally, ( serious, but we are :-) with RFS OVERALL) we often have to REBOOT the primary server after an RFS crash to gain any RFS sanity. Tests done in *isolation* from the rest of our normal LAN neighbors show *near complete* RFS stability. We believe that RFS *just cannot cope* with the MANY protocols and other network traffic on the LAN. Storms are sometimes, but not always an issue here. I really do like the overall stability of AT&T 3B2 products, both hardware and software, but in case some offense is taken, I'm putting on asbestos shorts! ;-) Bye!
woods@eci386.uucp (Greg A. Woods) (11/24/89)
In article <1262@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: > In article <1989Nov15.155346.25197@eci386.uucp> woods@eci386.uucp (Greg A. Woods) writes: > >In article <367@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: > >> 3. RFS comes with the computer. Is NFS available from somewhere? > >Why would you want it? :-) > > I see the smiley, so you're somewhat off the hook. Somewhat. :-) :-) :-) One reason I joke about this is, as you say, RFS is not readily available, and has known problems in heterogeneous environments. However, from the less pragmatic side, I would like to see RFS marketed, improved, and used, because of the tremendous advantages this would bring. We all complain about NFS, but does anyone *DO* anything about it? Not that I've seen. Most of the good distributed filesystems are still in the research phase. At least with RFS, we have some very useful features available to a reasonably large domain of users (don't forget the 386 and friends). Now if only we quit bitching about it to each other, and forced our vendors to make it usable, we'd get somewhere. I certainly don't want to have to wait for Plan 9 to reach the marketplace before we get elegant, and coherent, distributed systems. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
woods@eci386.uucp (Greg A. Woods) (11/24/89)
In article <1989Nov22.162738.10433@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <1262@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: > [re: RFS] > >I _do_ like the way RFS allows sharing periperals like tape drives. > >That's really handy. > > Actually I think this is a bad idea compared to providing server programs > that know how to handle both the network and device efficiently. There > are also problems with ioctl()'s to devices when the CPU's are different. Of course you can't share complex peripherals with different systems, without being *VERY* careful, and without making various changes. I think that if you take into account the ioctl data is defined by the device driver, the CPU, the implementation of C, and such, not just the device itself; you can generate ioctl requests in which the data has the right number of bits, and the right order of bytes, etc. You won't be able to use a curses programme, or a tape rewind programme, compiled and working on a DEC3100 with a device mounted from a MIPS (assuming both are running RFS :-), but you might be able to write a separate ioctl interface for such programmes which will talk to foreign device drivers, and you should even be able to do it in such a way that it is user-transparent (find out which filesystems are remote, stat the device, see if it is remotely mounted, and if it is, where, and then pick an interface). So, in the end you will probably want to provide network services which allow access to shared devices. Still, in a homogeneous environment it is nice to be able to mount the other guy's /dev! As a very silly example: it makes more sense to rlogin to another machine than to disable your tty, and then have the other guy rmount and run getty on it. However this example isn't so silly if you want to be able to balance the load on your machines by transparently shuffling users between them without getting into a wiring tangle. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
rwa@cs.AthabascaU.CA (Ross Alexander) (11/27/89)
les@chinet.chi.il.us (Leslie Mikesell) writes: >If your machines crash often enough to be a problem maybe you *should* >replace them... I'd like to replace TransAlta Power (my power utility). Can't afford UPS's for 35+ geographically dispersed machines, I'm afraid, and we see enough hits on the power lines to make life interesting. I mean 1 to 2 second outages. Ross
les@chinet.chi.il.us (Leslie Mikesell) (11/29/89)
In article <18366@bellcore.bellcore.com> scj@navaho.cc.bellcore.com (Steve Johnson) writes: >It seems that packets NOT >destined for RFS or even our boxes *somehow* cripple our (nearly new, >current software) 3B2/(600,700,1000*) machines into panic'ing (stream >resource related panics). Tuning is not an issue (for instance, /etc/crash >shows no failures for strstat, no other errors either, either from crash >or other daemons and logs). Interesting. We used to have the same problem when we had a mix of Starlan 1.0 and 3.2 (URP/OSI) machines on the same net. It seemed to happen most often when we had the lan manager running (it watched both protocols) and particularly when the 3B2's would access their tape drives. My guess is that the length of a packet is interpreted incorrectly due to the mix of protocols and the kernel buffer pool is overrun. >>Anyway, you should not have to restart RFS because any single node >>goes away. >Agreed, you *should* not have to restart. But, on the same LAN as >mentioned above, *with* a secondary properly defined, our entire RFS >network often comes down, HARD, when the primary server RFS crashes. >Additionally, ( serious, but we are :-) with RFS OVERALL) we often have >to REBOOT the primary server after an RFS crash to gain any RFS sanity. I saw something like that a few times under 1.0 starlan on the 3b2's, mostly triggered by someone disconnecting a wire and leaving an unterminated run. Since installing 3.2 and changing to the newer network hub units we haven't had that sort of problem (several months now). Rebooting the primary server isn't too serious if you have set up a secondary machiner. >Tests done in *isolation* from the rest of our normal LAN neighbors show >*near complete* RFS stability. We believe that RFS *just cannot cope* >with the MANY protocols and other network traffic on the LAN. Storms >are sometimes, but not always an issue here. I suspect that this relates more to the network drivers than RFS. >I really do like the overall stability of AT&T 3B2 products, both >hardware and software, but in case some offense is taken, I'm >putting on asbestos shorts! ;-) I'd like to seem more discussion of these kinds of real-world problems out in the open. Why should anyone be offended? Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (11/29/89)
In article <1279@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: >I'd like to replace TransAlta Power (my power utility). Can't afford UPS's >for 35+ geographically dispersed machines, I'm afraid, and we see enough >hits on the power lines to make life interesting. I mean 1 to 2 second >outages. I'm inclined to consider UPS's as a part of the cost of the machine, having had to replace several expensive system boards due to power fluctuations before buying them. The data integrity is just gravy... Les Mikesell les@chinet.chi.il.us
mvadh@cbnews.ATT.COM (andrew.d.hay) (11/30/89)
In article <1989Nov29.052142.2137@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
"I'm inclined to consider UPS's as a part of the cost of the machine, having
"had to replace several expensive system boards due to power fluctuations
"before buying them. The data integrity is just gravy...
i'm surprised (well, a little, anyway) that small machines -- which i
define as machines designed to be used outside a controlled
environment -- don't have power conditioning and limited battery
holdup *built*in*.
the battery would only have to last for a few minutes -- long enough to
catch sigpwr and shut down. (perhaps init s would be the fastest way...)
this would be redundant if you have a real ups, but it would still give
you a little extra insurance against system problems.
--
Andrew Hay +------------------------------------------------------+
42 Authority | Zaphod Beeblebrox is now appearing in |
AT&T-BL Ward Hill MA | "No S*x Please, We're Amoeboid Cingatularians" |
a.d.hay@att.com +------------------------------------------------------+les@chinet.chi.il.us (Leslie Mikesell) (12/01/89)
In article <11826@cbnews.ATT.COM> mvadh@cbnews.ATT.COM (andrew.d.hay,54242,wi,1d007,508 374 5484) writes: >i'm surprised (well, a little, anyway) that small machines -- which i >define as machines designed to be used outside a controlled >environment -- don't have power conditioning and limited battery >holdup *built*in*. Well, then they wouldn't be "small" machines anymore unless.... >the battery would only have to last for a few minutes -- long enough to >catch sigpwr and shut down. (perhaps init s would be the fastest way...) >this would be redundant if you have a real ups, but it would still give >you a little extra insurance against system problems. As a builtin for emergencies only, it might just park the disk heads and support only the RAM. A tiny battery could do this for hours and then pick up exactly where things left off. Some of the Toshiba laptop PC's have a feature like that to maintain work in progress with minimal battery drain. Under unix, some things might be confused by skipping an interval of time, though, and you would lose most of the terminal connections anyway. Les Mikesell les@chinet.chi.il.us
flinton@eagle.wesleyan.edu (12/02/89)
So: In article <1989Nov29.052142.2137@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > > I'm inclined to consider UPS's as a part of the cost of the machine ... > OK, I'm convinced; any reliable, lo-budget recommendations? (to protect UNIX-pc) -- Fred [E.J. Linton, Wesleyan U. Math. Dept, Middletown, CT 06457] 203 776 2210 <flinton@eagle.Wesleyan.EDU> or <flinton@WESLEYAN.bitnet> or <attmail!fejlinton>