INFO-VAX Wed, 03 Dec 2008 Volume 2008 : Issue 646 Contents: Re: Anyone want a ride on the SS Itanic? Re: Anyone want a ride on the SS Itanic? Re: Anyone want a ride on the SS Itanic? Re: gnutar and tape drive Re: gnutar and tape drive Re: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Re: It that VAX 11/750 in the background? Re: It that VAX 11/750 in the background? Re: It that VAX 11/750 in the background? RE: Multicore Is Bad News For Supercomputers Re: Multicore Is Bad News For Supercomputers Re: Multicore Is Bad News For Supercomputers RE: Multicore Is Bad News For Supercomputers ---------------------------------------------------------------------- Date: Wed, 3 Dec 2008 02:17:55 -0500 From: "William Webb" Subject: Re: Anyone want a ride on the SS Itanic? Message-ID: <8660a3a10812022317m72e5338csdb539659735e76a9@mail.gmail.com> ------=_Part_648_31227274.1228288675521 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 26, 2008 at 4:08 PM, FrankS wrote: > On Nov 26, 2:07 pm, Hein RMS van den Heuvel > wrote: > > Also, the MP gives TELNET access to the console. > > While I have the infrastructure for serial line consoles, telnet is > > proferred for me. > > DECserver 90 series, 700, and 900 (and possible others) all support > reverse Telnet. You could pick one up on eBay (or Island Computer), > connect up all the serial lines, and then telnet to any console. You > will need DNAS software, but early versions are available on some > older condist kits. > Don't forget about the Lantronics one-porters. WWWebb ------=_Part_648_31227274.1228288675521 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Nov 26, 2008 at 4:08 PM, FrankS <sapienza@noesys.com> wrote:
On Nov 26, 2:07 pm, Hein RMS van den Heuvel
<heinvandenheu...@gmail.com> wrote:
> Also, the MP gives TELNET access to the console.
> While I have the infrastructure for serial line consoles, telnet is
> proferred for me.

DECserver 90 series, 700, and 900 (and possible others) all support
reverse Telnet.  You could pick one up on eBay (or Island Computer),
connect up all the serial lines, and then telnet to any console.  You
will need DNAS software, but early versions are available on some
older condist kits.

Don't forget about the Lantronics one-porters.
 
