RE: IPS Issues document

["Bradley, Mark" <mark_bradley@btc.adaptec.com>]

Julo, good comments.  My observation is that faster CPU's
don't solve the problem.  We have been getting faster CPU's
since the beginning of time and the only semi-constant is 
that we find that the CPU continues to get utilized.  Large 
MP machines are bought because the processing horsepower
is needed for some appl.(s) that consumes it.  Therefore they
don't have 'extra' cycles to spare.  Most generic OS's
don't support dedicating a processor to specific jobs,
either.  Putting a small processor someplace (an IOP) else
typically doesn't scale as system processing speed increases,
so those often become bottle-necks after some time.  Remember
those 186-based networking cards?

Bottom line is that % CPU utilization has been, is, and will
continue to be an important consideration for some time.
It seems we never have enough CPU, memory or disk.  We seem
always to find ways to use it up.  (I remember years ago
thinking "Wow!  A megabyte on a single platter!  We'll have
enough disk space to last 3 or 4 years!!!"  I also recall
thinking that a 68020 made for a pretty fast workstation.
Now I complain that my dual 450 MHz PC with 128 MB of memory
is not fast enough to be a decent office machine next year... 
:{)   )

  --  markb

> -----Original Message-----
> From: VonStamwitz, Paul [mailto:paulv@corp.adaptec.com]
> Sent: Monday, March 13, 2000 10:50 PM
> To: julian_satran@il.ibm.com; ips@ece.cmu.edu
> Subject: FW: IPS Issues document
> 
> 
> Julian,
> 
> I took the liberty of forwarding your comments to the reflector.
> 
> To get the discussion going...
> 
> Paul von Stamwitz
> 
> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] 
> Sent: Sunday, March 12, 2000 10:43 AM
> To: Dave_Lee@3com.com
> Cc: Bradley, Mark; VonStamwitz, Paul; Wilson, Andrew; 'Costa
> Sapuntzakis'; bassoon@ece.cmu.edu; alan@orca.com; harwood_jack@emc.com
> Subject: RE: IPS Issues document
> 
> 
> 
> 
> Hi,
> 
> Good job.  I had only an hour to glance over it so I might 
> come later with
> some more but here are some observations:
> 
>    Performance - has two aspects - related but not entirely 
> equivalent -
>    latency and bandwidth. It is obvious that bandwidth is not a
>    differentiating factor for any type of interconnect as 
> they use the same
>    physical infrastructure in a similar fashion. Latency on 
> the other hand
>    is a more difficult factor as it relates to hardware, software and
>    protocol. CPU utilization by itself is arguably not a 
> limiting factor -
>    as it can be solved by simply adding more CPUs or waiting 
> until the CPUs
>    get faster.  All the elements you mention under CPU 
> utilization refer
>    mostly to the memory subsystem utilization - and there are 
> no known ways
>    to improve on that  as the memory does not get faster as 
> fast as the
>    CPUs do (no Moore law for DRAMs!).  Protocol stack 
> processing reduction
>    is the mainly improving your "placement" techniques and 
> reducing copy
>    operations. Storage subsystems fare better (and so does 
> FCP) since the
>    do scatter-gather DMA (and DMA is times faster than copy due to an
>    architectural "feature" of DRAMs that use one address 
> setup for several
>    memory operations.  This is the reason why we think that giving the
>    protocols a chance to do well DMA is so important
>    Adoption of the solution by the device vendors is important but not
>    critical. Adoption of a "last half-meter" protocol - like 
> the serial-ATA
>    pushed by Intel, with all its drawbacks could offer a 
> cheap alternative
>    for fiercely competitive environments like desktops with 
> SCSI as a more
>    robust and functional cousin. For clusters and RAIDs both can be
>    considered and with IP getting adopted by pervasive 
> computing may get IP
>    networks to the point at which the price differential will 
> not exist
>    anymore
>    You do not mention the SBP although, I recall it as the 
> first serial
>    SCSI standardized
>    On the performance section I think that solution 
> scalability for the
>    low-end to the high-end is essential as it is the only way to gain
>    "mass" and survive the continuous shift in performance
>    Management should include both storage and interconnect.  
> Any solution
>    should be able to use for interconnect management whatever 
> is good for
>    network management with only slight concern about the 
> device specifics.
>    A factor that I have difficulty expressing is - skills and tools
>    availability. By this I mean planers, administrators and 
> (why not!) even
>    salesman and their tools. Any solution that we leverage an existing
>    skill (and tools) base will have a distinct advantage
> 
> Regards,
> Julo
> 
> Julian Satran - IBM Research at Haifa
>