RE: IPS Issues document

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

This is sort of an interesting thread.  It sound like the goals
covered so far are:
1)Reduce CPU utilization
2)Minimize copies
3)Acheive low latency
4)Avoid hardware obsolescence/bottlenecking

(...along with, as previously stated of course, using IP as the 
transport).  What approaches can meet the above?  BTW, this sounds
like a lot of what was in the Framework draft that was sent out.
  --  markb

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Tuesday, March 14, 2000 11:14 PM
> To: Zachary Amsden
> Cc: Bradley, Mark; ips@ece.cmu.edu
> Subject: Re: IPS Issues document
> 
> 
> 
> 
> I would like to clarify my comment. I am not contesting the 
> fact that CPU
> will get saturated.
> My concern is that CPU load decrease does not justify 
> specialized silicon
> for protocol processing
> (as it gets soon out-dated like the 186 NICS) and you have 
> the nightmare of
> supporting 2 protocol stacks.  Memory load on the other hand can't be
> solved any other way than by off-loading and reducing copies 
> to a minimum.
> 
> Regards,
> Julo
> 
> Zachary Amsden <zamsden@cthulhu.engr.sgi.com> on 14/03/2000 20:53:41
> 
> Please respond to Zachary Amsden <zamsden@cthulhu.engr.sgi.com>
> 
> To:   "Bradley, Mark" <mark_bradley@btc.adaptec.com>
> cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
> Subject:  Re: IPS Issues document
> 
> 
> 
> 
> > 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...
> > :{)   )
> 
> I agree completely with that - protocol processing and 
> interrupt time alone
> for a 1 Gbps connection can easily saturate a single CPU, even with
> interrupt
> coalescing and many other tricks.  When you move to a 10 Gbps 
> connection,
> you
> can't just add more CPUs to deal with the problem, because of 
> both cost and
> the fact that you don't get a perfect speedup as you add more 
> CPUs.  This
> makes techniques that reduce CPU and bus utilization more valuable as
> network
> speeds increase.
> 
> --
> Zachary Amsden  zamsden@engr.sgi.com  3-6919  31-2-510  Core Protocols
> 
> 
> 
> 
>