From: Matthias Schniedermeyer <ms@citd.de>
To: "Martin A. Fink" <fink@mpe.mpg.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SATA-performance: Linux vs. FreeBSD
Date: Tue, 13 Feb 2007 14:53:45 +0100 [thread overview]
Message-ID: <45D1C2E9.4070803@citd.de> (raw)
In-Reply-To: <200702131349.05428.fink@mpe.mpg.de>
Martin A. Fink wrote:
>> The needed total bandwidth may be to high and at least the incoming part via
> GigE may have serious overhead.
>> 150MB/s in via (at least 2) GigE, without Zero-Copy there is another 150MB/s
> memory to memory.
>> Then there is the next 150MB/s memory to the discs, without Zero-Copy there
> also another 150MB/s memory to memory.
>> In total that's 300MB/s to 600MB/s without any processing.
>
> I dont understand your calculation: from 3 GE ports come around 50 MB/each.
> These altogether 150MB/s have to be copied to memory. From there they will be
> copied to disk. So we talk about 2x150 MB/s running through my system. That
> is less than 2 PCIe lanes can handle... And there are more than 2 lanes
> between north and south bridge....
It may be that the TCP/IP-Stack has to copy the data around. But someone that knows the inner workings would have to answer this.
That may also depend on the used NIC.
Also the data doesn't appear 'en bloc', but arrives over a period of time, so you have more or less big "gaps" in the processing.
Especially the "gaps" can considerably lower total achievable bandwidth.
A little naive fallacy (According to dict.leo.org a translation for: Milchmädchenrechnung):
You get a package of work every (say) 1ms and you (say) need .2ms for processing, shoveling and writing to disc.
Then there is no way you can saturate more than 1/5 of total theoretical bandwidth, because 80% of the time you are waiting for more work to come.
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
next prev parent reply other threads:[~2007-02-13 13:53 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-12 14:02 SATA-performance: Linux vs. FreeBSD Martin A. Fink
2007-02-12 17:04 ` Andi Kleen
2007-02-12 16:27 ` Martin A. Fink
2007-02-12 18:41 ` Andi Kleen
2007-02-12 17:56 ` Martin A. Fink
2007-02-12 18:17 ` Ray Lee
2007-02-12 19:08 ` Alan
2007-02-12 20:34 ` Nigel Cunningham
2007-02-13 9:34 ` Martin A. Fink
2007-02-13 11:25 ` Alan
2007-02-13 12:32 ` Martin A. Fink
2007-02-13 14:47 ` Theodore Tso
2007-02-13 15:03 ` Alan
2007-02-13 17:12 ` Jeff Garzik
2007-02-12 23:31 ` Matthias Schniedermeyer
2007-02-13 9:25 ` Martin A. Fink
2007-02-13 10:08 ` Arjan van de Ven
2007-02-13 11:18 ` Andi Kleen
2007-02-13 10:25 ` Arjan van de Ven
2007-02-13 11:27 ` Alan
2007-02-13 11:59 ` Jörn Engel
2007-02-13 19:54 ` Jeffrey Hundstad
2007-02-13 10:16 ` Matthias Schniedermeyer
2007-02-13 10:29 ` Martin A. Fink
2007-02-13 12:04 ` Jörn Engel
2007-02-13 12:24 ` Matthias Schniedermeyer
2007-02-13 12:49 ` Martin A. Fink
2007-02-13 13:53 ` Matthias Schniedermeyer [this message]
2007-02-12 16:37 ` Martin A. Fink
2007-02-12 18:19 ` Stefan Richter
2007-02-13 19:09 ` Jeff Carr
2007-02-12 17:42 ` Martin A. Fink
2007-02-15 5:48 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45D1C2E9.4070803@citd.de \
--to=ms@citd.de \
--cc=fink@mpe.mpg.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox