Conference 7.286::digital

They are a partner - we sell them components, they build systems.  Aspen
doesn't hamstring its systems with poor-performance memory and I/O the way we
have been.

					Steve

    are we servicing their equipment??
    

    Tom,
    
    You can get the scoop using NETscape - go to http://www.aspsys.com/  
    
    For a PR angle contact Lisa Lipson at 508-568-4352 of the AxP 
    Microprocessor and Peripheral chips - Digital Semiconductor Division 
    or reference http://www.aspsys.com/media/dectel.htm
    
    The Area Sales Manager is Pat Lubinski in Irvine Cal. (714)-727-0468.
     
    Within Digital Semiconductor, a TSR rep. is also available for Q&A.   
    Try either DTN:225-5340 Rosemarie Lupo or Gwen Cook DTN:225-4759.
     
    And after all of this you get to buy me a coffee !!
    
    Dave
    

RE: .2

Our agreement with ASPEN includes MCS installation, warranty and 
on-going maintenance to their end users.

- John.

    Re: .1 - 
    Steve, saying that Digital Alpha systems have poor-performance memory
    and I/O is a broad, unspecific, and (I suggest) undeserved slam.  Yes, 
    it's likely that you can find a benchmark that Aspen does better on, 
    but I'm sure I can find plenty that AlphaStations do better on!  
    
    Specifically, if Aspen does better using SPEC92 on EV45 at 275 Mhz, one 
    should note that the Digital published SPEC92 ratings for our 275 Mhz 
    EV45 workstation, the DEC 3000 Model 900, were run with compilers that 
    are now on the order of 15 months old.  That's a very long time, and 
    if Aspen has tested the identical chip with different memory and newer 
    compilers, my first guess would be that the compilers make the difference 
    not the memory, for SPEC92.
    
        /john

    If Aspen is offering MCS installation, warranty and on-going maintenance
     to their end users as well as the Alpha chip at a lower price, then
    what do I tell my customer to get them to buy Digital Alpha
    workstations.
    
    
    

|    If Aspen is offering MCS installation, warranty and on-going maintenance
|     to their end users as well as the Alpha chip at a lower price, then
|    what do I tell my customer to get them to buy Digital Alpha
|    workstations.

I am not a salesperson, but IMO the first goal should be to get a costomer onto
any Alpha, be it a Digital or non-Digital. If a customer has already decided to
go to Alpha by getting Aspen systems concentrate on patting them on the back and
then sell Digital add-ons to the acccount. I agree that this may not be that
optimal for the Digital sales rep *initially*, but helps create business for
us down the road.

>Per

One of the reasons that a customer might go with ASPEN, rather than 
DIGITAL, is the the unique-to-ASPEN software/hardware configurations 
that they offer to customers with a particular need. Don't ask me 
what it is exactly that they are selling, it's several months ago 
that I briefly saw their systems, but I recall that their systems had 
rather clever graphics hardware/software.

- John.

I think it's fantastic that Alpha workstations are coming out from other
vendors!!  This does a few things IMHO:

1.  Look at the home page of Aspen, there is plenty of hype (free advertising)
on the Alpha architecture including a blurb on how other chipsets have reached
physical limits and how the Alpha chipset is 'the chipset of the future' (or
something like that).

2.  With a lot of folks developing workstations based on Alpha, the systems
architecture will only get better, workstation vendors will 'raise the bar'
on increasing I/O performance and the customer wins!!

3.  Like someone said in this thread earlier, both Digital sales reps and
channels can sell customers a wide variety of Alpha solutions...as a customer
I would be VERY impressed if a Digital sales rep sold me Aspen's if that is
what I wanted and then serviced them...I might be apt to buy a ton of Digital
software to run on it!!! 8^)

-Stephen

    
    Tom,
    
    where are you ?
    
    
    AW

    
    Re: .1
    
     <<< Note 3995.1 by QUARK::LIONEL "Free advice is worth every cent" >>>

>They are a partner - we sell them components, they build systems.  Aspen
>doesn't hamstring its systems with poor-performance memory and I/O the way we
>have been.
>
>					Steve
    
    
   Can you elaborate on this a little? Since Aspen uses the APECS chipset
    just like we do to talk to the memory and I/O, I am not sure I know
    what you are talking about. 
    
    

