This is in regards to an inheritance on your surname, reply back using your
email address, stating your full name for more details. Reply to email for
info. Email me here ( ger...@dr.com )
How you doing today? I hope you are doing well. My name is Jones, from the US.
I'm in Syria right now fighting ISIS. I want to get to know you better, if I
may be so bold. I consider myself an easy-going man, and I am currently looking
for a relationship in which I feel loved. Please te
tions as to the number of 10 KByte/s connections
you could support. It would be a bit of handwaving, but give yourself
say a 20% pad and you'll probably be OK.
rick jones
>
> Kind Regards
>
> James
> -
> To unsubscribe from this list: send the line "unsubscribe n
east one of
your DMA allocation retries succeed.
While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially
if the IOMMU fills frequently (for some suitable definiton of
frequently), is it really worth the effort to save say an ACK?
rick jones
-
To unsubscribe from this lis
packets queued
What implications does c have for something like tcpdump?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
nt paths through the system. No issues about reordering, but
perhaps some on cache lines going hither and yon.
The question boils down to - Should the application (via the scheduler)
dictate where its connections are processed, or should the connections
dictate where the application runs?
rick jon
for load, not the number of interrupts. (for network
interrupts obviously)
And hopefully some knowledge of NUMA so it doesn't "balance" the
interrupts of a NIC to some far-off (topology-wise) CPU...
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netd
the topologically closest CPU. (Not that
some irqbalancer programs recognize that just yet :)
Now, if both CPU0 and CPU1 are saturated it might make sense to put some
interrupts on 2 and/or 3. One of those fun "it depends" situations.
rick jones
-
To unsubscribe from this list: send t
Jay -
So, where do you and I stand wrt the proposed changes to bonding.txt? Are we at
an impass?
sincerely,
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Past performance is no guarantee of current correctness :) And over an
Ethernet, there will be a very different set of both timings and TCP
segment sizes compared to loopback.
My guess is that you will find setting the lo
Jay Vosburgh wrote:
Rick Jones <[EMAIL PROTECTED]> wrote:
So, where do you and I stand wrt the proposed changes to bonding.txt? Are
we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change
support 802.3ad.
8. Where does a bonding device get its MAC address from?
Not part of your change, but since you are editing the section, drop the
"from" in the section title, or perhaps put it at the beginning so we
don't have a dangling whatchamacallit.
rick jones
-
To unsu
the current value of the MRRS get displayed in lspci output? It
wouldn't be a slam dunk, but if someone were looking at that and saw the
value large they might make an educated guess.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
In some experiements a while back I thought I saw that LRO on the
receiver was causing him to send fewer ACKs already? IIRC that was with
a Myricom card, perhaps I was fooled by it's own ACK LRO it was doing.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev
On Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen wrote:
> There seems to be rough consensus that the kernel currently has too many
> exported symbols. A lot of these exports are generally usable utility
> functions or important driver interfaces; but another large part are
> functions
On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
> - does it cause bugs?
> - or are you just worried about "evil modules"?
To clarify something here,
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of TOE comes to mind right away.
rick jones
-
To unsubscribe from this list: send
On Tue, Nov 27, 2007 at 10:09:42PM +0100, Adrian Bunk wrote:
> On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote:
> > On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
> >
> > > 1) Why is everyone so concerned that expo
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling
Could the corruption be seen in a tcpdump trace prior to transmission
(ie taken on the sender) or was it only seen after the data passed out
the NIC?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majo
us, one at a time request/response, never tries
to have both sides talking at the same time.
Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.
rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messa
r the
alloc_tbufs(), but I feel if a real interrupt occured, this diff would
stand more chance of doing the right thing.
Comments?
Dave
Delay irq registration until after we've allocated ring buffers,
otherwise DEBUG_SHIRQ will complain.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]&g
On Wed, Dec 12, 2007 at 05:53:43PM +0100, Thomas Klein wrote:
> +static void ehea_update_adapter_handles(struct ehea_adapter *adapter)
> +{
> +int i, k;
> +int j = 0;
> +
> +memset(adapter->res_handles, sizeof(adapter->res_handles), 0);
arguments wrong way around.
Dave
Robert Iakobashvili wrote:
Hi,
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones <[EMAIL PROTECTED]>
wrote:
> I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
> But I am hitting a max limit of 4000 IP address . Seems like there
is a
> limiting variable
Ok I have tried it on a Pentium-M ( 32 Bit ,) with 512 MB RAM and Core
2 Duo with 1Gig RAM ( running SMP kernel , 2 CPUS) with same results.
Cant go more than ~4K addresses. I have tried them with vanilla and
custom kernels all 2.6.19+ versions. Results are same on both systems ,
so thats th
Evgeniy Polyakov wrote:
On Thu, Jun 21, 2007 at 02:00:07PM -0700, Rick Jones ([EMAIL PROTECTED]) wrote:
Simple test included test -> desktop and vice versa traffic with 128 and
4096 block size in netperf-2.4.3 setup.
Is that in conjunction with setting the test-specific -D to set
TCP_NODE
upper bound on the RTO, and wouldn't deal with
non-machine-local link failover.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
of ethtool, and I've just not
seen it?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Snook wrote:
Rick Jones wrote:
It seems that every driver, when providing support for ethtool -S
functionality, has considerable lattitude when it comes to the stats
provided. Clearly this is very nice for the driver writer(s) as it
allows them to provide whatever stats they feel are
e be having the drivers stick
stats in multiple places? Or are we back to wanting drivers to have a
common set of stats they keep?
rick jones
unafraid to show his ignorance of how things work, and how :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
quot; (ee el kay) - applying that same "telephone" game
(consistency? nah) to e1000 to get e1k, which if you look at it quickly
enough looks like elk. OK, that's half in jest, but only half. I may
be wrong, but I don't think I've seen anyone shortening the current
e1000
sub-MSS send. When Nagle is involved,
things can be very timing-sensitive, change the timing ever so slightly
and you can have a rather larger change in throughput. That could be
dealt-with either with the larger send sizes mentioned above, or by
adding a test-specific -D option to set TCP_NODEL
Does that pretty much sum it up?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
, that would cause RTO to be 1second.
I suspect that what is happening here is that a link goes down in a
trunk somewhere for some number of seconds, resulting in a given TCP
segment being retransmitted several times, with the doubling of the RTO
each time.
rick jones
-
To unsubscribe from this
contexts, the general answer is that the device failover time
is fixed, and the application layer time is similarly constrained by
end-user expectation/requirement. Often as not, layer 8 and 9 issues
tend to dominate and expect to trump (in this case layer 4 issues).
rick jones
-
To unsubscribe
Ilpo Järvinen wrote:
On Thu, 12 Jul 2007, Rick Jones wrote:
One question is why the RTO gets so large that it limits failover?
If Linux TCP is working correctly, RTO should be srtt + 2*rttvar
So either there is a huge srtt or variance, or something is going
wrong with RTT estimation
average latency. That is also in top of trunk, otherwise, for 2.4.3
you can skip that and do the math to conver to megabits/s yourself and not get
all the other derived values.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
tures.
Is this a requirement which might be expected to remain in the future, or is it
something which might just go away? That will have an effect on netperf future
development.
thanks,
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 13 Jul 2007 09:55:10 -0700
Fine, but so? I suspect the point of the patch is to provide a
lower cap on the accumulated backoff so data starts flowing over the
connection within that lower cap once the link is
restored/
NET6 to fe80::207:43ff:fe05:9d%2
(fe80::207:43ff:fe05:9d) port 0 AF_INET6 : +/-2.5% @ 99% conf.
Cool - it establishes the data connection just fine.
To further demonstrate my ignorance :) is that %n suffix something one might
expect in most/all getaddrinfo()'s or is that unique to th
Well, I spoke too soon - while it got me past my EINVAL, the connection
establishement timed-out. Either I picked the wrong value for n, or I may yet
need to make some tweaks to netperf.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
Thanks for the feedback Rick. We haven't used the netperf trunk. The
person who actually got these numbers will be trying the netperf trunk
little later and we will post the results..
Just in case someone has top-of-trunk worries, the basic single-stream,
bidirectional stuff is in the 2.4.3 rel
While that
doesn't break the bitbank it does get rather close.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
conditions change.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ignored.
(i.e. a list of 5 strings is returned, but bit 24 is set)
Is that to enable "hidden" bits? If not I'd think that emitting some
sort of "UNKNOWN_FLAG" might help flush-out little oopses like
forgetting a string.
rick jones
-
To unsubscribe from this list: s
enabled by default?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loic Prylli wrote:
On 4/30/2007 2:12 PM, Rick Jones wrote:
Speaking of defaults, it would seem that the external 1.2.0 driver
comes with 9000 bytes as the default MTU? At least I think that is
what I am seeing now that I've started looking more closely.
rick jones
That's th
On how "topologically big" a system has this resurrection of the PIO read been
tried so far?
rick jones
ever the paranoid :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
Michael Chan wrote:
On Mon, 2007-05-07 at 09:39 -0700, Rick Jones wrote:
On how "topologically big" a system has this resurrection of the PIO read been
tried so far?
If you're asking how much impact the read will have on performance, the
answer is that it will depend
Folks -
Is it a bug, or a feature that after changing a device's smp_affinity via echo
"N" >> /proc/irq/M/smp_affinity that the new mask isn't visible via cat
/proc/irq/M/smp_affinity until after actual interrupts are taken?
rick jones
-
To unsubscribe fro
Arjan van de Ven wrote:
On Mon, 2007-05-07 at 13:53 -0700, Rick Jones wrote:
Folks -
Is it a bug, or a feature that after changing a device's smp_affinity via echo
"N" >> /proc/irq/M/smp_affinity that the new mask isn't visible via cat
/proc/irq/M/smp_affinity unt
good ACK avoidance heuristics - I just wanted to make
sure this behaviour I was seeing was on the record somewhere as it may not be
obvious to everyone.
happy benchmarking,
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
small sends, which suggests that they
would be coalesced either implicitly by the Nagle algorithm or explicitly with
TCP_CORK no?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
Vlad Yasevich wrote:
Rick Jones wrote:
It is the reverse - GSO will segment one super-packet just before calling
the driver so that the stack is traversed only once. In my case, I am
trying to send out multiple skbs, possibly small packets, in one shot.
GSO will not help for small packets
gments and then dropping the
others, thus transmitting IP datagrams which had no hope of being reassembled
into anything other than frankengrams.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
jamal wrote:
The discussion seems to have steered into protocol coalescing.
My tests for example were related to forwarding and not specific
to any protocol.
Just the natural tendency of end-system types to think of end-system things
rather than router things.
rick jones
-
To unsubscribe
er" queue develops in the first place wouldn't one?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
10.20. OK, I promise no more old HP-UX stories for the
balance of the week :)
Taking some count of the list might be a triffle too complicated.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
r next qdisc skb, as a cache line miss is far
more expensive than a locked operation (if lock already in L1 cache of
course)
Might they not build on on top of the other?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [E
.route.flush'
net.ipv4.ip_local_port_range = 3276861000
I cannot imagine there is anything "safer" about 61000 than 63355. They both
have that "sign-bit" set.
While it is "security through obscurity" having the same default port range as
other platforms wo
Note that the high-order bit is set for all ports above 32768, so this
dragon would be stepped on pretty badly by Linux's default (and
indeed, the default for most OS's).
However, by "the very top", I think he was referring to the range
61000-65535, not all ports from 32768 up. Alan Cox clarifie
/proc/irq/69/smp_affinity
,0004
hpcpc106:~/s2io-2.0.19-8893# cat /proc/interrupts | grep 69
69: 0 0 0 0 PCI-MSI
eth2:MSI-X-6-RX
It would be nice if this could find its way into the kernel at some point -
2.6.23 or 2.6.24 perhaps?
rick jones
-An
o remain over
time and aren't there times when it does indeed mean that someone should be
looking into it?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
H. Peter Anvin wrote:
Rick Jones wrote:
Some more of my paranoid questions :)
So, if a driver tries to enable MSI and that is unsuccessful (I'll try
to avoid using the possibly loaded term "fails") shouldn't that show-up
_somewhere_?
It already does -- in /proc/inter
Jeff Garzik wrote:
Rick Jones wrote:
But that is rather incidental isn't it? Would some sort of system
health monitor be likely to be checking that for interrupt flavors? And
Well, that's where the information is exported in a standard way. I
hope you're not suggestin
On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote:
> Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as
> soon as the first received packet comes in via the sis900 ethernet
> interface. The machine is locked up and part of the kernel panic message
> is lost as it has sc
As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015
The helptext implies that this is on by default.
This may be true on some distros (Fedora/RHEL have it enabled
in /etc/sysctl.conf), but the kernel defaults to it off.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git
nds of segments (or more) per RTT via the traditional slow-start
procedures. This might degrade TCP performance when packet losses start to
occur. With limited slow-start, TCP increments the congestion window by at most
tcp_max_ssthresh/2 segments per RTT when the congestion window is is above
On Mon, May 21, 2007 at 02:51:35PM -0700, Auke Kok wrote:
> Herbert Xu wrote:
> "netif_poll_enable can only be called if you've previously called
> netif_poll_disable. Otherwise a poll might already be in action
> and you may get a crash like this."
>
> Removing the call to netif_poll_enabl
On Mon, May 21, 2007 at 05:58:27PM -0700, Kok, Auke wrote:
> >> This probably doesn't solve the latter bug.
> >> The code you reference isn't there in the kernel tested in that bug
> >> (2.6.21) In 2.6.21, netif_poll_enable is only called from
> >> e1000_up(), not e1000_open()
> >
> > Yes
NET, SOCK_STREAM although I
suppose it could be SCTP)
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
scc_rxint doesn't call this function at all.
http://bugzilla.kernel.org/show_bug.cgi?id=8146
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c
index 6fdaad5..30bed2a 100644
--- a/drivers/net/hamradio/scc.c
+++ b/
http://bugzilla.kernel.org/show_bug.cgi?id=8160
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 25b75b6..b670b97 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -1562,7 +1562,7 @@ stati
> RX queues - yes, I can see; TX queues, it doesnt make sense to put
different rings on different CPUs.
To what extent might that preclude some cachelines bouncing hither and
yon between the CPUs?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev"
On Wed, Jun 06, 2007 at 06:04:21PM -0700, Andrew Morton wrote:
> There _should_ be some #ifdeffable thing which is being passed to cpp when
> we run sparse (but I'm not sure what it is).
#ifdef __CHECKER__
(See include/linux/compiler.h, this is how we implement __user & friends)
Dave
really is.
So, for aggregate tests using netperf2, one has to calculate service
demand by hand. Sum the throughput as KB/s, convert the CPU util and
number of CPUs to a microseconds of CPU consumed per second and divide
to get microseconds per KB for the aggregate.
rick jones
-
To unsubscri
eal with that a little
would be to increase SO_SNDBUF in netperf with the -s option. That at
least is something I did back in 2.4 days
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
jamal wrote:
On Fri, 2007-08-06 at 10:27 -0700, Rick Jones wrote:
[..]
you cannot take the netperf service demand directly - each netperf is
calculating assuming that it is the only thing running on the system.
It then ass-u-me-s that the CPU util it measured was all for its work.
This
I'm starting to wonder how a multi-queue NIC differs from a bunch of
bonded single-queue NICs, and if there is leverage opportunity there.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
ELAY, or was Nagle left-on? If the latter, perhaps timing issues
could be why the confidence intervals weren't hit since the relative
batching of 128byte sends into larger segments is something of a race.
rick jones
-
To unsubscribe from this list: send the line "unsubscrib
1e or e1ke or heck, even elke if one wanted
to be a triffle playful would certainly help distinguish this driver
from its grandfather.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
t the entire tree for these
> things :-)))
Indeed. Here's another one.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/net/netfilter/xt_u32.c b/net/netfilter/xt_u32.c
index 74f9b14..bec4279 100644
--- a/net/netfilter/xt_u32.c
+++ b/net/netfilter/xt_u32.c
@@ -36
A Fedora users reported this against our 2.6.23-rc3 build
Dave
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0
least not during a netperf TCP_RR test.
Does anyone else see this? To try to eliminate netperf demo mode I re-ran
without it and got the same end results.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
% in the second.
So, in broad handwaving terms, TSO increased the per-transaction service demand
by something along the lines of (23.27 - 17.67)/17.67 or ~30% and the
transaction rate decreased by ~6%.
rick jones
bitrate blindless is a constant concern
-
To unsubscribe from this list: send the lin
stuff I posted recently) being rather worse with TSO enabled than with it
disabled?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
rick jones
Is the current behaviour intended?
Regards,
Laszlo Attila Toth
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this
jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A current hot topic of research is reducing the number of ACK's to make TCP
work better over asymmetric links like 3G.
Oy. People running Solaris and HP-UX have been "researching" ACK reductions
since 1997 if not earlier.
rick jones
-
To unsubscribe from this list
. The "send a request, wait for reply, send next request, etc etc
etc" is a rather common application behaviour afterall.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bill Fink wrote:
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
tion on the receiver. I don't know if it can account for all the
difference you see.
I had completely forgotten these stretch ACK and ucopy issues.
ISTR that LRO will induce stretch ACKs as well. Not that I dislike fewer ACKs
mind you... :)
rick jones
-
To unsubscribe from this lis
is release.
Yes, but for what definition of finite?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I don't even understand why this needs to be discussed to be honest
with you :-)
Just my (possibly frustrating :) habit of asking questions which help
further my understanding of the code :)
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" i
sort of call-back to TCP or the like.
If this failover is out in the middle of the cloud the only way to get a
notification back to TCP would be by sending it a packet of some sort
and I don't see that happening.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl "tcp_rto_min" to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Lamont Jones <[EMAIL
lue (in MS) for TCP_RTO_MIN.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I am sure you can use CTL_UNNUMBERED instead of adding yet another
sysctl value, as advised in include/linux/sysctl.h
** For new interfaces unless you really need a binary number
** please use CTL_UNNUMBERED.
fair enough. i was just repeating past behaviour :)
rick jones
-
To
David Miller wrote:
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a SHOULD
rather than a MUST. I had a quick look around and not s
From what I've seen thusfar, the issue isn't so much actual loss, but
very variable RTTs leading to spurrious RTOs.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
1 - 100 of 1071 matches
Mail list logo
