Conference 7.286::digital

RE: .0

> Around the middle of the decade, when the benefits to our users outweigh
             --------------------
> the costs, HP will supply 64-bit systems which are completely compatible
> with applications running on our present systems.  We expect most major
> system vendors to do the same.


Well, it is 1995, our technology has had 3 years to ramp, and HP hasn't 
even begun their technology churn.  All that just to say that they are
about 5 years behind our technology curve.

    I'd like to think our customers aren't stupid enough to by that tap
    dance...
    
    

	HP = 64-bits is bad news until we get around to offering a
	product.

	"PA-RISC has always had..." = Lets make it sounds like it's
	been around forever.

	What a bunch of horse puckey. HP, IBM, quit your whining!
	(Tho I have to admit, it's nice that we are in this position!)

							mike

    When I was at TI they did a short blitz about why LEDs were superior to
    LCDs in watches.  The reason for this was simple.  TI wasn't yet
    prepared to compete in the LED watch market at the time.  Similarly,
    when 7UP advertized "no caffiene" there was a lot of whining from the
    cola makers since they couldn't compete in the market.
    
    The *fact* is that HP (and IBM) are both whining because Digital is
    taking a stance that our competitors can't compete effectively with.
    Given this, it seems to me that the ad campaign about other companies
    whining is *absolutely* the right thing to do.  I think our next step
    should be to start quoting what our competitors are saying and POINT
    OUT that, true to our ads, they are WHINING!  Our customers need to
    *instantly* recognize the kind of BS as in .0 as WHINING!  But, I think
    we need to CONTINUE to point this out clearly and effectively.
    
    Steve

    HP also say, "when the benefits outweigh the costs".  In most cases
    Alpha is cheaper than HP's products anyway and there does not seem to
    be a technical cost to 64-bits.

> and there does not seem to be a technical cost to 64-bits.

  Perhaps not, but it only takes one or two "assumptions" (on the
  part of some poor programmer 'way back in history) that a pointer
  and an int are the same to add up to a lot of non-technical costs.

  This isn't a long-term argument against a 64-bit architecture,
  but it's a fact of life that essentially *EVERYONE* who ports
  will have to face somewhere along the way.

  The H/P letter contains a lot of FUD, but like any effective
  propaganda, it's based on some kernels of truth.

                                   Atlant

    This is absolute crap.  (But hey, is anyone surprised?)
    
    The statement that no-one gets any benefit from 64-bit addressing is
    galling.
    
    Right now we have a KILLER application in SAS running on UNIX/Alpha. 
    Many mainframes are downsizing large SAS files, often greater than
    2Gbytes.  WE ARE THE ONLY GAME IN TOWN!!!  None of our competitors can
    access files >2Gbytes, and this business is ours for the asking.  We
    have two formerly hostile accounts that have had to hold their noses
    and buy AlphaServer 2100 4/275s running UNIX to run SAS... this has
    in-turn lead to greatly increased credibility and presence in the
    accounts.
    
    This is starting to fell pretty good!!!
    

    Did HP say that NO ONE NEEDS 64 bit addressing??
    
    Did they THEN go on to say "If you do need 64-bit addressing, then
    PA-RISC can emulate it for you".
    
    Sound very like the IBM advert around the new Oracle/Alpha mainframe
    killer:  "Its not true, and even if it was true, its not fair!"
    

> 
>                         64-BIT FACTS AND FALLACIES
> 
> Lately, DEC has been making a lot of noise about their 64-bit processor,
> Alpha, and how superior it is to all the 32-bit RISC machines, including
> PA-RISC.  The purpose of this note is to debunk these claims and put
> "64-bitness" in its proper perspective.
> 
> First, you may be surprised to hear that not a single HP user has received
> any benefits from 64-bit hardware--and they won't for several years, if
> they stick with us!
> 
> Second, the claimed performance benefits of 64-bit hardware do not
> materialize on real applications.  The reason is that HP applications
> cannot operate on integers larger than 32 bits!  Larger integers are
> extremely rare and are not part of the performance path of the HP application.
> DEC also claims that 64-bit machines are faster at moving blocks of data
> around, but most RISC machines--including PA-RISC--already move data blocks
> and clear storage areas by moving 64-bit chunks through the floating-point
> registers!  If an application actually uses 64-bit integer registers, then
> all the register saving and restoring that occurs on context switches and
> procedure calls requires twice as much cache space and bandwidth, which
> degrades performance of a hyptothetical HP implementation.
> 
> Third, the truth is that going to 64 bits is not paced by hardware at all.
> The critical path to making good use of 64-bit capability is several layers
> of software and its APIs--all of which must be standardized, implemented,
> and widely distributed before applications can enter the 64-bit world.
> This is not expected to happen at HP before about 1996, and 64-bit HP
> applications are not expected to proliferate until late in the decade.
> 
> If it's going to be such a long wait with HP, why are we talking about
> 64 bits now?  What does it mean to users, and how does PA-RISC stack up?
> 
> Sometimes, the move from 32 to 64 bits is compared to the move from 16 to
> 32 bits.  As International Data Corporation points out in their analysis,
> the situations are very different.
> 
> In the move from 16 to 32 bits in the late 70's, there was a pent-up demand
> for greater-than-16-bit addressing which created a tremendous market pull
> for 32-bit systems in advance of their availability.  And this is exactly
> why Windows decided to wait 20 years more. Remember that 16 bits address
> only 64 thousand bytes, while 32 bits are sufficient to address 4,000
> megabytes (32 billion+ bits) of memory!  Since practically all HP
> applications can use only a small fraction of this space, we cannot create
> a market pull to 64 bits.
> 
> As the density of DRAMs continues to increase, the size of physical memories
> will eventually grow beyond 4,000 megabytes. The cost of $25 per megabyte,
> that corresponds to $100,000 worth of DRAM chips today!  In three years, the
> DRAM cost will drop to about $50,000.  Eventually, the population of such
> AXP systems will be large enough so that applications requiring large
> memories will begin to appear on HP too, but for at least the next several
> years they will be very rare on PA-RISC machines.
> 
> You are probably aware (though your customer may not be) that PA-RISC has
> always had 64-bit virtual addressing. In fact, we even use 128-bit microcode
> instructions. This large address space facilitates data sharing and permits
> large files to be "memory mapped"--meaning that the data in files can be
> directly addressed by the application or database without explicit "reads"
> or "writes."
> 
> On PA-RISC, the 64-bit virtual address is formed in two parts instead of
> one, leaving you more control.  The high-order 32 bits and the low-order
> 32 bits are then concatenated to produce the 64-bit address.  This scheme
> satisfies most of HP's requirements for a large address space without
> requiring us to develop double-width general registers. 
> 
> The only cases which are handled less efficiently are those in which
> single objects, such as tables or arrays, are larger than 4,000 megabytes,
> comparable to the size of 4 hard disks from Lechemere. It will be years
> before anyone will notice this limitation.
> 
> The cache busses on PA-RISC machines are already 64 bits wide, to accomodate
> high speed movement of 64-bit operands into and out of the floating-point
> registers.
> 
> Although it is often stated that the incremental cost of widening a 32-bit
> integer data path to 64 bits is only 7%-10% of silicon die area, this
> overlooks the equivalent cost for a superscalar processor having two integer
> units--in which case the incremental cost is doubled, and the cost-performance
> of the HyPothetical processor is compromised without user benefit.
> 
> Around the middle of the decade (like 1995), when the benefits to our
> users outweigh the costs, HP will supply 64-bit systems which are
> completely compatible with applications running on our present systems. 
> We expect most major system vendors, that haven't already done it by then,
> to do the same.
> 
> As with any system, the actual value of 64-bit machines results from the
> availability of 64-bit applications which satisfy real user needs.  For all
> of the reasons we've discussed, such applications will not arrive on the
> HP scene until after the mid-90's.
> 

    No one needs 64 bit addressing.  Applications can't use it.  Software
    doesn't use it.  Users don't need it.
    
    But just in case they do, here's how we do it ...

This is a good feeling, after a long time, HP and IBM cribbing about 64-bit
Alpha technology and in turn giving us good press (although they mean
otherwise). Does anyone have comments on the claim that "software layers, APIs,
compilers etc." are not (and will not for a while) utilize the 64-bits power
and hence there is no real gain in performance for "real" applications. Is this
an issue? Are we addressing it? How?

Avinash

                    <<< Note 3816.13 by CSC32::C_BENNETT >>>
                          -< what does it stand for? >-

    

     Fear, Uncertainty and Doubt

    it's been a long time since HP / IBM have been fearful of us!! this is
    terrific news!  it does my heart good...
    
    

    note sync problem...
    
    FUD HP term?  
    
    The recent advancements in database benchmarks, and I would
    imagine advancements in high end scientific applications, VR, etc..
    would explain HPs FEAR.  They see the need...
    
    The uncertainty part - what they are uncertain that their FAB can pull
    it off?   Maybe we can sell them some Alphas? 
    
    The applications for 64 bit architecture have as much future as 32 bit 
    did back in the 16 bit days... 16 bit ... 8 bit etc... 
    
    I think that the Digital designers / planners and people in the FAB 
    deserve a pat on the back.   Good work, keep it up!
    
    				Chip

    Probably some of the big users of 64-bit stuff are the people that
    design&build computers, even 32-bit computers!  Would you buy a
    computer from a company that doesn't have this edge?
    
    Mark

    
    .5 
    
    Care should be taken to keep "cost" and "price" as separate issues
    when commenting on technology and who has cheaper products.  
    
    Price - determined by the lowest market price for a given "perceived"
    	    comparible product
    
    Cost  - product design and implementation
    
    price - cost = profit  <-- measured by stock prices...   35 vs 64
    	(accounting for HP's recent 2:1 split..... 128)
    
    HP's recent efforts extract significant "work" at the application level
    from very little hardware...
    
    	HP7200 cpu 		1.2M xistors  100Mhz clk  210mm die
    	cache			512KB 
    
    
    food for thought...
    
    technology costs		in incremental memory with 64 bit pointers
    				Incremental shielding with clocks @ 300 Mhz
    				Cooling w/ opennings under .25"
       				latency in working 3 cache levels..
    					and byte manipulation
    
     On the brighter side.. at least there are now "real applications"
     (data base servers) with more "customer measured" value 
    	with  64 bits machines.
    
    -barry
    
    

Digital should run an ad similar to as follows:

"Our competition says that almost noone needs 64 bits.  And they're right.
But what about those who need 40 bits? Or 33?"


Even mapping a 1TB database as virtual memory "only" needs 40 bit addressing
to do so.

I sent .0 to one of the Alpha chip designers who sent the following response
with permission to "do whatever" I wanted with it.

> 
>                         64-BIT FACTS AND FALLACIES
> 
> Lately, DEC has been making a lot of noise about their 64-bit processor,
> Alpha, and how superior it is to all the 32-bit RISC machines, including
> PA-RISC.  The purpose of this note is to debunk these claims and put
> "64-bitness" in its proper perspective.
> 
> First, you may be surprised to hear that not a single user has received
> any benefits from 64-bit hardware--and they won't for several years!

Really?  I don't have specific sales details, but there are now well over 
100,000 64b systems from Digital out there contributing over $3 Billion to 
Digital revenues so far.  All of the Digital Unix systems include 64b system 
software, so those users are already benefiting from 64b hardware with quite 
a clear future.  Someone buying 32b hardware today might want to think twice.  

Larry Ellison, CEO of Oracle, seems to believe that 64b applications are near 
enough to trumpet the extensive opportunities for the new 64 bit VLM (Very 
Large Memory) Oracle7 database product at our recent and well received product 
annoucement. 

> 
> Second, the claimed performance benefits of 64-bit hardware do not
> materialize on real applications.  The reason is that real applications
> do not operate on integers larger than 32 bits!  Larger integers are

Slow down there guys, that's not what was said.  The biggest gain comparitive 
to a 32b system is due to the fact that you can use fast main memory instead 
of much slower disk storage for large database applications.  This is possible 
only after you break the 4GByte limits of a 32b system by allowing a larger 
than 32b FLAT addressing scheme.  

> extremely rare and are not part of the performance path of the application.
> DEC also claims that 64-bit machines are faster at moving blocks of data
> around, but most RISC machines--including PA-RISC--already move data blocks
> and clear storage areas by moving 64-bit chunks through the floating-point
> registers!  If an application actually uses 64-bit integer registers, then
> all the register saving and restoring that occurs on context switches and
> procedure calls requires twice as much cache space and bandwidth, which
> degrades performance.

Why quibble, both machines are available.  Run the tests and report the
results.  We have quite a list of performance results too.  Check the Digital
Web server  for performance reports, or any independant performance reporting
source.  If there is a performance degradation, customers will see it.  On the
contrary,  virtually every report shows our 64 bit systems on top, sometimes by
a little,  sometimes by a lot.  And we just introduced a new CPU that is much
faster and  isn't reflected in most of those reports. 

> 
> Third, the truth is that going to 64 bits is not paced by hardware at all.
> The critical path to making good use of 64-bit capability is several layers
> of software and its APIs--all of which must be standardized, implemented,
> and widely distributed before applications can enter the 64-bit world.
> This is not expected to happen before about 1996, and 64-bit applications
> are not expected to proliferate until late in the decade.

That's right, it will take some significant time to get all the system 
software moved over to take advantage of 64b systems.  We've done this for 
Digital Unix and have been working on it for OpenVMS, soon to be available.  
There were some early issues to contend with, that's why we started back in 
1989, but then you'll find out too.  If we all wait for the market 
"to proliferate", there would be no leaders. 

> 
> If it's going to be such a long wait, why is there so much talk about
> 64 bits now?  What does it mean to users, and how does PA-RISC stack up?
> 
> Sometimes, the move from 32 to 64 bits is compared to the move from 16 to
> 32 bits.  As International Data Corporation points out in their analysis,
> the situations are very different.
> 
> In the move from 16 to 32 bits in the late 70's, there was a pent-up demand
> for greater-than-16-bit addressing which created a tremendous market pull
> for 32-bit systems in advance of their availability.  Remember that 16 bits
> address only 64 thousand bytes, while 32 bits are sufficient to address
> 4,000 megabytes of memory!  Since practically all applications use only a
> small fraction of this space, there is no market pull to 64 bits.
> 

If we learned anything from that experience, it is that the industry is not as 
well tuned to the market as they would like to think.  The pent up demand for 
32b systems didn't take very long to swell considering that our 16b PDP-11's 
(one of the most popular 16b machines) was only in use for less than 10 years 
before the popular introduction of 32b computing with our VAX in the late 70's. 

> As the density of DRAMs continues to increase, the size of physical memories
> will eventually grow beyond 4,000 megabytes.  At a cost of $25 per megabyte,
> that corresponds to $100,000 worth of DRAM chips today!  In three years, the
> DRAM cost will drop to about $50,000.  Eventually, the population of such
> systems will be large enough so that applications requiring large memories
> will begin to appear, but for at least the next several years they will be
> very rare.

In the meantime, 64b, big memory machines sound pretty cheap compared to those 
slower 1M+ systems struggling to solve the problem now.  Those first 32b
machines  selling into a "market pull" as you say, did not immediately address
the lower  price bands either.  But if you don't need all that memory, you can
still get a  64b machine today for the same price as a 32b machine which should
allow more  people to sleep easier and only add memory as they need it.  It
doesn't hurt to  know that our current systems without big memory have been the
benchmark leaders  for over 2 years now so current applications run faster to
boot.

> 
> You are probably aware (though your customer may not be) that PA-RISC has
> always had 64-bit virtual addressing.  This large address space facilitates
> data sharing and permits large files to be "memory mapped"--meaning that
> the data in files can be directly addressed by the application or database
> without explicit "reads" or "writes."
> 
> On PA-RISC, the 64-bit virtual address is formed in two parts.  The high-
> order 32 bits and the low-order 32 bits are then concatenated to produce
> the 64-bit address.  This scheme satisfies most of the requirements for a
> large address space without requiring double-width general registers.

Yea, yea, yea, and overlays were great too.  How many customers like this 
solution?  I'll bet the number is far fewer than the currently available 64b 
applications by your count and moving in opposite directions!

> 
> The only cases which are handled less efficiently are those in which
> single objects, such as tables or arrays, are larger than 4,000 megabytes!
> It will be years before this becomes a problem for more than a small handful
> of users.

Come on, "only cases" type arguments don't hold water with customers who all 
plan to be around years from now or they wouldn't be buying new computers
today. 

> 
> The cache busses on PA-RISC machines are already 64 bits wide, to accomodate
> high speed movement of 64-bit operands into and out of the floating-point
> registers.
> 
> Although it is often stated that the incremental cost of widening a 32-bit
> integer data path to 64 bits is only 7%-10% of silicon die area, this
> overlooks the equivalent cost for a superscalar processor having two integer
> units--in which case the incremental cost is doubled, and the cost-performance
> of the processor is compromised without user benefit.

Getting weaker and weaker here.  The price of the CPU chip is a fraction of 
the cost of the total system, and if you've already widened the busses as you
say,  then you've added much of the area.  Digital 64b systems don't cost more
than  HP 32b systems period, in fact, they're cheaper, so the point is empty. 

> Around the middle of the decade, when the benefits to our users outweigh
> the costs, HP will supply 64-bit systems which are completely compatible
> with applications running on our present systems.  We expect most major
> system vendors to do the same.

That's fine.  You should decide what's best for your users.  But be careful
with  the "completely compatible" part, it's not as easy as you recall from
your last  transition.  And you're right, press releases confirm that ALL major
system  vendors have promised a 64b transition for their users in the near
future too.

> 
> As with any system, the actual value of 64-bit machines results from the
> availability of 64-bit applications which satisfy real user needs.  For all
> of the reasons we've discussed, such applications will not arrive on the
> scene until after the mid-90's.
> 

Isn't it nice to know that you can buy a 64b machine today that runs literally 
thousands of those applications now and is becoming the platform of choice for 
developing many of the new and exciting, fully capable 64b applications for 
tomorrow. 

	Ed McClellan

Here's Dave Fenwick's response.  Dave is AlphaServer architect in the 
AlphaServer engineering organization.

- Ram


  My responses after >>>. As far as I am concerned we should turn this around 
and attack HP for their limited systems lack of foresight and admission of not
having 64 bit addressing. I summarized this at the end. Hope this helps.

Dave



================================================================================
> 
>                         64-BIT FACTS AND FALLACIES
> 
> Lately, DEC has been making a lot of noise about their 64-bit processor,
> Alpha, and how superior it is to all the 32-bit RISC machines, including
> PA-RISC.  The purpose of this note is to debunk these claims and put
> "64-bitness" in its proper perspective.
> 
> First, you may be surprised to hear that not a single user has received
> any benefits from 64-bit hardware--and they won't for several years!

>>> HP is making a lot of noise about 64 bit PA8000. If it is so 
>>> inconsequential why is HP making claims of being the fastest 64 bit micro
>>> even before they built it. Could it be HP has the worst migration strategy
>>> for its customers 32-64 bit then to another architecture. Push home the
>>> inadequacy of their response as too little too late and costly in migration
>>> terms because by their admission they will move to yet another architecture
>>> in the late 90s. So HP customers can expect two migration steps towards the
>>> year 2000.

> 
> Second, the claimed performance benefits of 64-bit hardware do not
> materialize on real applications.  The reason is that real applications
> do not operate on integers larger than 32 bits!  Larger integers are
> extremely rare and are not part of the performance path of the application.
> DEC also claims that 64-bit machines are faster at moving blocks of data
> around, but most RISC machines--including PA-RISC--already move data blocks
> and clear storage areas by moving 64-bit chunks through the floating-point
> registers!  If an application actually uses 64-bit integer registers, then
> all the register saving and restoring that occurs on context switches and
> procedure calls requires twice as much cache space and bandwidth, which
> degrades performance.

>>> We Digital are seeing this in many applications including scientific and 
>>> commercial where the customers ability to access very large data sets is
>>> giving real performance wins.

> 
> Third, the truth is that going to 64 bits is not paced by hardware at all.
> The critical path to making good use of 64-bit capability is several layers
> of software and its APIs--all of which must be standardized, implemented,
> and widely distributed before applications can enter the 64-bit world.
> This is not expected to happen before about 1996, and 64-bit applications
> are not expected to proliferate until late in the decade.

>>> Wow so now we know when HP can get a 64 bit system out. They are late and 
>>> they are panicking!!!


> 
> If it's going to be such a long wait, why is there so much talk about
> 64 bits now?  What does it mean to users, and how does PA-RISC stack up?
> 
> Sometimes, the move from 32 to 64 bits is compared to the move from 16 to
> 32 bits.  As International Data Corporation points out in their analysis,
> the situations are very different.
> 
> In the move from 16 to 32 bits in the late 70's, there was a pent-up demand
> for greater-than-16-bit addressing which created a tremendous market pull
> for 32-bit systems in advance of their availability.  Remember that 16 bits
> address only 64 thousand bytes, while 32 bits are sufficient to address
> 4,000 megabytes of memory!  Since practically all applications use only a
> small fraction of this space, there is no market pull to 64 bits.

>>> This means HP thinks 4Gbytes is enough. I would attack their lack of 
>>> foresight and vision to see the benefits of 4GB+ memory systems.
> 
> As the density of DRAMs continues to increase, the size of physical memories
> will eventually grow beyond 4,000 megabytes.  At a cost of $25 per megabyte,
> that corresponds to $100,000 worth of DRAM chips today!  In three years, the
> DRAM cost will drop to about $50,000.  Eventually, the population of such
> systems will be large enough so that applications requiring large memories
> will begin to appear, but for at least the next several years they will be
> very rare.
>>> So how come customers are beating a path to our door to take advantage of
>>> large memory with cost being a second issue behind the ability to do 
>>> things they could not do before
> 
> You are probably aware (though your customer may not be) that PA-RISC has
> always had 64-bit virtual addressing.  This large address space facilitates
> data sharing and permits large files to be "memory mapped"--meaning that
> the data in files can be directly addressed by the application or database
> without explicit "reads" or "writes."
> 
> On PA-RISC, the 64-bit virtual address is formed in two parts.  The high-
> order 32 bits and the low-order 32 bits are then concatenated to produce
> the 64-bit address.  This scheme satisfies most of the requirements for a
> large address space without requiring double-width general registers.
> 
> The only cases which are handled less efficiently are those in which
> single objects, such as tables or arrays, are larger than 4,000 megabytes!
> It will be years before this becomes a problem for more than a small handful
> of users.
>>> HP by their own admission can't virtually address a 4GByte + address space
>>> I think with their attitude it will be years before anybody buys an HP 
>>> machine with greater than 4GBytes + addressing. Fortunately we Digital are 
>>> not so narrow minded and we are giving our customers limitless 
>>> possibilities today instead of limitations.
> 
> The cache busses on PA-RISC machines are already 64 bits wide, to accomodate
> high speed movement of 64-bit operands into and out of the floating-point
> registers.
> 
> Although it is often stated that the incremental cost of widening a 32-bit
> integer data path to 64 bits is only 7%-10% of silicon die area, this
> overlooks the equivalent cost for a superscalar processor having two integer
> units--in which case the incremental cost is doubled, and the cost-performance
> of the processor is compromised without user benefit.

>>> PC's have 64 bit datapaths they don't pretend to be 64 bit machines. There
>>> is more to 64 bit systems than just datapaths.

> 
> Around the middle of the decade, when the benefits to our users outweigh
> the costs, HP will supply 64-bit systems which are completely compatible
> with applications running on our present systems.  We expect most major
> system vendors to do the same.
> 
> As with any system, the actual value of 64-bit machines results from the
> availability of 64-bit applications which satisfy real user needs.  For all
> of the reasons we've discussed, such applications will not arrive on the
> scene until after the mid-90's.
> 

>>> Absolutely NOT Digital UNIX has been providing our customers with 64 bit 
>>> application space since day one. Oracle also provides the benefits of their
>>> 64 bit VLM technology without changing the end users application. IN other 
>>> words the customers running on 32 bit ORACLE already have the 64 bit 
>>> application ready when they move to ORACLE VLM

Clearly HP have been surpassed by the 21164 and the AlphaServer 8000 series. 
The arrogant and certainly pathetic "non-announcement" of the PA8000 at COMPCON
'95 underscores their lack of competitiveness in the market space and their
only response is nobody needs this until HP supplies it. The above text is
complete vindication of our strategy and a lamentable commentary on HP's
offerings. 

    Re.20
    
    	Before taking the information within this response to the market,
    we subject it to further analysis. It appears to me that there are some
    problems within.

    Let's not wear ourselves out prematurely patting ourselves on the back. 
    Although the HP FUD letter and our responses give us some great
    ammunition, let's use the messages carefully.
    HP has historically beat Digital by providing superior support,
    dedicated and trained sales teams focused on customer need, superior
    executive level relationships, a long and distinguished record focusing
    on the open systems market, and a huge list of loyal ISVs and
    customers.   Furthermore, their current marketing strategy is to take
    our strength (price performance) and use it against us.  If we respond
    to the HP FUD by just saying we're faster and cheaper (without at the
    same time strengthening our alliances, marketing, support, and focus)
    we will get beaten more often than not.
    	

    I think the best response to this FUD would be to line up testimonials
    from customers that are successfully using Alphas.  Use some of the
    technical arguments presented here as a basis, but let real customers
    drive it home.  I've actually been expecting something like this from
    Digital ads.
    
    Steve

Send your customer a video tape of the TurboLaser announcement with
Oracle.  That tape will answers most of HP FUD.


						-Paul

    re. 23
    
    take a look at Kent::Turbolaser_marketing at note 101 for current
    testimonials and references
    
    rick

    I am seeing pretty much the same story right across Europe.
    Sometimes our customers (US based and European) do dance to the HP tune
    and we need to better articulate and be more literate to challenge the 
    aggressive HP stance. 
    
    For us to make them really suffer, and double our revenues in the near
    future, we're going to need more applications (like SAS) - and more 
    seed/demo units.
    
    

Re .8: what IBM ad was this?

PJDM