All I know is that the published performance ratings of their systems exceed
ours for the same clock rate.  I also know that we've not paid attention to
memory and I/O speed in the past, but this has changed with the 
AlphaStation 250 and 600 systems.

				Steve

|All I know is that the published performance ratings of their systems exceed
|ours for the same clock rate.
    
    Sigh.
    
    They can ship a customer:
    	- 3 slower M3's (at either 166MHz, 200MHz, or 233MHz)
    	- 3 even slower M3's (with 512KB of Bcache instead of 2MB, same clocks)
    	- or a slightly faster M3 (at 275MHz instead of 266MHz)
    
    And I think that's just great!
    
    But it has nothing to do with they pay attention to memory and I/O
    speed and we don't.  (Particularly since at 275MHz, they have slower
    memory and I/O performance than we do as far as I know.  Ironic, huh?)
    
    We just made some slightly different tradeoffs at 166MHz and 233MHz,
    which saved some chip count, which also saved some cost.
    
    Maybe there is a big market for large wide caches on slower clock rate
    CPUs in this half-over 1995 and beyond.
    
    
    I for one wish them all the luck in the world.
    
    								-mr. bill

re: .12

If you're comparing 275Mhz Aspen systems with 275MHz DEC3000's, it's not
surprising that a system built using a four year old chipset is outperformed
by a system using the latest EV4 support chips;  don't you expect a Pentium
system using the latest Triton chipset to outperform versions that were sold
only a year ago?  

If you're comparing 275Mhz Aspen systems to the newer AlphaStation line, then
you're comparing similar generations of support chip technology.  The Aspen
system is architecturally most like our AlphaStation 250;  if it has a
performance edge, it's probably on CPU-centric benchmarks, where the 275Mhz
Aspen system will have an advantadge over the 266Mhz AlphaStation 250.
In apples-to-apples comparisons using the same I/O cards, AlphaStation 250's
should show better I/O performance than the Aspen systems, as the AlphaStation
runs its PCI bus at 33Mhz, versus 30Mhz on the Aspen system.

I take exception to the statement that "we've not paid attention to the memory
and I/O speed in the past."  From my experience, quite the contrary is true.

    An Aspen Telluride @275 can take up to 8Mb L2; I believe we max out
    a 275 M3 at 2Mb, so it probably isn't that hard to get the Aspen to
    beat the M3 at the same clock speed by throwing cache at it.  We
    went thru two generations of workstations (Jensen, Avanti/Mustang)
    that held Alpha back at 512kb before light dawned.

    I'm with Bill - having a competitor that uses Alpha is good for keeping
    us awake and good for Alpha.  I think David Stone used to call this
    "coopetition", and B-schools make much of how the phenomenon can help
    markets grow.
    
    But back to Steve's concerns for a moment:
    
