1 INFO-VAX	Sun, 01 Dec 2002	Volume 2002 : Issue 663       Contents:, Re: Alternatives to "DEC LMF PAK GEN V1.3" ?3 Re: Cracking OpenVMS passwords with John the Ripper  Re: Endianity of Itanium Re: Endianity of Itanium Re: Endianity of Itanium Re: Endianity of Itanium Re: Endianity of Itanium Re: Endianity of Itanium) Re: Independent Consultants + OpenVMS.org ) Re: Independent Consultants + OpenVMS.org ) Re: Independent Consultants + OpenVMS.org ) Re: Independent Consultants + OpenVMS.org 3 RE: Information Needed -Cross Compiler Availability 3 Re: Information Needed -Cross Compiler Availability 3 RE: Information Needed -Cross Compiler Availability 3 RE: Information Needed -Cross Compiler Availability ; Re: NY LUG meeting - Disaster Tolerant Technologies from HP % Re: poor Gigabit Ethernet performance & Re: Question about V7.2-2 distribution Re: SRM for multiboot  Re: SRM for multiboot   F ----------------------------------------------------------------------  % Date: Sat, 30 Nov 2002 12:56:55 +0100 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> 5 Subject: Re: Alternatives to "DEC LMF PAK GEN V1.3" ? ' Message-ID: <3DE8A787.3B2CD548@aaa.com>   = Yes, VEST'ing or using some free Windows VAX emulator was two  of my other options...  : Well, I think things are much clearer now and I'll talk to: my client to find a solution. `The main goal is to get rid of the VAX 4000...   Thanks all !   Jan-Erik Sderholm.    John Vottero wrote:  > 5 > "Jan-Erik Sderholm" <aaa@aaa.com> wrote in message # > news:3DE74387.90E52A69@aaa.com...  > > Hi. 4 > > A client is running "DEC LMF PAK GEN V1.3" on an: > > old VAX 4000. What are the alternatives in this case ?, > > They have a number of Alpha VMS systems.+ > > Have anyone tried to VEST the PAK GEN ?  > > 5 > > Or is there a native Alpha version of this tool ?  > >  > I > That specific tool isn't available on Alpha.  However, if you're a DSPP J > member you can get a PAKGEN license and generate license PAKs with newerN > versions of OpenVMS (I think 7.2 or higher).  If you really want to continueL > using the old PAKGEN stuff, you can VEST it and it works.  I'm not sure of > the legal issues involved.   ------------------------------  # Date: Sun, 01 Dec 2002 01:33:43 GMT 1 From: Michael Austin <maustin@firstdbasource.com> < Subject: Re: Cracking OpenVMS passwords with John the Ripper2 Message-ID: <3DE9669D.42958F22@firstdbasource.com>   JF Mezei wrote:  >  > Shane Smith wrote: > > D > > True. However, access to that file would also be restricted in aI > > properly locked down system, so it's still of limited use to hackers. H > > They'd have to get in and get privs to get the file, and the program3 > > would be fairly pointless once you'd done that.  > I > But if you have a system manager as an accomplice, he hand send you the J > sysuaf.dat, you crack the boss's password and can then have "fun" on the8 > system, undetected and without any intrusion attempts. > O > This is why it is very important to have full trust in anyone with privileges  > in your system.   C If you have said accomplice, it is even easier using something like " SETUSER. or other similar methods.   --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com    ------------------------------  % Date: Sat, 30 Nov 2002 14:38:47 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch> ! Subject: Re: Endianity of Itanium 5 Message-ID: <3DE8BF67.812CD3EC@swissonline.delete.ch>    JF Mezei wrote:  > # > VAXman-, @SendSpamHere.ORG wrote: ) > > Itanium has any endium you preferium.  > F > Do bi chips have any "preference" for either endium in terms of core > design/performance ? > O > In other words, would alpha perform just as well in either endian, or was the O > chip/architecture tuned to perform better with little endian since all the oS ' > that run on Alpha are little endian ?  > L > Similarly, is the bloated IA64 performing better as big endian (for HP) or0 > little endian (for the rest of the world) ????  G At a recent OpenVMS Techical Seminar I heard that Itanium is any-endian G for data but little endian for instructions.  You will be able to set a 4 flag bit in your PCB to say which way the data goes.  G The catch is that VMS system service routines are written to a standard = endian-ness and you may have to call a routine to change your > process-specific endianness before you call the system service  H In reality I think we will all pretty much adopt the same endian-ness asF OpenVMS System Service routines but should we need to, we will be able$ to change around for "foreign" data.     cheers   John McLean   B PS.  I also heard that the first VMS boot on Itanium should happenH within this month.  ...And I heard that VMS engineers and support people, are much happier to be owned by HP name  :-)   ------------------------------  % Date: Sat, 30 Nov 2002 16:48:54 -0500 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>! Subject: Re: Endianity of Itanium / Message-ID: <3DE93245.4B5CE655@vl.videotron.ca>    John McLean wrote:I > At a recent OpenVMS Techical Seminar I heard that Itanium is any-endian I > for data but little endian for instructions.  You will be able to set a 6 > flag bit in your PCB to say which way the data goes.    K Interesting, so the compilers and linkers that run on HP-UX will have to do F neat tricks to genereate little-endian code. Does this mean that HP-UXN compilers will have to be significantly different that HP might not see fit to# use the Intel compilers for HP-UX ?    ------------------------------  $ Date: Sun, 1 Dec 2002 00:48:02 +0100% From: "Jakob Erber" <erberj@yahoo.de> ! Subject: Re: Endianity of Itanium , Message-ID: <3de9348d$1@news.swissonline.ch>  1 > It has the same endianity as Alpha - bi-endian.   J Sorry for my ignorance, but how does this work? Is it OS denpendend? Would2 VMS on Itanium be little endian? What about Tru64?   best regards   Jakob    ------------------------------  # Date: Sat, 30 Nov 2002 22:25:56 GMT / From: "John Reagan" <johnrreagan@earthlink.net> ! Subject: Re: Endianity of Itanium E Message-ID: <UVaG9.9742$ta5.1131128@newsread2.prod.itd.earthlink.net>   L As others have mentioned, Itanium is bi-endian.  The actual instructions areH allocated in little-endian order.  The architecture has a user-writeableJ register that has a big/little endian flag.  OpenVMS will require that theK flag be in little-endian position.  If you try to flip the bit (you'll have K to write in Itanium Assembly to access that register - no compiler builtins L are being provided to set it), you are no longer running OpenVMS and I'm not sure what will happen.... ;-)    --   John Reagan ' Compaq Pascal/{A|I}MACRO Project Leader  Hewlett-Packard Company    ------------------------------  # Date: Sun, 01 Dec 2002 00:06:20 GMT " From:   VAXman-  @SendSpamHere.ORG! Subject: Re: Endianity of Itanium 0 Message-ID: <00A17C2C.0A7A2BA2@SendSpamHere.ORG>  w In article <UVaG9.9742$ta5.1131128@newsread2.prod.itd.earthlink.net>, "John Reagan" <johnrreagan@earthlink.net> writes: M >As others have mentioned, Itanium is bi-endian.  The actual instructions are I >allocated in little-endian order.  The architecture has a user-writeable K >register that has a big/little endian flag.  OpenVMS will require that the L >flag be in little-endian position.  If you try to flip the bit (you'll haveL >to write in Itanium Assembly to access that register - no compiler builtinsM >are being provided to set it), you are no longer running OpenVMS and I'm not  >sure what will happen.... ;-) >  >--  >John Reagan( >Compaq Pascal/{A|I}MACRO Project Leader >Hewlett-Packard Company  K Let's hope that its access (the endian bit) is protected in some fashion.      --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Sat, 30 Nov 2002 21:17:44 -0500 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>! Subject: Re: Endianity of Itanium / Message-ID: <3DE97136.86393AAC@vl.videotron.ca>   M > >register that has a big/little endian flag.  OpenVMS will require that the N > >flag be in little-endian position.  If you try to flip the bit (you'll haveN > >to write in Itanium Assembly to access that register - no compiler builtinsO > >are being provided to set it), you are no longer running OpenVMS and I'm not   > >sure what will happen.... ;-)  N Humm, let me see, if you switch that bit, wouldn't it become "SMVnepO" on a 64, bit machine, and "SMV" on a 32 bit machine ?  L Where's your sense of adventure ? Think of all the fun that folks could have. switching that bit :-) :-) :-) :-) ;-) :-) :-)   ------------------------------  # Date: Sat, 30 Nov 2002 14:43:23 GMT # From: "John Smith" <a@nonymous.com> 2 Subject: Re: Independent Consultants + OpenVMS.orgJ Message-ID: <f84G9.188442$YSz1.77626@news01.bloor.is.net.cable.rogers.com>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3DE84969.B12CEBED@fsi.net...  > B > Give the public a solid, reasonably safe-feeling car with enoughJ > acceleration to get out of its own way and you might see that trend that" > shift a bit - MAYBE, just maybe.  H If people (generally) quit 'super-sizing' their meals and stuffing theirH faces with junk food, maybe that smaller car with 140HP would seem peppy' enough, and they could fit into it too.       B > > Well, while we like to make fun of BG, a recent radio show wasF > > discussing what private individuals have donated the most of theirJ > > personal wealth to charities and community services. BG was first with > > $22B > , > Is that a current-year number or lifetime?    L Given that inflation has been pretty low since BG started his donations, theK inflation adjusted aggregate is not far off $20B since the inception of his K donations. He's on-record as saying that he plans to give most of his money E away and not leave his kids with tons of money at the end (relatively  speaking of course).    E > > and the next individual was not even close - came in at something L > > like $6B. And apparently, BG has stated that there will be a huge amount# > > more when he decides to retire.  > I > Ah. Another Rockefeller or Carnegie: robber-baron in life who built his I > emire on the backs of under-paid slaves, immortal philanthropist in the  > eyes of posterity.  L To some extent one can agree with that point of view. On the other, Gates isG giving individuals and corporations what they seem to want, at somewhat I reasonable prices. Rockefeller and Carnegie got rich by providing society K something it needed too. Yes there were excesses along the way, and no they K didn't treat their workers with much altruism. But don't forget, there were ! no income taxes back then either.   G As another example, Wrigley got rich selling something that has no real G value, so why single out Gates? Sure a lot of the products MS sells are J crap, but they are good enough for most users and uses. Same for Ford, GM,K Chrysler. Go pick on them too. Probably 5,000-10,000 deaths per year in the H US are caused by automobile design decisions made for the sake of savingK $0.37 on one part and $1.23 on another part. I'm not sure that the same can H be said for MS products, even though they are fraught with faulty design decisions and bugs.    ------------------------------  % Date: Sat, 30 Nov 2002 19:18:47 -0500 * From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Independent Consultants + OpenVMS.org2 Message-ID: <35CdnSKZDer9yHSgXTWcpQ@metrocast.net>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3DE84969.B12CEBED@fsi.net...  > "Main, Kerry" wrote:   ...   ; > > One can certainly not blame other countries for wanting 2 > > what the Western world has had for many years. > H > Wanting? No, can't balem them. Seeing as their due? For what? Years ofB > poverty? Are we less deserving for what our forebearers endured?  # Your viewpoint is seriously warped.   E I don't know of anyone in those other countries seeing the jobs we're I exporting as 'their due':  they're just welcoming with open arms the jobs L that *American companies* are *deciding* to export because it makes economic sense to do so.   K As for ourselves, we're in no way any *more* 'deserving' of those jobs than @ are those to whom they are moving (many of whose forebears had aK considerably worse time of it than many of ours did, by the way):  if we're H willing to compete for them, fine; if not, bye-bye.  The fact that we'veL been exceptionally fortunate in the past (due in large part to no particularJ effort of our own, just to the possession of a rich land-mass from which aL higher-than-average standard of living was relatively easy to eke out) in noL way entitles us to continuing that standard of living now that conditions noJ longer conspire to support it:  if we still want it, then we'll have to be> willing to scrabble for it somewhat harder than we're used to.   - bill   ------------------------------   Date: 30 Nov 2002 21:16:55 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: Independent Consultants + OpenVMS.org5 Message-ID: <asb9s6$psp3d$1@ID-135708.news.dfncis.de>   J In article <f84G9.188442$YSz1.77626@news01.bloor.is.net.cable.rogers.com>,& 	"John Smith" <a@nonymous.com> writes: > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3DE84969.B12CEBED@fsi.net...  >>C >> Give the public a solid, reasonably safe-feeling car with enough K >> acceleration to get out of its own way and you might see that trend that # >> shift a bit - MAYBE, just maybe.  > J > If people (generally) quit 'super-sizing' their meals and stuffing theirJ > faces with junk food, maybe that smaller car with 140HP would seem peppy) > enough, and they could fit into it too.   H My MGB and Triumph are both quite peppy enough for me.  But that doesn'tI eliminate the need for the Jeep. (Hint:  The place I work has a high % of H resident students and as a result the administration figures if they canI get to class, so can the employees.  Work has only been canceled twice in J the 17+ years I have been there, both at the order of local government who/ banned all non-emergency traffic on the roads.)    >  >  > C >> > Well, while we like to make fun of BG, a recent radio show was G >> > discussing what private individuals have donated the most of their K >> > personal wealth to charities and community services. BG was first with 	 >> > $22B  >>- >> Is that a current-year number or lifetime?  >  > N > Given that inflation has been pretty low since BG started his donations, theM > inflation adjusted aggregate is not far off $20B since the inception of his 
 > donations.    G Humph.  At least Scrooge mended his ways before he tried to buy his way  into heaven.  M >            He's on-record as saying that he plans to give most of his money G > away and not leave his kids with tons of money at the end (relatively  > speaking of course).  F An interesting attitude for someone who was given his first million on the day he was born.   bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Sat, 30 Nov 2002 22:21:37 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 2 Subject: Re: Independent Consultants + OpenVMS.org& Message-ID: <3DE98E51.9062631@fsi.net>   John Smith wrote:  > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3DE84969.B12CEBED@fsi.net...  > > D > > Give the public a solid, reasonably safe-feeling car with enoughL > > acceleration to get out of its own way and you might see that trend that$ > > shift a bit - MAYBE, just maybe. > J > If people (generally) quit 'super-sizing' their meals and stuffing theirJ > faces with junk food, maybe that smaller car with 140HP would seem peppy) > enough, and they could fit into it too.   H "Peppy" is not the issue. Able to merge safely from 0 - 70+ in less thanF 1/4-mile is the issue: the damned ramp signals reduce the accelerationC distance from in excess of a 1/4 mile to less than 100 feet in some G places here in Metro Chicago. Nothing short of a super-fuel dragster is ? capable of such acceleration, regardless of the passenger load.   F ...and yes, these roads are actually posted 55. Travel at that pace atE your own peril - they'll pass you like you're standing still. S--t, I G drive 70 most places on these roads and I'm still damn near the slowest  thing on the road at times...    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 30 Nov 2002 12:19:47 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) < Subject: RE: Information Needed -Cross Compiler Availability3 Message-ID: <ju0lBlILfKHH@eisner.encompasserve.org>   ~ In article <BE56C50EA024184DAF48F0B9A47F5CF4023D9981@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> writes: > Larry, > $ >>> > Domain : Embedded Systems  <<< > C > So, embedded systems are not susceptible to the virus of the day?   A Since they typically do not run commercial operating systems, no.   ? My comment, however, was directed to your remard about Netbeans A on VMS.  Netbeans relates to Java as I understand it, so I do not @ see any way it is related to embedded systems, even ignoring the? fact that embedded systems often have realtime requirements for > which Java is unsuited, due to the unpredictability of garbage collection if nothing else.    ------------------------------  % Date: Sat, 30 Nov 2002 20:52:52 +0100 6 From: Arne =?ISO-8859-1?Q?Vajh=F8j?= <arne@vajhoej.dk>< Subject: Re: Information Needed -Cross Compiler Availability) Message-ID: <3DE91714.3030202@vajhoej.dk>    Larry Kilgallen wrote:   > In article <BE56C50EA024184DAF48F0B9A47F5CF4023D9981@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> writes:C >>So, embedded systems are not susceptible to the virus of the day?  > C > Since they typically do not run commercial operating systems, no.  > A > My comment, however, was directed to your remard about Netbeans C > on VMS.  Netbeans relates to Java as I understand it, so I do not B > see any way it is related to embedded systems, even ignoring theA > fact that embedded systems often have realtime requirements for @ > which Java is unsuited, due to the unpredictability of garbage > collection if nothing else.   B As far as I know, then Java are quite popular in embedded systems.  < Either they can live with GC or they use J2ME, which (I have been told) do not use GC.    Arne   ------------------------------  # Date: Sat, 30 Nov 2002 21:51:18 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)< Subject: RE: Information Needed -Cross Compiler Availability4 Message-ID: <qpaG9.198396$up.2009042@news.chello.at>   In article <00A17BF7.AA10D4B7@SSRL.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes: K >NetBeans is an Integrated Development Environment which, while written in  M >Java, is not limited to supporting Java.  At the same symposium you recently K >attended, the NetBeans presentation made it clear that on VMS it supported L >C, C++, and Java.  It's also extensible (and open source, for that matter),L >so you could make it support whatever cross-compiled language you meant to # >develop for your embedded systems.   ' Nice discussion but it misses the case.   I As I interpret the original posting, the cross-compiled language is fixed 3 (PL/M-86 for 80186) and is not under "development". # The code on the embedded system is.   K And the question was who knows a platform with a PLM86 cross compiler on it @ which is more up to date (and not on its dead row) than VAX/VMS.  O I personally don't count JavaBeans as a suitable answer to this orig. question.    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  # Date: Sat, 30 Nov 2002 20:51:29 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")< Subject: RE: Information Needed -Cross Compiler Availability6 Message-ID: <00A17BF7.AA10D4B7@SSRL.SLAC.STANFORD.EDU>  c In article <ju0lBlILfKHH@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  >In article <BE56C50EA024184DAF48F0B9A47F5CF4023D9981@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> writes: 	 >> Larry,  >>  % >>>> > Domain : Embedded Systems  <<<  >>  D >> So, embedded systems are not susceptible to the virus of the day? > B >Since they typically do not run commercial operating systems, no. > @ >My comment, however, was directed to your remard about NetbeansB >on VMS.  Netbeans relates to Java as I understand it, so I do notA >see any way it is related to embedded systems, even ignoring the @ >fact that embedded systems often have realtime requirements for? >which Java is unsuited, due to the unpredictability of garbage  >collection if nothing else.  J NetBeans is an Integrated Development Environment which, while written in L Java, is not limited to supporting Java.  At the same symposium you recentlyJ attended, the NetBeans presentation made it clear that on VMS it supportedK C, C++, and Java.  It's also extensible (and open source, for that matter), K so you could make it support whatever cross-compiled language you meant to  " develop for your embedded systems.  O However, it doesn't do that out of the box, so Kerry's suggestion still puzzles 6 me.  NetBeans doesn't have a cross-compiler component.   -- Alan     O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------    Date: 30 Nov 2002 19:39:03 -0800+ From: spamdump@mccready.com (Gary McCready) D Subject: Re: NY LUG meeting - Disaster Tolerant Technologies from HP< Message-ID: <ffd79a6c.0211301939.6b8543c@posting.google.com>  u "John Smith" <a@nonymous.com> wrote in message news:<X_RF9.213099$MGm1.62608@news02.bloor.is.net.cable.rogers.com>... : > "Gary McCready" <spamdump@mccready.com> wrote in message9 > news:ffd79a6c.0211291313.3b9d27ad@posting.google.com... G > > Well, yes, being able to broadcast the presentation is a good idea, * > > but it does have some requirements.... > >  > > .... <SNIP!>  ...   N > Hell, HP may even get some VMS marketing ideas out of these events, not thatK > they'd do anything with them though. The obtuse way of looking at this is N > that if for something as low-cost and relatively easy to do as what has beenM > suggested in one form or another is NOT done, then there is no hope for VMS  > at HP. >  > John    D Well, if some of the fine folks at HP are following this thread, andC it sounds interesting,..., they can check out be the below links. I F have not heard of the company, but if they are legit, it looks like it can be done for about $1000   ( http://www.camcd.com/Rentals.htm#Webcast   --Gary   ------------------------------   Date: 30 Nov 2002 20:59:48 GMT& From: Rick Jones <foo@bar.baz.invalid>. Subject: Re: poor Gigabit Ethernet performance* Message-ID: <asb8s4$5u3$5@web1.cup.hp.com>  ' Rudolf Wingert <win@fom.fgan.de> wrote: C > Sorry, but I do not understand what you wrote. TTCP is not my own E > test tool. It is a tool from HP. Other then DTSEND looks it it like D > a non optimized tool. Also the user do not use optimized tools. HeA > uses normal system utilities and stamdard file open. So the the < > result with the copy is the best test for the performance.  B HP does provide a ttcp for VMS, however, ttcp is a "public domain"A tool with a history that goes back at least 15 years if not more.   + What Matt is driving at is related to this:   D One of the many limits to the performance of a TCP connection is theD window size divided by the round-trip time. This is often written as W/RTT.    F TCP is a flow-controled protocol. A sending TCP may not send more thanD one window's worth of data before it must await a window update from@ the remote TCP. The fastest that window update can arrive is oneC Round-Trip-Tim (RTT), hence the limit of W/RTT.  When W/RTT is less D than the bitrate of the link, that is as fast as the connection will go.   D Notice that the expression W/RTT has _no_ component that relates (atA least directly) to the bitrate of the link. It is all a matter of # Window size and round-trip latency.   C All TCP/IP stacks have a default window size (sometimes also called D the default socket buffer size, the two are generally but not alwaysE related). These defaults have their origins in the "way back" and may F or may not suffice for contemporary very high-speed data links such as Gigabit Ethernet.   D Based on the numbers you have posted, the default socket buffer sizeE for the revision of VMS you are using seems be sufficiently large for 9 a single TCP connection to saturate a Fast Ethernet link.   E That same default socket buffer size may not be sufficient to achieve 0 peak performance across a Gigabit Ethernet link.  < The options Matt has suggested are to accomplish two things:  ? 1) have ttcp use a larger socket buffer (and thus window) size.    and   C 2) enable the stack to allow that larger socket buffer/window size.   ; This should enable ttcp and the TCP stack to have more data E outstanding at one time - increasing the "W" in W/RTT.  When ttcp was @ compiled and release for VMS, it was probably before gigabit wasE prevalent, so it was not compiled with larger defaults. That ttcp and A other test tools even have command-line options to set the socket A buffer sizes indicates that their author(s) knew that one setting C would not work for every situation, so the command line options are C there to allow the user(s) to experiment and tune. (There are times E when one cah have a socket buffer and TCP window that are too large.)   F Netperf is the same as ttcp in this regard. Unless one uses the -s andD -S options, netperf will use the systems' default socket buffer (andF thus window) sizes. The defaults on most TCP/IP stacks are still smallB enough that while they work just fine for Fast Ethernet and below,E they may not allow a single TCP connection to achieve link-rate (or a ! very high rate) over GbE.  W/RTT.   0 > Now a few facts: there are no network errors.   D Good. It only takes a few TCP retransmissions to ruin your whole day :)  E > Also it is possible to get 77% of the FastEthernet performance with C > the COPY utility. DTSEND meassures 95% for FastEthernet, but only F > 27% for GigabitEthernet. I did measure the disk read (COPY CONT128MB; > NL:) for that disk, which I did use for the test. Result: E > 25.2MB/s. If Gigabit would tick right, I should be able to transfer  > 25.2MB/s to the NL: device.   C That one of your tests - DTSEND - that is DECnet yes? - went faster B than Fast Ethernet implies that at least the adaptor is capable ofC faster than Fast Ethernet speeds.  However, even DECnet is going to F have some form of flow-control. Perhaps not a window size exactly likeC TCPs, but perhaps something more like NFS - say a maximum number of D disc requests outstanding at a time or somesuch. The "W/RTT" sort ofF calculation would still hold there as well. I've no idea if there is aA way to get a larger number of oustanding requests with the DTSEND  test.   E After window size performance limitations are dealt with and W/RTT is > now large enough there are of course a host of other potential limitations to examine.   B In and of itself, Gigabit Ethernet technology does nothing to makeA data transfer easier for a host.  From a technology standpoint it C takes just as many CPU cycles to transfer a packet across a Gigabit F Ethernet network as it did to transfer a packet across a Fast Ethernet$ network, or even a 10Base-T network.  D Now, there may be some specific aspects of the _implementation_ of aF specific Gigabit Ethernet _NIC_ that could make it more efficient thanF an older Fast Ethernet NIC, but those would be incremental things, not order of magnitude things.  C So, if the test across Fast Ethernet consumed say 50% of the CPU on A the system(s), the best one might expect from a switch to Gigabit D Ethernet would be <=2X Fast Ethernet. The bottleneck has simply beenF transfered from the network (in the case of maxing-out a FastEthernet) to the CPU.   D If the straight disc COPY test consumes some non-trivial fraction ofF the CPU to achieve that 22.5 MB/s, those of course are CPU cycles that@ are unavailable to the TCP stack, which may or may then take the system to CPU saturation.   D The sum of the CPU cycles required to read from the disc at 22.5MB/sD plus the sum of the CPU cycles to transfer that data through TCP hasC to be less than the total CPU cycles available or the CPU becomes a  bottleneck.   E > In case of this I don't like to use JUMBO frames. May be you can me B > explain why JUMBO frames won't make the same problem (not enaugh5 > buffer space on the switch --> destroyed pakets -->  > retransmissions).   A If the egress (exit) port on the switch is also Gigabit, then the E experience you had with Fast Ethernet being switched to 10BaseT would F not apply directly. In that case, the large speed mismatch between theB different ports could (and in your case does seem to have) lead to4 buffer overruns in the switch and thus lost packets.  @ However, if the network includes non-JF aware components you mayA indeed not be able to use JF in production. So while a quick test F between two JF-capable systems may help show better what the limits of= the NIC and I/O subsystem are, JF indeed may not be usable in  production.   D > At last, I did made a call to TSC Muenchen. They did say, that the% > DEGPA-SA do have a bad performance    E I'm going to guess that the DEGPA-SA is a NIC based on the old Alteon D Tigon2 chipset. The HP 9000's (HP-UX systems) also have an older GbEF NIC based on that chipset, and indeed, there are some situations where> that NIC cannot achieve link-rate (and some where it can :).    @ The reasons have to do with the arcane trivia of things like theF number of buffers used by the networking stack to hold the contents ofF a given packet and its headers, the overhead in the NIC for setting-upF a DMA transaction, and the memory and I/O bus latencies in the system.  C These overheads in the NIC are particularly troublesome with a 1500 D byte MTU (aka standard Ethernet frame size) and more than one buffer@ per packet. However, they are not so troublesome as to limit theD performance of TCP (again, after TCP window sizes are dealt with) to only FastEthernet speeds.   B If one _is_ able and willing to use Jumbo Frames, the larger frame> size helps compensate for those overheads quite well - the DMAE transactions across the bus become larger and so the set-up overheads F are a smaller component of overall time. It also has the added benefitF of allowing the transfer of a given quantity of data in fewer packets,F which will directly reduce the CPU overhead and if that then takes theA system from being CPU saturated to no longer being CPU saturated, - there can be a direct increase in throughput.   E > and that there is a new generation of GigabitEthernet adapters. But D > test within HP did measure with this new one only a performance of	 > 57MB/s.   ? Did TSC Muenchen happen to give the particulars of the testing?   D > I am realy interisted to tune the system, but I do need time to do > so.   B We look forward to hearing about the results of increasing the TCP7 window sizes, and the CPU utilization during the tests.    happy benchmarking,   
 rick jones http://www.netperf.org/  --  G oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...u   ------------------------------  % Date: Sat, 30 Nov 2002 16:50:52 -0500V0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>/ Subject: Re: Question about V7.2-2 distributiont/ Message-ID: <3DE932BB.8F488194@vl.videotron.ca>n  M One thing that puzzles me. I was under the impression that dash releases werenK to be available for download, and that only point releases would require CD H distribution. With such a policy, I should have been able to download anL upgrade from V7.2 to V7.2-1 and V7.2-2. But on VAX, I don't think I ever saw
 such a beast.   I Was this policy ever in place but abandonned ? Or are those kita actually * available  and I just haven't found them ?   ------------------------------    Date: 30 Nov 2002 16:05:45 -0800! From: soterro@yahoo.com (Soterro)a Subject: Re: SRM for multiboot= Message-ID: <d5440555.0211301605.69953ba2@posting.google.com>   ` "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3DE844D3.DFEC1C1A@fsi.net>...> > ...or do you need to automate the boot-into-alt-os function? > F > You can send sequences from the host to Reflection to make it invoke  F Thanks for your answer, but I must tell I didn't understand it... WhatA I needed is: let's say I'm remotely connected to my home computernB which runs _VMS_ (not open.) I want to reboot it in _Tru64_. I canC reboot it, but as long I'm not home in front of the console to type A the ostype and boot device, it will boot again in VMS. I needed aeF proggy to write the new stuff into nvram so when it reboots it reboots into the next os.   ; I'm quite curious what will happen to the date/time format.0  * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/   D Polls, free licenses, available code... and I thought _I_ was livingF in the past. Let's get real, the biguns in Dec/Compaq/HP do not give a? shit on whatever opinions the users have. Fast money talks, andb  research never makes fast money.   Sorine   ------------------------------  % Date: Sat, 30 Nov 2002 22:31:04 -0600f1 From: "David J. Dachtera" <djesys.nospam@fsi.net>N Subject: Re: SRM for multiboot' Message-ID: <3DE99088.64393142@fsi.net>s   Soterro wrote: > b > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3DE844D3.DFEC1C1A@fsi.net>...@ > > ...or do you need to automate the boot-into-alt-os function? > >iH > > You can send sequences from the host to Reflection to make it invoke > H > Thanks for your answer, but I must tell I didn't understand it... WhatC > I needed is: let's say I'm remotely connected to my home computersD > which runs _VMS_ (not open.) I want to reboot it in _Tru64_. I canE > reboot it, but as long I'm not home in front of the console to typeeC > the ostype and boot device, it will boot again in VMS. I needed amH > proggy to write the new stuff into nvram so when it reboots it reboots > into the next os.n  G What I was suggesting is this: to reboot the Alpha, you could set off ah sequence of events like so:t  E (Some magic, REPLY or some other broadcast) is used to send an escapey> sequence to the PC connected to the serial console and runningH Reflection. That escape sequence causes the PC to execute a script whichH sends command to the Alpha as if typed at the keyboard to accomplish the< VMS shutdown, alter the necessary console variables (ostype,3 boot_osflags, etc.) and execute the "boot" command.   E Likewise under Tru64, you'd need to send it an escape sequence to runsH the counterpart script to shutdown Tru64, modify the console environment for VMS and boot up.  C That's one way you could do it. Kinda goofy, but possible. I'm sureo there are other ways...   = > I'm quite curious what will happen to the date/time format.o  H I'm also curious as to what difference is made by the "ostype" variable.H I've never had to deal with it, though I may try it if I get the chance.   -- e David J. Dachterao dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------   End of INFO-VAX 2002.663 ************************