linux-kernel - Re: SATA-performance: Linux vs. FreeBSD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45D1C2E9.4070803@citd.de>
Date:	Tue, 13 Feb 2007 14:53:45 +0100
From:	Matthias Schniedermeyer <ms@...d.de>
To:	"Martin A. Fink" <fink@....mpg.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: SATA-performance: Linux vs. FreeBSD

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/