> All I know is that the published performance ratings of their systems exceed
                         ^^^^^^^^^
    
    Um, published as in "submitted to an audit or peer review process and
    officially published by TPC, AIM, or SPEC with full disclosure of
    testbeds and methods"?  Or published as in "claimed in an internet
    posting or marketing brochure"?  
    
    If the latter is all you do, it makes it a lot easier to take advantage
    of this month's whizzy new compiler feature or extra tweak to the cache
    or lovely new IO device.  It can easily give you a couple percent in
    the game (or more).  It costs a lot less than doing the former. 
    
    But the former is far more likely to be reproducible by the customer,
    who can go look up just exactly how you got to the claimed level of
    performance.  The former is less error prone and is more credible.
    
    I would hypothesize that whatever Aspen advantages you may have
    observed probably came from 3 causes:
        - more recent compilers
        - different cache configurations
        - less formal test methods
    
    Please note that I am not accusing Aspen of publishing incorrect data;
    just saying that what I have seen appears to come from a less formal
    performance tradition that makes it easier to claim a few percent more
    than the stodgy HP, SGI, IBM, Intel, Sun, Digital players.
    
    Meanwhile, back to claims that IO and memory need improvement: sure, of
    course they do.  CPUs need improvement too.  So do caches.  And bus
    speeds.  And compilers.  And operating systems.  And run time
    libraries.  And tuning guides and field education and partner support
    and marketing programs and pricing.  Until the day that these are
    perfect, they will always need improving, FOR ALL COMPANIES IN THE
    INDUSTRY.                                 
    
    I just don't know of any evidence that Aspen has done anything amazing
    on IO or memory vs. what we've done.  If you do know of a specific
    improvement they've made, by all means please route it to the right
    engineering group.  Please post a note in their notesfile that says
    "How come I can attach a 30 MB/sec Mumble Disk to an Aspen and not to
    an AlphaStation?", or if there's risk of proprietary information
    disclosure please contact the engineering group off line.
    
    	/john
                                                  

    re: .15
    
    Yup, Aspen's Telluride can take up to 8MB of L2 cache (12 ns).
    Last I knew, it was still a future.  (Cost out 8MB of 12 ns cache
    memory recently?)
    
    
    And you are quite wrong about our small caches.
    
    (Somebody should feel free to pick nits.)
    
    The first EV4 workstations had 256KB caches.  (3000/400, 500)
    Then we came out with 2MB caches. (3000/500X?, 600, 700, 800, 900)
    Then we came out with 256KB caches again.  (3000/300*)
    Then we came out with 512KB caches.  (Jensen, AS 200 4/*)
    Then we came out with 2MB cache.  (AS 250 4/*)
    Now we came out with 2MB or 4MB.  (AS 600 5/266 (600 5/300 4MB only))
    
    This is no "light dawned".  It is rational tradeoff of the cost of
    cache (at a time in recent history) vrs cost of a system.  It is no
    "light dawned" to say that it is generally unwise investment to pay
    more for L2 cache than the rest of the system combined.
    
    (And let's not revisit the mustang/mustang/mustang history again, OK?)
                                                               
    								-mr. bill

.13>    We just made some slightly different tradeoffs at 166MHz and 233MHz,
.13>    which saved some chip count, which also saved some cost.

Did this translate into a lower price?  If not, then Aspen's choices look
better to the customer.

.16>    Um, published as in "submitted to an audit or peer review process and
.16>    officially published by TPC, AIM, or SPEC with full disclosure of
.16>    testbeds and methods"?  Or published as in "claimed in an internet
.16>    posting or marketing brochure"?  

I think this is "published" as in "the magazine made up a set of tests and
ran them on a set of machines, and here's what they found."  Strangely
enough, this tends to have more credibility with customers than all our
carefully controlled TPC and SPEC processes.

.17>    (Somebody should feel free to pick nits.)

One nit: the 3000/500X had the same size cache as the /500; that's the main
(performance) difference between it and the /800.

re: .17

One more nit... the initial DEC 3000 workstations had 512KB Bcaches, not 256KB.
I should know. :) :) :)

"Mr. Bill's" statements regarding tradeoffs in cache sizes for different
price points is dead on.

    For an example of this tradeoff, see DTJ Vol 6 No 1 page 60 (the Jensen
    case).
    
    In this case, the product ended up with a 512K cache because it was
    cheaper than a 256K cache.. 
    
    I only point this article out because I know it by heart 8-)  .. I'm
    sure there are other articles in DTJ about how the caches ended up
    where they did (based on personal experiences, these articles may
    slightly varnish the truth to protect the, ahh, innocent..)
    
    
    ...tom

    What happens when Digital works an opportunity to push AlphaStations in
    an account, and Aspen, Carrera, DESKstation etc. come in at the end of
    the sales cycle and take the business?
    
    The problem as I see it is our sales/marketing force spends real money
    and effort to sell Digital built AlphaStations.  We are funded and
    goaled to sell Digital built AlphaStations, and a small company that
    put forth very little sales effort (aka the cost of sales) wins the
    sale.
    
    I would like to belive the Aspens of the world were made partners because 
    they were expected to get Alphas into new accounts, and create flexible
    inovative solutions.  Unfortunatly the resellers of these systems
    "cherry pick" the accounts where Digital's SBU/ABU are spending sales
    dollars.
    
    It really hurts a person on leveraged compensation to travel, present,
    overcome objections, configure, and turn a customer away from SPARC,
    MIPs, PA7*00, and PowerPC, only to lose to a clone.  
    
    I would have no problem with a clone reseller moving product into small
    accounts, or even educational accounts that cannot afford full blown
    AlphaStations.  I agree that getting Alpha proccessors out their is the
    right thing to do, but not if it is at the cost of our marketing and
    sales effort.  
    
    Yes we can win, "if" we can successfully get the customer to belive the 
    following.
    
    AlphaStations are a better long term investment, and have better
    residual value.  (Use Tatung, and Solborn SPARC clones as examples)
    
    Digital maintains the firmware on AlphaStations.  Who maintatins the
    firmware on the clone machines, will they be able to run future
    operating system versions, and take advantage of new hardware options?
    
    Digital has a great history of maintaining Digital products.  Will
    parts be available on the clones in three years?
    
    Just my thoughts,
    dpdmai::maria
    
    

    Bottom line - That the Aspen performance exceeds M3 performance on many
    benchmarks is attributed to the 275MHz clock vrs 266MHz clock, not
    cache/memory bandwidth or I/O bandwidth (which is actually about
    10% lower on the Aspen).
    
    Bottom line - I've not seen many performance reviews of the Aspen
    at 166MHz, but I'd be shocked if it blows the socks off the
    Mustang at 166MHz.  I'd even be shocked if it knocked its socks
    off.  I think we are talking photo finish here.
    
|.13>    We just made some slightly different tradeoffs at 166MHz and 233MHz,
|.13>    which saved some chip count, which also saved some cost.
|
|Did this translate into a lower price?  If not, then Aspen's choices look
|better to the customer.
    
    Fewer APECS chips cost less than more APECS chips.  It is a real
    cost savings.  Which results in real benefits to our customers and
    Digital.
    
    We aren't talking about the 12.5MHz TURBOchannel here, where there was
    no cost benefit.  (There was a significant time to market benefit for
    the Pelican family to use the existing "half speed" TURBOchannel
    support chips though.)
    
    
    Consider for a moment these hypothetical clock rates:
    
    			Benefits of		Cost of
    			higher			higher
    			cache/memory		cache/memory
    			bandwidth		bandwidth
    						relative to system cost
    
    	~100 MHz	miniscule		very high
    	~150 MHz	tiny			high
    	~200 MHz	small			medium
    	~250 MHz	large                   low
    
    
    It is not mass delusional decisions by irrational employees of
    the industry which resulted in the Indys, HP 712s, and Mustangs
    (and various Intel boxes) of the world making this very same tradeoff.
    
    Since the cost column is constantly changing (getting lower by
    the day) the day will come sooner or later where it *does* make sense
    to offer more cache/memory bandwidth at the bottom.  But then the
    argument will shift to the choice between more bandwidth and
    still more bandwidth.
    
    								-mr. bill

    re .21 firmware upgrades for Alpha clones...
    
    A friend bought a Carrera Alpha clone.  When NT V3.5 came out,
    it needed a firmware upgrade.  Carrera wanted $1500(!) for the
    upgrade.  It gathers dust now.

    All of our new AlphaStations use 21x64 chips running at a clock speed
    that is divisable by the 33.33Mhz.  The AlphaStation *** run at 100,
    166, 200, 233, and 266Mhz.
    
    All of the DEC 3000 systems used a 12.5Mhz, or 25Mhz TurboChannel bus.
    They ran at 125, 150, 175, 200, 225, and 275Mhz.
    
    I just found out the 21051-AA is a 25Mhz cost PCI bridge.  The
    AlphaStations use the 21050-AA PCI bridge.   I wonder what Aspen uses
    in their 275Mhz system?????
    
    
    
    
    

RE: Clone firmware

There is a group in HLO that maintains the firmware for the clone systems,
which is then licensed to the clone vendors.  I guess the vendor are then 
free to charge whatever the market will bare for the upgrade.

I can't be certain, but the clone firmware may be present on the quarterly 
firmware upgrade CD.

							-Paul