On Fri, 2 Feb 2001, David Lang wrote:
> Thanks, that info on sendfile makes sense for the fileserver situation.
> for webservers we will have to see (many/most CGI's look at stuff from the
> client so I still have doubts as to how much use cacheing will be)
CGI performance isn't directly affecte
David Lang writes:
> right, assuming that there is enough sendfile() benifit to overcome the
> write() penalty from the stuff that can't be cached or sent from a file.
>
> my question was basicly are there enough places where sendfile would
> actually be used to make it a net gain.
There a
Morton <[EMAIL PROTECTED]>, lkml <[EMAIL PROTECTED]>,
> > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > Subject: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
> >
> >
> > David Lang writes:
> > > Thanks, that info on send
vid S. Miller wrote:
> Date: Fri, 2 Feb 2001 15:09:13 -0800 (PST)
> From: David S. Miller <[EMAIL PROTECTED]>
> To: David Lang <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>, lkml <[EMAIL PROTECTED]>,
> "[EMAIL PROTECTED]" <[EMAIL
David Lang writes:
> Thanks, that info on sendfile makes sense for the fileserver situation.
> for webservers we will have to see (many/most CGI's look at stuff from the
> client so I still have doubts as to how much use cacheing will be)
Also note that the decreased CPU utilization resulting
2001 14:46:07 -0800 (PST)
> From: David S. Miller <[EMAIL PROTECTED]>
> To: David Lang <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>, lkml <[EMAIL PROTECTED]>,
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: Re: send
David Lang writes:
> 1a. for webservers that server static content (and can therefor use
> sendfile) I don't see this as significant becouse as your tests have been
> showing, even a modest machine can saturate your network (unless you are
> useing gigE at which time it takes a skightly large
> Date: Fri, 02 Feb 2001 21:12:50 +1100
> From: Andrew Morton <[EMAIL PROTECTED]>
> To: David S. Miller <[EMAIL PROTECTED]>
> Cc: lkml <[EMAIL PROTECTED]>,
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: Re: sendfile+ze
> " " == Andrew Morton <[EMAIL PROTECTED]> writes:
> Much the same story. Big increase in sendfile() efficiency,
> small drop in send() and NFS unchanged.
This is normal. The server doesn't do zero copy reads, but instead
copies from the page cache into an NFS-specific buffer usi
"David S. Miller" wrote:
>
> ...
> Finally, please do some tests on loopback. It is usually a great
> way to get "pure software overhead" measurements of our TCP stack.
Here we are. TCP and NFS/UDP over lo.
Machine is a dual-PII. I didn't bother running CPU utilisation
testing while benchmar
Hi!
> Advantage of Tulip and AMD is that they perform much better in my experience
> on half duplex Ethernet than other cards because they a modified
> patented backoff scheme. Without it Linux 2.1+ tends to suffer badly from
> ethernet congestion by colliding with the own acks, probably because
Ingo Molnar writes:
>
> On Tue, 30 Jan 2001, jamal wrote:
>
> > > - is this UDP or TCP based? (UDP i guess)
> > >
> > TCP
>
> well then i'd suggest to do:
>
> echo 10 10 10 > /proc/sys/net/ipv4/tcp_wmem
>
> does this make any difference?
For the last week I've been benchmar
In article <[EMAIL PROTECTED]> you wrote:
> On Tue, Jan 30, 2001 at 02:17:57PM -0800, David S. Miller wrote:
> 8.5MB/sec sounds like half-duplex 100baseT.
> No; I'm 100% its FD; HD gives 40k/sec TCP because of collisions and
> such like.
> Positive you are running at full duplex all th
Chris Wedgwood writes:
> There are ... ... 3 switches between four switches in
> between, mostly linked via GE. I'm not sure if latency might be an
> issue here, is it was critical I can imagine 10 km of glass might be
> a problem but it's not _that_ far...
Other than this, I don't know wha
Andrew Morton writes:
> The box has 130 mbyte/sec memory write bandwidth, so saving
> a copy should save 10% of this. (Wanders away, scratching
> head...)
Are you sure your measurment program will account properly
for all system cycles spent in softnet processing? This is
where the bulk of
Chris Wedgwood writes:
> What server are you using here? Using NetApp filers I don't see
> anything like this, probably only 8.5MB/s at most and this number is
> fairly noisy.
8.5MB/sec sounds like half-duplex 100baseT. Positive you are running
at full duplex all the way to the netapp, and i
Andrew Morton writes:
> BTW: can you suggest why I'm not observing any change in NFS client
> efficiency?
As in "filecopy speed" or "cpu usage while copying a file"?
The current fragmentation code eliminates a full SKB allocation and
data copy on the NFS file data receive path in the client,
The "more expensive" write/send in zerocopy is a known cost of paged
SKBs. This cost may be decreased a bit with some fine tuning, but not
eliminated entirely.
What do we get for this cost?
Basically, the big win is not that the card checksums the packet.
We could get that for free while copyi
On Mon, 29 Jan 2001, jamal wrote:
> > 11.5kBps, quite consistently.
>
> This gige card is really sick. Are you sure? Please double check.
Umm.. the starfire chipset is 100Mbit only. So 11.5MBps (sorry, that was a
typo, it's mega not kilo) is really all I'd expect out of it.
Ion
--
It is bet
On Mon, 29 Jan 2001, Ion Badulescu wrote:
> 11.5kBps, quite consistently.
This gige card is really sick. Are you sure? Please double check.
>
> I've tried it, but I'm not really sure what I can report. ttcp's
> measurements are clearly misleading, so I used Andrew's cyclesoak instead.
The tt
On Sat, 27 Jan 2001, jamal wrote:
> > starfire:
> > 2.4.1-pre10+zerocopy, using sendfile(): 9.6% CPU
> > 2.4.1-pre10+zerocopy, using read()/write(): 18.3%-29.6% CPU * why so much
>variance?
> >
>
> What are your throughput numbers?
11.5kBps, quite consistently.
BTW, Andrew
> I'll give this a shot later. Can you try with the sendfiled-ttcp?
> http://www.cyberus.ca/~hadi/ttcp-sf.tar.gz
I guess I need to "leverage" some bits for netperf :)
WRT getting data with links that cannot saturate a system, having
something akin to the netperf service demand measure can help.
> > Throughput: 100Mbps is really nothing. Linux never had a problem with
> > 4-500Mbps file serving. So throughput is an important number. so is
> > end to end latency, but in file serving case, latency might
> > not be a big deal so ignore it.
>
> If I try to route more than 40mbps (40% line
> Throughput: 100Mbps is really nothing. Linux never had a problem with
> 4-500Mbps file serving. So throughput is an important number. so is
> end to end latency, but in file serving case, latency might
> not be a big deal so ignore it.
If I try to route more than 40mbps (40% line utilization)
Thus spake Felix von Leitner ([EMAIL PROTECTED]):
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.
I started one now.
It's at http://www.fefe.de/linuxeth/, but there is not much content yet.
Please contribute!
Felix
-
To unsubscribe from this li
On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote:
> Thus spake Andrew Morton ([EMAIL PROTECTED]):
> > Conclusions:
>
> > For a NIC which cannot do scatter/gather/checksums, the zerocopy
> > patch makes no change in throughput in all case.
>
> > For a NIC which can do scatt
jamal wrote:
>
> PS:- can you try it out with the ttcp testcode i posted?
Yup. See below. The numbers are almost the same as
with `zcs' and `zcc'.
The CPU utilisation code which was in `zcc' has been
broken out into a standalone tool, so the new `cyclesoak'
app is a general-purpose system loa
On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote:
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.
>
> I have a tulip NIC because a few years ago that apparently was the NIC
> of choice. It has good multicast (which is important
On Sun, 28 Jan 2001, Felix von Leitner wrote:
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.
> I have a tulip NIC because a few years ago that apparently was the NIC
> of choice. It has good multicast (which is important to me), but AFAIK
> it h
Thus spake Andrew Morton ([EMAIL PROTECTED]):
> Conclusions:
> For a NIC which cannot do scatter/gather/checksums, the zerocopy
> patch makes no change in throughput in all case.
> For a NIC which can do scatter/gather/checksums, sendfile()
> efficiency is improved by 40% and send() effi
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > 2.4.1-pre10+zercopy, using read()/write(): 38.1% CPU
>
> write() on zc card is worse than normal write() by definition.
> It generates split buffers.
yes. The figures below show this. Disabling SG+checksums speeds
up write() and send().
> Split
On Sun, 28 Jan 2001, Andrew Morton wrote:
> jamal wrote:
> >
> > ..
> > It is also useful to have both client and server stats.
> > BTW, since the laptop (with the 3C card) is the client, the SG
> > shouldnt kick in at all.
>
> The `client' here is doing the sendfiling, so yes, the
> gathering
jamal wrote:
>
> ..
> It is also useful to have both client and server stats.
> BTW, since the laptop (with the 3C card) is the client, the SG
> shouldnt kick in at all.
The `client' here is doing the sendfiling, so yes, the
gathering occurs on the client.
> ...
> > The test tool is, of course,
On Sat, 27 Jan 2001, Ion Badulescu wrote:
>
> 750MHz PIII, Adaptec Starfire NIC, driver modified to use hardware sg+csum
> (both Tx/Rx), and Intel i82559 (eepro100), no hardware csum support,
> vanilla driver.
>
> The box has 512MB of RAM, and I'm using a 100MB file, so it's entirely cached.
>
On Sat, 27 Jan 2001, Andrew Morton wrote:
> (Please keep netdev copied, else Jamal will grump at you, and
> you don't want that).
>
Thanks, Andrew ;-> Isnt netdev where networking stuff should be
discussed? I think i give up and will join lk, RSN ;->
> The kernels which were tested were 2.4.
Ion Badulescu wrote:
>
> On Sat, 27 Jan 2001 19:19:01 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > The figures I quoted for the no-hw-checksum case were still
> > using scatter/gather. That can be turned off as well and
> > it makes it a tiny bit quicker.
>
> Hmm. Are you sure the dif
Ion Badulescu wrote:
>
> 2.4.1-pre10+zerocopy, using read()/write(): 18.3%-29.6% CPU * why so
>much variance?
The variance is presumably because of the naive read/write
implementation. It sucks in 16 megs and writes out out again.
With a 100 megabyte file you'll get aliasing effect
On Sat, 27 Jan 2001 19:19:01 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote:
> The figures I quoted for the no-hw-checksum case were still
> using scatter/gather. That can be turned off as well and
> it makes it a tiny bit quicker.
Hmm. Are you sure the differences are not just noise? Unless yo
On Sat, 27 Jan 2001 16:45:43 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote:
> The client is a 650 MHz PIII. The NIC is a 3CCFE575CT Cardbus 3com.
> It supports Scatter/Gather and hardware checksums. The NIC's interrupt
> is shared with the Cardbus controller, so this will impact throughput
> s
Aaron Lehmann wrote:
>
> On Sat, Jan 27, 2001 at 04:45:43PM +1100, Andrew Morton wrote:
> > 2.4.1-pre10-vanilla, using read()/write(): 34.5% CPU
> > 2.4.1-pre10+zercopy, using read()/write(): 38.1% CPU
>
> Am I right to be bothered by this?
>
> The majority of Unix network traffic is
On Sat, Jan 27, 2001 at 04:45:43PM +1100, Andrew Morton wrote:
> 2.4.1-pre10-vanilla, using read()/write(): 34.5% CPU
> 2.4.1-pre10+zercopy, using read()/write(): 38.1% CPU
Am I right to be bothered by this?
The majority of Unix network traffic is handled with read()/write().
Why would
41 matches
Mail list logo