WWWebb
------=_Part_648_31227274.1228288675521-- ------------------------------ Date: Wed, 3 Dec 2008 04:19:43 -0800 (PST) From: FrankS Subject: Re: Anyone want a ride on the SS Itanic? Message-ID: <5a8c59c6-4aad-4fd6-be9d-1108101badd0@j39g2000yqn.googlegroups.com> On Dec 3, 12:16=A0am, Alan Frisbie wrote: > 1. Quadrics QM500-A Network adapter, which I am sure is not > =A0 =A0 supported by VMS. =A0 I am also sure that it will turn up on > =A0 =A0 ebay before too long. =A0 :-) Yeah, mine too. Not sure what kind of demand there will be, but I don't need it. > I got a good deal on the HP DVD-ROM drive for it, but would > like to get a burner. =A0 Does anyone have any suggestions > for a suitable drive? HP Slimline CDRW/DVD Combo A6986-62001 A6986-64001 It's in the supported drives list for the RX2600. I bought one on eBay for $60. It's a Teac DW-224E. > Now all I need is a fibre channel card and I'm all set! HP QLA2342 Dual Port 2Gbp/s 133MHz PCI-X Fiber HBA Also got one of these on eBay. $75. Hmmm... I can't find the HP part number, but it's also on the supported device list for OpenVMS/RX2600. ------------------------------ Date: Wed, 3 Dec 2008 16:41:57 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Anyone want a ride on the SS Itanic? Message-ID: Glen Herrmannsfeldt writes: >Alan Frisbie wrote: >(snip) >> I just received mine (the version without the DVD but with >> the management processor). It had two PCI cards included: I got mine, the one with the DVD but no management card. >> 1. Quadrics QM500-A Network adapter, which I am sure is not >> supported by VMS. I am also sure that it will turn up on >> ebay before too long. :-) I'm not sure what this is. Some sort of star cluster (not VMS Cluster) interconnect, from what I've found googling. >The picture looks like there is built in 10/100 and a >separate port for gigabit ethernet. There is. They show up on VMS as EIA0: and EWA0:. I believe EWA0: is the gigabit port. >> 2. A6829A (LSI Logic 22915-HP) 2-port ultra 160 SCSI The description of the ones with the management card don't mention this. The one without the management card does, and mine has one. It appears that VMS doesn't support this card, but it does recognize it. >It also shows a built-in SCSI port with a "do not use" >sticker over it. Mine came without the sticker so I plugged it into a BA356 box, temporarily, until a drive that works in the sled (already won on Ebay) arrives. It works. I'll get a second drive later. ------------------------------ Date: Wed, 03 Dec 2008 06:53:11 GMT From: "John E. Malmberg" Subject: Re: gnutar and tape drive Message-ID: kimmo.berghall@gmail.com wrote: > Hello, > > Is it possible to use gnutar from GNV to create archive to tape? Now I > get > > $ gtar cvf /$tape JEM-AXPVMS-GNUTAR-V0119--1.PCSI$COMPRESSED > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual > address=000000000000 > 0000, PC=FFFFFFFF809A8960, PS=0000001B I will need to chase down that access violation, but it may be a while before I will add it to the list of bugs I have discovered since the kit was made. In general because of speed issues, and because around me, I have not used tapes in years, I have not tried to connect directly to a tape. The source is available in the kit if you want to try to build it your self. Additional notes are in the PORTING_TO_VMS notes conference on the Encompasserve.org system. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Wed, 03 Dec 2008 09:15:14 +0000 From: "R.A.Omond" Subject: Re: gnutar and tape drive Message-ID: <49364e24$0$90264$14726298@news.sunsite.dk> John E. Malmberg wrote: > kimmo.berghall@gmail.com wrote: > >> Is it possible to use gnutar from GNV to create archive to tape? Now I >> get >> >> $ gtar cvf /$tape JEM-AXPVMS-GNUTAR-V0119--1.PCSI$COMPRESSED >> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual >> address=0000000000000000, PC=FFFFFFFF809A8960, PS=0000001B > > I will need to chase down that access violation, but it may be a while > before I will add it to the list of bugs I have discovered since the > kit was made. > > In general because of speed issues, and because around me, I have not > used tapes in years, I have not tried to connect directly to a tape. Not that it should make a *huge* difference (connecting directly to tape), but for such situations Jur's LM (Logical Magtape) is simply *perfect*. See: http://www.digiater.nl/ ------------------------------ Date: Wed, 03 Dec 2008 10:45:34 -0500 From: jls Subject: Re: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Message-ID: On Sun, 30 Nov 2008 17:13:04 +0000 (UTC), helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote: >In article , helbig@astro.multiCLOTHESvax.de >(Phillip Helbig---remove CLOTHES to reply) writes: >Here's the answer: > >The system-disk shadow set on the node I was working on was still >mounted on the other nodes in the cluster, since I had forgotten to >dismount it there. As expected, it went into mount verification on >those nodes. When the node I was working on came back up, there was >only one member in the system-disk shadow set, whereas the other nodes >remembered that there were two. Thus, an inconsistency. > >(Interesting is that a couple of weeks ago I mentioned that, after an >unplanned dirty reboot, a system-disk shadow set (as it happens, on the >same node I was working on today) WAS inconsistent in the cluster, >showing two members on a two nodes and just one on another. Apparently >this was a by-product of the dirty reboot and, in more or less normal >circumstances, such inconsistency is avoided. A better error message >would be helpful, though, and/or an OPCOM from the nodes which detect >the inconsistency.) Which is exactly why setting vaxcluster to 0 is the wrong thing to do. Maintaining cluster membership is important to insure that you don't scribble on disks that other cluster members are also scribbling on. ------------------------------ Date: 3 Dec 2008 08:39:36 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: It that VAX 11/750 in the background? Message-ID: In article , paul_hansford@o2.co.uk writes: > See the you tube link from The UK (and ?) Renault Megane ad. > http://uk.youtube.com/watch?v=rTthvxpzNDM > 'I would never get a computer' 11-13 seconds into the ad. > P I think so. But I can't tell if that's a tell-tale TU58 cartridge in the middle or just the |d|i|g|i|t|a|l| logo. Looks like an MV II mounted in the rack next to it, with a TK50 on it's left end. Looks like some kind of disk platter canister on top of the center cabinet behind an acoustic couple modem. Looks like DEC 9-track drives in the background on that shot. Other than those two cabinets and the tape drives behind them, everything else looks non-DEC. But it's hard to be sure. In any case those two are clearly DEC cabinets with DEC stuff in them. ------------------------------ Date: Wed, 3 Dec 2008 07:15:37 -0800 (PST) From: MetaEd Subject: Re: It that VAX 11/750 in the background? Message-ID: <1311e7f9-29bb-4bfe-aaa5-d8d89e360116@x14g2000yqk.googlegroups.com> No, I'm just happy to see you. ------------------------------ Date: Wed, 03 Dec 2008 10:30:15 -0500 From: JF Mezei Subject: Re: It that VAX 11/750 in the background? Message-ID: <0022834b$0$12274$c3e8da3@news.astraweb.com> Michael Austin wrote: >> http://uk.youtube.com/watch?v=rTthvxpzNDM > In the center it looks like a MVII or 11/73 or 11/83 with the RA disk on > top and the one to the left does look like the 11/750... On the left, could it be a 730 ? Doesn't a 750 have a "Blue" band on the top of the cabinet ? In terms of the cabinet directly behind the guy, it is NOT a microvax II. It lacks the princess-lea ears on both sides of the cabinet (the air vents), the separator bar below the top RA drive has some gizmo on its left which the all mighty Microvax II doesn'T have, and the top ba23 rack is definitely not an MVII. The botton BA23 is also not an MVII. For the MVIIs, the bottom unit has a control panel on the right side, and the removable panels on the left. On the picture, it lacks the control panel. ------------------------------ Date: Wed, 3 Dec 2008 12:57:36 +0000 From: "Main, Kerry" Subject: RE: Multicore Is Bad News For Supercomputers Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593EDB45EC3F@GVW1158EXB.americas.hpqcorp.net> > -----Original Message----- > From: Keith Parris [mailto:keithparris_nospam@yahoo.com] > Sent: December 2, 2008 5:23 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Multicore Is Bad News For Supercomputers > > Main, Kerry wrote: > > Its not only multi-cores that is the issue, but rather new buses like > Intel's > > new QuickPath (formerly called CSI). > > > > The new X86/Itanium bus architecture is NUMA based and that is a new > paradigm > > that for very high performance requires accessing local memory much > more than > > remote memory. Hence, the OS and App's need to be aware and be able > to maximize > > perf with this architecture. > > It's NUMA, but not NUMA like you remember from the Wildire (GS-320, > GS-160, GS-80) series, which had such severe performance problems > because of the 3X difference in latency between local (QBB) and remote > (across-QBB) memory accesses. > > Intel's QuickPath is NUMA of the EV7 flavor, which had remote access > times only 1.something times as slow as local memory access, and where > the slowest (farthest) memory access was still faster than the fastest > memory access in a QBB-based design. G'day Keith .. Re: new NUMA .. yeah, I know it is much different than the original NUMA designs from the early wildfire days, but if the OS and App are not NUMA aware, then for Supercomputer performance, it may make a difference for those who want to take advantage of the every cycle. Since memory/cache is local to each CPU, local cache references will be faster than going over the interconnect (granted, it is faster than the older buses) to a remote CPU, not finding it in cache and then going to main memory (or disk). If the App and OS are not NUMA aware (e.g. scheduling of processes and where they run), then all sorts of cache thrashing could occur. This will be a concern for supercomputing, but potentially also for other high perf app environments as well. Is this not correct? Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Wed, 3 Dec 2008 06:05:05 -0700 From: "Michael D. Ober" Subject: Re: Multicore Is Bad News For Supercomputers Message-ID: "Main, Kerry" wrote in message news:9D02E14BC0A2AE43A5D16A4CD8EC5A593EDB45EC3F@GVW1158EXB.americas.hpqcorp.net... > -----Original Message----- > From: Keith Parris [mailto:keithparris_nospam@yahoo.com] > Sent: December 2, 2008 5:23 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Multicore Is Bad News For Supercomputers > > Main, Kerry wrote: > > Its not only multi-cores that is the issue, but rather new buses like > Intel's > > new QuickPath (formerly called CSI). > > > > The new X86/Itanium bus architecture is NUMA based and that is a new > paradigm > > that for very high performance requires accessing local memory much > more than > > remote memory. Hence, the OS and App's need to be aware and be able > to maximize > > perf with this architecture. > > It's NUMA, but not NUMA like you remember from the Wildire (GS-320, > GS-160, GS-80) series, which had such severe performance problems > because of the 3X difference in latency between local (QBB) and remote > (across-QBB) memory accesses. > > Intel's QuickPath is NUMA of the EV7 flavor, which had remote access > times only 1.something times as slow as local memory access, and where > the slowest (farthest) memory access was still faster than the fastest > memory access in a QBB-based design. G'day Keith .. Re: new NUMA .. yeah, I know it is much different than the original NUMA designs from the early wildfire days, but if the OS and App are not NUMA aware, then for Supercomputer performance, it may make a difference for those who want to take advantage of the every cycle. Since memory/cache is local to each CPU, local cache references will be faster than going over the interconnect (granted, it is faster than the older buses) to a remote CPU, not finding it in cache and then going to main memory (or disk). If the App and OS are not NUMA aware (e.g. scheduling of processes and where they run), then all sorts of cache thrashing could occur. This will be a concern for supercomputing, but potentially also for other high perf app environments as well. Is this not correct? Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. From the article, NUMA won't work for the types of problems their looking at. One of the statements in the article was that memory references could be from several processors away, which definitely rules out NUMA. Mike. ------------------------------ Date: Wed, 03 Dec 2008 09:01:11 -0500 From: JF Mezei Subject: Re: Multicore Is Bad News For Supercomputers Message-ID: <00229a9d$0$4030$c3e8da3@news.astraweb.com> Main, Kerry wrote: > NUMA designs from the early wildfire days, but if the OS and App are > not NUMA aware, then for Supercomputer performance, it may make a > difference for those who want to take advantage of the every cycle. While VMS may have had some NUMA-aware logic back when it was on Alpha, is this capability latent in the IA64 version of VMS ? And is that capability relevant to the "new" NUMA that CSI will bring ? Or will they just re-use concepts and a bit fo code used for the Alpha-Wildfire and essentially build a new NUMA-awareness for VMS ? Also, what happens when you have a NUMA hardware that runs HU-UX upon which VMS will run as a hosted/vistualised instance ? Will VMS still know about NUMA-ness of the hardware deep down below ? ------------------------------ Date: Wed, 3 Dec 2008 14:16:38 +0000 From: "Main, Kerry" Subject: RE: Multicore Is Bad News For Supercomputers Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593EDB45EC98@GVW1158EXB.americas.hpqcorp.net> > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: December 3, 2008 9:01 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Multicore Is Bad News For Supercomputers > > Main, Kerry wrote: > > > NUMA designs from the early wildfire days, but if the OS and App are > > not NUMA aware, then for Supercomputer performance, it may make a > > difference for those who want to take advantage of the every cycle. > > > While VMS may have had some NUMA-aware logic back when it was on Alpha, > is this capability latent in the IA64 version of VMS ? And is that > capability relevant to the "new" NUMA that CSI will bring ? Or will > they > just re-use concepts and a bit fo code used for the Alpha-Wildfire and > essentially build a new NUMA-awareness for VMS ? > I have no idea how future designs will be implemented, but since the IA code base is pretty much the same as Alpha, I would assume there is not a whole lot of differences with the current code. > > Also, what happens when you have a NUMA hardware that runs HU-UX upon > which VMS will run as a hosted/vistualised instance ? Will VMS still > know about NUMA-ness of the hardware deep down below ? No one moves an OS instance to a VM where there is high performance requirements. VM's (on all platforms) are used to consolidate low-med workloads, so I doubt this will be an issue. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ End of INFO-VAX 2008.646 ************************