INFO-VAX Fri, 18 Apr 2008 Volume 2008 : Issue 217 Contents: Re: Chip head stuff: AMD's proposed 12 core... Re: Chip head stuff: AMD's proposed 12 core... Chip head stuff: Intel's Nehalem CPU RE: DEC 3000/400 firmware update Re: DEC 3000/400 firmware update Re: DEC 3000/400 firmware update Re: Mozilla (et al.) v. TCPIP FTP server Re: Mozilla (et al.) v. TCPIP FTP server New Communigate Pro V5.2.2 OpenVMS release, itanium only? Re: OT: IBM looking at Macintosh Re: Watching P2 memory usage on an Alpha ---------------------------------------------------------------------- Date: Fri, 18 Apr 2008 04:20:19 -0700 (PDT) From: Neil Rieck Subject: Re: Chip head stuff: AMD's proposed 12 core... Message-ID: <40784035-c4da-45df-b6cb-aeb03f33a7d8@a70g2000hsh.googlegroups.com> On Apr 18, 1:11=A0am, JF Mezei wrote: > Neil Rieck wrote: > > Chip head stuff: AMD's proposed 12 core. > > I would think that this Tukwilla thing, supposed to come out "soon" will > give IA64 its last claim to performance for a short period of time > before being overtaken by the 8086 once and for all. IA64 will be > blindsighted by upcoming 8086 projects and it is likely, in my opinion, > that Intel will announce end of the line for IA64 betwen Tukwila and its > successor (whats the name again ?) > > Big question is whether they will actually deliver the successor to > Tukwila, or just deliver speed boosts on the existing chip. I was pleasantly surprised to see the Tukila (quad-core Itanium) announcement at IPF and am pleased that Intel hasn=92t (yet) abandoned the chip. People forget that more Itanium platforms are now in commercial use than the total number of Alpha platforms ever produced. If Intel doesn=92t ever retire Itanium, then maybe son-of-Tukwila will eventually merge with the daughter-of-Nehalem. Of course this is just wishful thinking on my part. On a related note, I feel the need to point out the following: My employer=92s company was fully entrenched in VAX platforms when Alpha was announced in the early 1990s and we thought we=92d never get access to the new technology. But less than 7 years later (my employer is incredibly cheap), Alpha systems where rolling in the door. Alpha hardware and software cost much less than VAX. Alpha hardware used much less power and required almost no air conditioning. It was almost like you couldn=92t afford to not go to Alpha. The only problem with this logic is that desktop systems also became incredibly inexpensive so it was still difficult to get the financial people to open their wallets. So I=92m going to go out on a limb and state that I expect to see Itanium systems rolling in the door sometime in 2009 (my employer is still incredibly cheap). If these Itanium systems were as inexpensive as Penryn (Core2 Quad) we=92d have them now. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html http://www3.sympatico.ca/n.rieck/links/openvms_demos.html ------------------------------ Date: Fri, 18 Apr 2008 06:38:17 -0700 (PDT) From: AEF Subject: Re: Chip head stuff: AMD's proposed 12 core... Message-ID: <7dfb510d-de58-4e85-aa5b-7aff9b443a55@u69g2000hse.googlegroups.com> On Apr 17, 9:34 pm, Neil Rieck wrote: > Chip head stuff: AMD's proposed 12 core. > > Although no firm date has been given, this announcement gives us a > glimse of a possible "George Jetson" future. What does this have to do with the Jetsons? > > http://www.dailytech.com/Dodecacore+The+Megahertz+Race+is+Now+Officia... > > > > A twin-die Istanbul processor could enable 12 cores in a single > package. Each of these cores will communicate to each other via the > now-enabled HT3.0 interconnect on the processor. > > The rabbit hole gets deeper. Since each of these processors will > contain a dual-channel memory controller, a single-core can emulate > quad-channel memory functions by accessing the other dual-channel > memory controller on the same socket. This move is likely a > preemptive strike against Intel's Nehalem tri-channel memory > controller. > > Motherboard manufacturers claim Shanghai and its many-core derivatives > will be backwards compatible with existing Socket 1207 motherboards. > However, processor-to-processor communication will downgrade to lower > HyperTransport frequencies on these older motherboards. The newest > 1207+ motherboards will officially support the HyperTransport 3.0 > frequencies. > > > > Neil Rieck > Kitchener/Waterloo/Cambridge, > Ontario, Canada.http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Fri, 18 Apr 2008 03:50:43 -0700 (PDT) From: Neil Rieck Subject: Chip head stuff: Intel's Nehalem CPU Message-ID: <796d0253-2406-4c61-a2bf-61792bb23827@f63g2000hsf.googlegroups.com> What you need to know about Intel's Nehalem CPU http://arstechnica.com/articles/paedia/cpu/what-you-need-to-know-about-nehalem.ars In some ways, Nehalem is Intel's most significant processor since the Pentium 4, insofar as it signifies a major shift for the company's x86 strategy. The ill-fated Pentium 4 was a relatively radical design conceived with clockspeed in mind. Nehalem, in contrast, is a more progressive evolution of Intel's existing, mobile-oriented Core 2 products; all of its changes are made with a view to exploiting the large amounts of parallelism that Moore's Law affords at the 45nm process node and to taking advantage of QPI's bandwidth. Peers at my place of employment have told me that this chip contains many technolgies developed by the DEC Alpha engineers hired by Intel after HPQ's Alphacide. I have found nothing online to support this claim but maybe someone out there knows the truth and will post it here. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Fri, 18 Apr 2008 11:06:27 +0000 From: "Main, Kerry" Subject: RE: DEC 3000/400 firmware update Message-ID: > -----Original Message----- > From: alexandre.laguejacques@gmail.com > [mailto:alexandre.laguejacques@gmail.com] > Sent: April 17, 2008 10:40 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: DEC 3000/400 firmware update > > Hello Robert, > > You will of course notice that it was to your message that I had made > reference in my previous post. Thank you for documenting your > experience! > > I didn't know that one could force the install CD to accept the > present firmware with that syntax. (My VMS experience is limited to > the old dial up account that I had back in the mid 90s so I've never > dealt with the SRM.) I will definitely try that before attacking the > bootp fiasco, which is only a fiasco because my present *nix setup > would require taking a server off line to put it in place. > Alex, I have the old DEC 3000 firmware CD's and maint guides in PDF format. Contact me offline and we can discuss how to get you a copy of what you need. Btw - one of my home Alpha lab servers is a DEC 3000 running VMS V8.3 with no issues. :-) 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: 18 Apr 2008 08:37:49 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEC 3000/400 firmware update Message-ID: In article <021784e5-ae61-4ecd-bfb8-07c40ea10306@c65g2000hsa.googlegroups.com>, alexandre.laguejacques@gmail.com writes: > > I've found the equivalent of the old Digital FTP site at HP: > http://h18002.www1.hp.com/alphaserver/firmware/readmes/dec3000.html > The files provided by HP only cover the update via floppy, BOOTP or > MOP. Funny -- I'm not aware of a single DEC 3000 that has a floppy > drive. The floppy is not an option and the BOOTP or MOP procedures > require a working installation of OpenVMS or Tru64. Odd, I've always updated my 3000 via CD. BOOTP and MOP should work equally well no matter what OS is serving them. Lots of UNIX, of course, can server BOOTP. IIRC there's a MOP server for Linux. I'll look around and see if I can find my last CD for the 3000 series. ------------------------------ Date: Fri, 18 Apr 2008 18:42:23 +0100 From: "Maciej W. Rozycki" Subject: Re: DEC 3000/400 firmware update Message-ID: On Fri, 18 Apr 2008, Bob Koehler wrote: > Odd, I've always updated my 3000 via CD. BOOTP and MOP should > work equally well no matter what OS is serving them. Lots of > UNIX, of course, can server BOOTP. IIRC there's a MOP server > for Linux. And I'll be happy to help (up to patching up sources to fix bugs) if anyone decides to use this server and it fails for whatever reason. I use this piece of software (running on an x86 PC) to boot my DECstations routinely and I have successfully tried it with a VAXstation 4000/90 as well. Maciej ------------------------------ Date: 18 Apr 2008 08:34:04 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Mozilla (et al.) v. TCPIP FTP server Message-ID: In article <89ec2aa2-ed5f-4cbd-88e6-4e71283e934f@d45g2000hsc.googlegroups.com>, Carl Karcher writes: > > The real 'fix' is for hp to add a 'unix compatibility mode' to it's > ftp server. Enabled by a logical name perhaps. No GUI FTP client can > read the listings so it's going to have problems manipulating the > files. You can't expect every GUI FTP client to have special code to > deal with ODS5, but you could expect HP to provide a 'unix' compatible > ftp server so all those GUI FTP clients out there work again. Nope. I expect all those clients out there to start following the RFC, or maybe an update to the RFC (not likely), instead of all the vendors having to make up for those who don't follow the RFC. There's nothing going on with file names on an ODS-5 disk which isn't handled by the RFC. ------------------------------ Date: Fri, 18 Apr 2008 07:56:32 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Mozilla (et al.) v. TCPIP FTP server Message-ID: <08041807563198_2020CE0A@antinode.org> From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > In article <89ec2aa2-ed5f-4cbd-88e6-4e71283e934f@d45g2000hsc.googlegroups.com>, Carl Karcher writes: > > > > The real 'fix' is for hp to add a 'unix compatibility mode' to it's > > ftp server. Enabled by a logical name perhaps. No GUI FTP client can > > read the listings so it's going to have problems manipulating the > > files. You can't expect every GUI FTP client to have special code to > > deal with ODS5, but you could expect HP to provide a 'unix' compatible > > ftp server so all those GUI FTP clients out there work again. > > Nope. I expect all those clients out there to start following the > RFC, or maybe an update to the RFC (not likely), instead of all the > vendors having to make up for those who don't follow the RFC. And any such "fix" is unlikely to help anyone who isn't using the next version of TCPIP. > There's nothing going on with file names on an ODS-5 disk which isn't > handled by the RFC. Oh, really? So, the RFC expects the FTP client to do caret removal on the names supplied by the FTP server? This seems to me unlikely. Have you ever used a TCPIP FTP server with extended file names on an ODS5 disk? (Apparently not. It's lamer than you might think possible.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 18 Apr 2008 08:35:19 -0700 (PDT) From: Rich Jordan Subject: New Communigate Pro V5.2.2 OpenVMS release, itanium only? Message-ID: Just got this on the digest; Communigate Pro V5.2.2 has been released. For the first time there is a 5.2 build for VMS, but the letter only showed Itanium, not Alpha. They did release this version for Tru-64 on Alpha though. I haven't written to ask about the Alpha build yet, but the available OpenVMS alpha kit is still at V5.1.4. Stalker has not responded to previous questions about newer VMS builds. OpenVMS - Itanium So if you're on an itanic, this is good news. Rich ------------------------------ Date: 18 Apr 2008 08:40:53 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: OT: IBM looking at Macintosh Message-ID: <$yqIL4$wmzAi@eisner.encompasserve.org> In article <66q19aF2ks2anU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > > What could possibly make IBM want to do anything at all with VMS? IBM knows good stuff when they see it. And they know how to market. ------------------------------ Date: 18 Apr 2008 10:30:41 -0400 From: brooks@cuebid.zko.hp.nospam (Rob Brooks) Subject: Re: Watching P2 memory usage on an Alpha Message-ID: <7$E8EDq6XJDz@cuebid.zko.hp.com> VMS is Virus Free writes: > $ write sys$output f$getjpi(the_programs_pid,"p2_first_free_va_64") > > This works fine until it gets to FFFFFFFF then it rolls over to > 00000000. I know the program that it's monitoring is working because > its page file quota continues to slowly decrement even after this > overflow. > > Any thoughts or ideas? The problem is that DCL does not do 64-bit math, and that value is being returned as an integer. I would not expect to see DCL enhanced to support 64-bit integers. -- Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ End of INFO-VAX 2008.217 ************************