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
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
TED]>, 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 sendfile makes sense for the
. 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 PROTE
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
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: sendfile+
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
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+zerocopy: fairly sexy
> " " == 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
"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
"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
" " == 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 using
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+zerocopy: fairly sexy (nothing to do with ECN)
"David S. Miller" wrote:
...
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 larger
: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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
David Lang wri
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
. 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 PROTECTED]
Subject: Re: sendfile+zerocopy: fairly sexy (not
: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
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 us
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 affected
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
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
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 it
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
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
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
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
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,
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,
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 if
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
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 the way
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
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
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
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,
> 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
> > 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)
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)
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
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.
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's new
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 ttcp
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
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
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
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
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()
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()
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 has
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 to
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 load
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
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
[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().
>
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
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
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
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
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
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
>
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 you
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 differences are
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
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.
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 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 occurs on the
[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 buffers
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
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
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 handled
75 matches
Mail list logo
