On Mon, 14 Mar 2016, Yuchung Cheng wrote:
> On Thu, Mar 3, 2016 at 10:06 AM, Bendik Rønning Opstad
> wrote:
> >
> > Redundant Data Bundling (RDB) is a mechanism for TCP aimed at reducing
> > the latency for applications sending time-dependent data.
...
> > diff --git a/Documentation/networking/ip
Hi Herbert,
On Fri, 15 Feb 2008, Herbert Xu wrote:
> On Tue, Feb 12, 2008 at 06:08:28PM -0800, David Miller wrote:
> >
> > > [IPV6]: Fix IPsec datagram fragmentation
> >
> > Applied, and I'll queue this up to -stable as well.
>
> Sorry, David Stevens just told me that it doesn't work as intende
; >> the PCI-e x1 bus past its limits. However the evidence seems to show
> >> otherwise:
> >>
> >> (1) Bill Fink has reported the same problem on a NIC with a 133 MHz
> >> 64-bit PCI connection. That connection can transfer data at 8Gb/s.
> &g
Hi Bruce,
On Thu, 31 Jan 2008, Bruce Allen wrote:
> > I see similar results on my test systems
>
> Thanks for this report and for confirming our observations. Could you
> please confirm that a single-port bidrectional UDP link runs at wire
> speed? This helps to localize the problem to the T
On Wed, 30 Jan 2008, SANGTAE HA wrote:
> On Jan 30, 2008 5:25 PM, Bruce Allen <[EMAIL PROTECTED]> wrote:
> >
> > In our application (cluster computing) we use a very tightly coupled
> > high-speed low-latency network. There is no 'wide area traffic'. So it's
> > hard for me to understand why any
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
> Hi,
> I am using linux 2.6.20 and am trying to limit the receiver window
> size for a TCP connection. However, it seems that auto tuning is not
> turning itself off even after I use the syscall
>
> rwin=65536
> setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
On Fri, 21 Dec 2007, Ilpo Järvinen wrote:
> On Fri, 21 Dec 2007, Bill Fink wrote:
>
> > On Fri, 21 Dec 2007, Bill Fink wrote:
> >
> > > Or perhaps even:
> > >
> > > /* Ok, it looks like it is advisable to defer. */
> > > tp->tso_d
On Fri, 21 Dec 2007, Bill Fink wrote:
> Or perhaps even:
>
> /* Ok, it looks like it is advisable to defer. */
> tp->tso_deferred = jiffies;
>
> /* need to return a non-zero value to defer, which means won't
>* defer if jiffies == 0 b
On Fri, 21 Dec 2007, YOSHIFUJI Hideaki wrote:
> In article <[EMAIL PROTECTED]> (at Fri, 21 Dec 2007 11:24:54 +0900), "Satoru
> SATOH" <[EMAIL PROTECTED]> says:
>
> > 2007/12/21, Jarek Poplawski <[EMAIL PROTECTED]>:
> > > Jarek Poplawski wrote, On 12/20/2007 09:24 PM:
> > > ...
> > >
> > > > but
On Fri, 21 Dec 2007, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Fri, 21 Dec 2007 17:29:27 +0800
>
> > On Fri, Dec 21, 2007 at 01:27:20AM -0800, David Miller wrote:
> > >
> > > It's two shifts, and this gets scheduled along with the other
> > > instructions on many cpus so
On Thu, 20 Dec 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Thu, 20 Dec 2007 13:40:51 +0200 (EET)
>
> > [PATCH] [TCP]: Fix TSO deferring
> >
> > I'd say that most of what tcp_tso_should_defer had in between
> > there was dead code because of this.
> >
> > Signed
On Fri, 14 Dec 2007, Andrew Morton wrote:
> On Fri, 14 Dec 2007 15:39:26 -0500
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] wrote:
> > > From: Randy Dunlap <[EMAIL PROTECTED]>
> > >
> > > Make E1000E default to the same kconfig setting as E1000. So people's
> > > machiens do
On Sat, 08 Dec 2007, Patrick McHardy wrote:
> Patrick McHardy wrote:
> > Stephen Hemminger wrote:
> >>
> >> +struct tc_rlim_qopt
> >> +{
> >> +__u32 limit;/* fifo limit (packets) */
> >> +__u32rate;/* bits per sec */
> >>
> >
> > This seems a bit small, 512mbit is
On Tue, 20 Nov 2007, Andrew Gallatin wrote:
> David Miller wrote:
> > From: Andrew Gallatin <[EMAIL PROTECTED]>
> > Date: Tue, 20 Nov 2007 06:47:57 -0500
> >
> >> David Miller wrote:
> >> > From: Herbert Xu <[EMAIL PROTECTED]>
> >> > Date: Tue, 20 Nov 2007 14:09:18 +0800
> >> >
> >> >>
On Mon, 19 Nov 2007, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Mon, 19 Nov 2007 16:29:33 +0100
>
> > > > >
> > > > > All of our options suck, we just have to choose the least sucking one
> > > > > and right now to me that's decrementing the counter as much as I
> > > > >
On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:
> Hello!
>
> > Is there a reason that the target hardware address isn't the target
> > hardware address?
>
> It is bound only to the fact that linux uses protocol address
> of the machine, which responds. It would be highly confusing
> (more than conf
On Fri, 16 Nov 2007, David Miller wrote:
> From: "Jonas Danielsson" <[EMAIL PROTECTED]>
> Date: Fri, 16 Nov 2007 09:30:11 +0100
>
> > 2007/11/16, David Miller <[EMAIL PROTECTED]>:
> > > From: "Jonas Danielsson" <[EMAIL PROTECTED]>
> > > Date: Thu, 15 Nov 2007 22:40:13 +0100
> > >
> > > > Is there
On Mon, 29 Oct 2007, Hideo AOKI wrote:
> This patch added /proc/sys/net/udp_rmem and /proc/sys/net/udp_rmem.
> Each UDP packet is drooped when the number of pages for socket buffer
> is beyond the limit and the socket already consumes minimum buffer.
I think you meant /proc/sys/net/ipv4/udp_{r,w}
On Thu, 18 Oct 2007, Matthew Faulkner wrote:
> Hey all
>
> I'm using netperf to perform TCP throughput tests via the localhost
> interface. This is being done on a SMP machine. I'm forcing the
> netperf server and client to run on the same core. However, for any
> packet sizes below 523 the throu
On Sat, 13 Oct 2007, Stefan Richter wrote:
> Roland Dreier wrote:
> > There are a few changes to the bonding driver pending that will add
> > support for bonding IP-over-InfiniBand interfaces. IPoIB also cannot
> > change its HW address, so the patches address that issue.
> >
> > Once those patc
On Tue, 09 Oct 2007, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Tue, 09 Oct 2007 17:56:46 -0400
>
> > if the h/ware queues are full because of link pressure etc, you drop. We
> > drop today when the s/ware queues are full. The driver txmit lock takes
> > place of the qdisc queu
Tangential aside:
On Tue, 02 Oct 2007, Rick Jones wrote:
> *) depending on the quantity of CPU around, and the type of test one is
> running,
> results can be better/worse depending on the CPU to which you bind the
> application. Latency tends to be best when running on the same core as takes
On Tue, 02 Oct 2007, jamal wrote:
> On Tue, 2007-02-10 at 00:25 -0400, Bill Fink wrote:
>
> > One reason I ask, is that on an earlier set of alternative batching
> > xmit patches by Krishna Kumar, his performance testing showed a 30 %
> > performance hit for TCP for a s
On Mon, 01 Oct 2007, jamal wrote:
> On Mon, 2007-01-10 at 00:11 -0400, Bill Fink wrote:
>
> > Have you done performance comparisons for the case of using 9000-byte
> > jumbo frames?
>
> I havent, but will try if any of the gige cards i have support it.
>
> As a
On Sun, 30 Sep 2007, jamal wrote:
> This patch adds the usage of batching within the core.
>
> cheers,
> jamal
> [sep30-p2of3 text/plain (6.8KB)]
> [NET_BATCH] net core use batching
>
> This patch adds the usage of batching within the core.
> The same test methodology used in introducing txl
On Wed, 19 Sep 2007, L F wrote:
> Well,
> the issue seems to have gone away as of this morning, but I am
> somewhat unsure as to why.
> Placement of some things were modified so as to allow shorter cables.
> Now there are 3' CAT6 cables everywhere except for the 15' cable
> between the two switche
On Wed, 19 Sep 2007, L F wrote:
> I have one further question: what should I be doing with the TSO and
> flow control? As of now, TSO is on but flow control is off.
> I'd like to thank everyone who helped and I'll be trying to see if the
> realtek integrated NIC works next.
Just my personal opini
On Tue, 18 Sep 2007, Florian Weimer wrote:
> * Urs Thuermann:
>
> > How can a corrupted frame pass the TCP checksum check?
>
> The TCP/IP checksums are extremely weak. If the corruption is due to
> defective SRAM or something like that, it's likely that it causes an
> error pattern which is 16-
On 18 Sep 2007, Urs Thuermann wrote:
> Bill Fink <[EMAIL PROTECTED]> writes:
>
> > It may also be a useful test to disable hardware TSO support
> > via "ethtool -K ethX tso off".
>
> All suggestions here on the list, i.e. checking for flow control,
>
On 17 Sep 2007, Urs Thuermann wrote:
> Thomas Gleixner <[EMAIL PROTECTED]> writes:
>
> > Please do, having the patch in mail makes it easier to review and to
> > comment.
>
> OK, here it is:
One more typo.
> This patch adds documentation for the PF_CAN protocol family.
>
> Signed-off-by: Oliv
On Mon, 17 Sep 2007, Brandeburg, Jesse wrote:
> L F wrote:
> > On 9/17/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> >> The statistic we were looking at _will_ increase when running in
> >> half duplex, but if it increases when running in full duplex might
> >> indicate a hardware failure. Probably y
On Fri, 14 Sep 2007, L F wrote:
> > can you describe your setup a bit more in detail? you're writing from a
> > linux
> > client to a windows smb server? or even to a linux server? which end sees
> > the
> > connection drop? the samba server? the samba linux client?
> Certainly.
> I have a LAN,
On Mon, 27 Aug 2007, jamal wrote:
> On Sun, 2007-26-08 at 19:04 -0700, David Miller wrote:
>
> > The transfer is much better behaved if we ACK every two full sized
> > frames we copy into the receiver, and therefore don't stretch ACK, but
> > at the cost of cpu utilization.
>
> The rx coalescing
On Fri, 07 Sep 2007, jamal wrote:
> On Fri, 2007-07-09 at 10:31 +0100, James Chapman wrote:
> > Not really. I used 3-year-old, single CPU x86 boxes with e100
> > interfaces.
> > The idle poll change keeps them in polled mode. Without idle
> > poll, I get twice as many interrupts as packets, one
On Fri, 07 Sep 2007, Jay Vosburgh wrote:
> Rick Jones <[EMAIL PROTECTED]> wrote:
> [...]
> >> Note that this out of order delivery occurs when both the
> >> sending and receiving systems are utilizing a multiple
> >> interface bond. Consider a configuration in which a
> >>
On Wed, 05 Sep 2007, Jesper Dangaard Brouer wrote:
> On Tue, 2007-09-04 at 13:40 -0400, Bill Fink wrote:
> > On Tue, 04 Sep 2007, Patrick McHardy wrote:
> >
> > > Bill Fink wrote:
> > > > On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:
> > > &g
On Tue, 04 Sep 2007, Patrick McHardy wrote:
> Bill Fink wrote:
> > On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:
> >
> >>On Sat, 1 Sep 2007, Patrick McHardy wrote:
> >>>
> >>>It still won't work properly with TSO (TBF for example already dr
On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:
> On Sat, 1 Sep 2007, Patrick McHardy wrote:
>
> > Jesper Dangaard Brouer wrote:
> >> commit 6fdc0f061be94f5e297650961360fb7a9d1cc85d
> >> Author: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
> >> Date: Thu Aug 30 17:53:42 2007 +0200
> >>
> >> [N
On Fri, 24 Aug 2007, John Heffner wrote:
> Bill Fink wrote:
> > Here you can see there is a major difference in the TX CPU utilization
> > (99 % with TSO disabled versus only 39 % with TSO enabled), although
> > the TSO disabled case was able to squeeze out a little extra per
On Sat, 25 Aug 2007, Herbert Xu wrote:
> On Fri, Aug 24, 2007 at 02:25:03PM -0700, David Miller wrote:
> >
> > My hunch is that even if in the non-TSO case the TX packets were all
> > back to back in the cards TX ring, TSO still spits them out faster on
> > the wire.
>
> If this is the case then
On Fri, 24 Aug 2007, jamal wrote:
> On Thu, 2007-23-08 at 23:18 -0400, Bill Fink wrote:
>
> [..]
> > Here you can see there is a major difference in the TX CPU utilization
> > (99 % with TSO disabled versus only 39 % with TSO enabled), although
> > the TSO disabled cas
On Thu, 23 Aug 2007, Rick Jones wrote:
> jamal wrote:
> > [TSO already passed - iirc, it has been
> > demostranted to really not add much to throughput (cant improve much
> > over closeness to wire speed) but improve CPU utilization].
>
> In the one gig space sure, but in the 10 Gig space, TSO on
On Wed, 15 Aug 2007, Satyam Sharma wrote:
> (C)
> $ cat tp3.c
> int a;
>
> void func(void)
> {
> *(volatile int *)&a = 10;
> *(volatile int *)&a = 20;
> }
> $ gcc -Os -S tp3.c
> $ cat tp3.s
> ...
> movl$10, a
> movl$20, a
> ...
I'm curious about one minor tangential point. W
On Fri, 3 Aug 2007, Auke Kok wrote:
> This patch adds support for the Intel 82598 PCI-Express 10GbE
> chipset. Devices will be available on the market soon.
>
> This version of the driver is largely the same as the last release:
>
> * Driver uses a single RX and single TX queue, each using 1 MSI
On Tue, 24 Jul 2007, Sridhar Samudrala wrote:
> On Tue, 2007-07-24 at 10:13 -0700, Rick Jones wrote:
> > > Rick,
> > >
> > > I don't see any way around this. For example, on one of my test
> > > systems, I have the following link local routes:
> > >
> > > chance% netstat -A inet6 -rn | grep fe8
On Mon, 23 Jul 2007, Rick Jones wrote:
> Folks -
>
> People running netperf have reported that they have trouble with IPv6 under
> Linux. Specifically, wereas the use of link-local IPv6 addresses "just
> works"
> in netperf under a number of "other OSes" they do not under Linux. I'm
> ass-u
Hi John,
On Wed, 18 Jul 2007, [EMAIL PROTECTED] wrote:
> On Wed, 18 Jul 2007, Francois Romieu wrote:
>
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> > [...]
> >> Anyone have any suggestions for solving this problem?
> >
> > Try 2.6.23-rc1 when it is published or apply against 2.6.22 one of:
> >
On Wed, 13 Jun 2007, David Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 13 Jun 2007 11:31:49 -0700
>
> > Maybe it is time to remove BIC?
>
> I don't see any compelling reason, the same could be said
> of the other experimental protocols we include in the tree.
I agre
On Tue, 12 Jun 2007, Stephen Hemminger wrote:
> On Tue, 12 Jun 2007 15:12:58 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Bill Fink <[EMAIL PROTECTED]>
> > Date: Wed, 16 May 2007 02:44:09 -0400
> >
> > > [EMAIL PROTECTED]
etransmited
20936 fast retransmits
4503 retransmits in slow start
4 sack retransmits failed
It then only took 2.14 seconds to transfer 1 GB of data.
That's all for now.
-Bill
> Thanks,
> Sangtae
>
>
> On 5/12/0
On Thu, 10 May 2007, Injong Rhee wrote:
> Oops. I thought Bill was using 2.6.20 instead of 2.6.22 which should contain
> our latest update.
I am using 2.6.20.7.
> Regarding slow start behavior, the latest version should not change though.
> I think it would be ok to change the slow start of bi
9052 Mbps
> 844.3655 MB / 1.00 sec = 7082.6544 Mbps
> 842.2671 MB / 1.00 sec = 7065.7169 Mbps
> 839.9204 MB / 1.00 sec = 7045.8335 Mbps
> 840.1780 MB / 1.00 sec = 7048.3114 Mbps
> 834.1475 MB / 1.00 sec = 6997.4270 Mbps
> 835.5972 MB / 1.00 sec = 7009.31
6.2622 Mbps 90 %TX 46 %RX
[EMAIL PROTECTED] ~]# netstat -s | grep -i retrans
0 segments retransmited
-Thanks a lot!
-Bill
> Regards,
> Sangtae
>
>
> On 5/6/07, Bill Fink <[EMAIL PROTECTED]> wrote:
The initial TCP slow start on 2.6.20.7 cubic (and to a lesser
extent bic) seems to be way too slow. With an ~80 ms RTT, this
is what cubic delivers (thirty second test with one second interval
reporting and specifying a socket buffer size of 60 MB):
[EMAIL PROTECTED] ~]# netstat -s | grep -i retr
On Mon, 30 Apr 2007, James Chapman wrote:
> Signed-off-by: James Chapman <[EMAIL PROTECTED]>
>
> Index: linux-2.6.21/Documentation/networking/l2tp.txt
> ===
> --- /dev/null
> +++ linux-2.6.21/Documentation/networking/l2tp.txt
> @@ -0
On Mon, 30 Apr 2007, Rick Jones wrote:
> > What version of the myri10ge driver is this? With the 1.2.0 version
> > that comes with the 2.6.20.7 kernel, there is no myri10ge_lro module
> > parameter.
> >
> > [EMAIL PROTECTED] ~]# modinfo myri10ge | grep -i lro
> > [EMAIL PROTECTED] ~]#
> >
> >
On Fri, 27 Apr 2007, Rick Jones wrote:
> Bryan Lawver wrote:
> > I had so much debugging turned on that it was not the "slowing of the
> > traffic" but the "non-coelescencing" that was the remedy. The NIC is a
> > MyriCom NIC and these are easy options to set.
>
> As chance would have it, I've
On Thu, 26 Apr 2007 20:54:36 +0100, David Howells wrote:
> Provide AF_RXRPC sockets that can be used to talk to AFS servers, or serve
> answers to AFS clients. KerberosIV security is fully supported. The patches
> and some example test programs can be found in:
>
> http://people.redhat.co
On Thu, 26 Apr 2007, Ilpo Järvinen wrote:
> On Thu, 26 Apr 2007, Chuck Ebbert wrote:
>
> > Ilpo Järvinen wrote:
> > > ...I'm unsure how to continue the investigation from this point onward
> > > and asking for ideas/suggestions or how to rule out more possibilities...
> > > Or is there some kno
On Thu, 01 Mar 2007, Ben Greear wrote:
> Ben Greear wrote:
>
> I am sending udp packets through ppp400, and I see them appear on ppp401
> as expected.
>
> The thing that is bothering me is that all I see on rddVR4 (172.1.2.1)
> is arps for 172.1.2.2, but the 'tell' IP is that of the
> originat
On Thu, 09 Nov 2006, David Miller wrote:
> From: Brian Haley <[EMAIL PROTECTED]>
> Date: Thu, 09 Nov 2006 12:32:18 -0500
>
> > Al Viro wrote:
> > > AFAICS, the rules are:
> > >
> > > (1) checksum is 16-bit one's complement of the one's complement sum of
> > > relevant 16bit words.
> > >
> > >
FYI,
At least here, I received two copies of patch 9/14 and no copy
of patch 10/14.
-Bill
On Fri, 13 Oct 2006 13:37:50 +0200, Per Liden wrote:
> From: Allan Stephens <[EMAIL PROTECTED]>
>
> This patch tivially re-orders the entries in TIPC's li
On Fri, 6 Oct 2006 17:15:56 +0200, Joerg Roedel wrote:
> +config IPV6_SIT
> + tristate "IPv6: IPv6-in-IPv4 tunnel (SIT driver)"
> + depends on IPV6
> + default y
> + ---help---
> + Tunneling means encapsulating data of one protocol type within
> + another protocol and s
On Fri, 25 Aug 2006, Jeff Kirsher wrote:
> On 8/25/06, Bill Fink <[EMAIL PROTECTED]> wrote:
> >
> > I agree. Something like:
> >
> > ethtool -s ethx auto on advertise mode1+mode2+...+moden
> >
> > For example:
> >
> > ethto
On Thu, 24 Aug 2006, Michael Chan wrote:
> Jeff Kirsher wrote:
>
> > The old way of setting autonegotiation was using the
> > following command:
> > ethtool -s ethx speed 100 duplex full auto on
> > now the command would be
> > ethtool -s ethx auto on advertise 0x08
> > both commands would resul
On Mon, 21 Aug 2006, Johannes Berg wrote:
> Please review carefully, the task was so boring that I might have made
> stupid mistakes.
> ---
> This huge patch changes d80211 to treat pointers as "extended booleans",
> using "if (!ptr)" and "if (ptr)" instead of comparisons with NULL.
>
> Signed-of
On Tue, 15 Aug 2006, Evgeniy Polyakov wrote:
> On Tue, Aug 15, 2006 at 03:49:28PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
>
> > It could if you can provide adequate detection of memory pressure and
> > fallback to a degraded mode within the same allocator/stack and can
> > guarantee l
On Sun, 25 Jun 2006, Harry Edmon wrote:
> I understand the saying "beggars can't be choosers", but I have heard nothing
> on
> this issue since June 19th. Does anyone have any ideas on what is going on?
> Is
> there more information I can collect that would help diagnose this problem?
> An
On Thu, 25 May 2006, Brent Cook wrote:
> On Thursday 25 May 2006 02:23, Bill Fink wrote:
> > On Wed, 24 May 2006, Jeff Garzik wrote:
> > > Brent Cook wrote:
> > > > Note that this is just clearing the hardware statistics on the
> > > > interface, and woul
On Wed, 24 May 2006, Phil Dibowitz wrote:
> Right. I think the point here is that it does _NOT_ inherently break
> things. If you don't like the behavior, don't run "ethtool -z eth0",
> it's that simple.
>
> A co-worker suggested today, that maybe it'd appease people if the final
> ethtool patch
On Wed, 24 May 2006, Jeff Garzik wrote:
> Brent Cook wrote:
> > Note that this is just clearing the hardware statistics on the interface,
> > and
> > would not require any kind of atomic_increment addition for interfaces that
> > support that. It would be kind-of awkward to implement this on dr
On Thu, 30 Mar 2006, David S. Miller wrote:
> From: Bill Fink <[EMAIL PROTECTED]>
> Date: Fri, 31 Mar 2006 01:58:35 -0500
>
> > I don't think it makes perfect sense. If there's overhead, fine go
> > ahead and add the overhead, but do it under the covers an
On Thu, 30 Mar 2006, Mark Butler wrote:
> David S. Miller wrote:
>
> >This has been this way for centuries and it's the correct behavior.
> >
> >We double it on the way in to account for "struct sk_buff" etc.
> >overhead, applications assume that the SO_RCVBUF setting they make
> >will allow that
On Fri, 24 Mar 2006, walt wrote:
> Michael Chan wrote:
> > Walt wrote:
> >
> >> Nope, it was the second one: Skip phy power down...
>
> > It doesn't make sense. This code should have no effect on your
> > 5702. With or without this patch, the 5702 will be powered down
> > the same with tg3_writ
On Thu, 23 Mar 2006, walt wrote:
> Hi,
> I emailed Dave Miller, who re-directed me to this mail list.
>
> I update from Linus's git repository every morning, and today
> I got this error:
>
> tg3.c:v3.53 (Mar 22, 2006)
> PCI: Enabling device :00:09.0 (0014 -> 0016)
> ACPI: PCI Interrupt
On Tue, 3 Jan 2006, Stephen Hemminger wrote:
> On Wed, 28 Dec 2005 22:35:50 -0500
> Bill Fink <[EMAIL PROTECTED]> wrote:
>
> > Would the following patch be at all useful for the 2.6.14.x stable
> > series, since enabling TSO there causes a 40% or greater TCP performanc
On Thu, 15 Dec 2005, Stephen Hemminger wrote:
> On Fri, 16 Dec 2005 03:26:31 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Dec 15, 2005 at 08:35:32PM -0500, Bill Fink wrote:
> > > On Fri, 16 Dec 2005, Andi Kleen wrote:
> > >
> > > &
On Fri, 16 Dec 2005, I wrote:
> Is it expected behavior that ARP replies would be generated for interfaces
> on a different network than the IP address in the ARP request (note I
> don't have Proxy ARP enabled), or is this a bug? To me it would seem
> to be a bug.
Answering my own question for t
Sometimes when doing my 10-GigE testing, I would get results like
the following:
chance% nuttcp -w2m 192.168.88.8
1184.3614 MB / 10.04 sec = 989.8235 Mbps 12 %TX 9 %RX
This seemed to indicate it was using one of the GigE interfaces
rather than the 10-GigE interface. Both chance and chance4 ha
On Thu, 15 Dec 2005, David S. Miller wrote:
> From: Bill Fink <[EMAIL PROTECTED]>
> Date: Thu, 15 Dec 2005 20:35:32 -0500
>
> > chance% nuttcp -w2m 192.168.88.8
> > 6299.0625 MB / 10.01 sec = 5278.6065 Mbps 100 %TX 74 %RX
> > chance% nuttcp -r -w2m 192.168.88
On Fri, 16 Dec 2005, Andi Kleen wrote:
> > It appears that it is getting CPU starved for some reason (note the
> > 43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
> > 2.6.12.6 case).
>
> What happens when you turn off tso in ethtool?
Thanks!!! That did the trick.
[EMAIL PROT
Oops. I forgot to attach my 2.6.12.6 kernel config.
-Bill
config-2.6.12.bz2
Description: BZip2 compressed data
Hi,
We use dual 3.06 GHz Xeon PC servers, with 1 GB memory, 133-MHz/64-bit
PCI-X bus, and Intel PRO/10GbE 10-GigE NIC, as 10-GigE network performance
measurement and troubleshooting systems. With the 2.6.12.6 kernel we
get consistently excellent network performance, both TCP and UDP.
Here's a sa
83 matches
Mail list logo
