> Mark Guzdial <[EMAIL PROTECTED]> wrote:
> > At 11:50 AM -0300 4/27/00, Gerardo Richarte wrote:
> > >Mark Guzdial wrote:
> > >
> > > What I was thinking, is: if STOMP (the testing engine) is not
> > >fast enough, then,
> > >can it really test something related to speed on a sevrer faster
> > >that it? Doesn't STOMP
> > >has an upper limit in speed testing becouse it's
> implemented in Squeak?
> >
> > Network speed is always slower than processor speed. That's not an
> > issue. Even wimpy processors can swamp a T1. More, it's the issue
> > of using multiple client processors to see how much the server can
> > take.
> >
>
> On a 10 MBit/s network, yes. It seems, though, that multiple
> Squeak-level buffer copies are enough make a server slower than a *100
> MBit* network.... After all, 100 MBit is an order of
> magnitude closer to
> the raw memory-access speed of a computer. (which figure I don't know
> offhand; does anyone? I want to say 40 MB/s which would be
> 3200 MBit/s,
> but it might be faster than that)
According to Tom
(http://www.tomshardware.com/mainboard/99q4/991215/index.html),
the new Intel i840 chipset is good for "up to" 3.2 GB/s memory bandwidth.
That would be 25.6 Gbits/s. Of course, this is total bandwidth and subject
to many, many things. Most high speed networking work tends to focus on two
things -
1. Minimize latency (do more work per transaction, pipelining, etc.)
2. Maximize throughput. The first thing that you do is MIMIMIZE copies.
Copying data is bad (for performance). The really extreme guys even try
to avoid the copy between user space memory and kernel memory using
a variety of softare and/or hardware techniques. Remember that memory
bandwidth is not scaling at the same rate that processor performance is.
If you are spending a lot of time moving data around, doubling the
speed of the processor without changing memory technology may not buy
you anything.
> On the other hand, Comanche *should* be able to transfer a file at 100
> MBit/s. If anyone has time to work on this, BufferStream looks like a
> good candidate for optimization. For example, instead of
> having a single
> buffer, it could have a list of buffers and thus avoid a lot
> of copying.
>
>
> -Lex
