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
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
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
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Oh I'm pretty sure it's not my application, because my application performs
well over ethernet, which is after all its purpose. Also I see the
write, the TCP uncork, then a pause, and then the packet leaving.
We
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
How could I test this theory?
Can you take another trace that isn't so "cooked?" One that just sticks
with TCP-level and below stuff?
Sorry for taking so long. Here is a tcpdump. The side on port 445 is
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
I'll try to go pester folks in tcpdump-workers then.
The thing to check is "TP_STATUS_CSUMNOTREADY".
When using mmap(), it will be provided in the descriptor. When using
recvmsg() it will be provided via a P
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 01 Nov 2007 14:48:45 -0700
One could I suppose try to ammend the information passed to allow
tcpdump to say "oh, this was a tx packet on the same machine on
which I am tracing so don't worry about checksum mi
t too since the IP length of
those was 0, but IIRC we got that patched to use the length of zero as a "ah,
this was TSO so wing it" heuristic.)
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
thing is telling me finding a 64 core system with a suitable workload to try
this could be a good thing. Wish I had one at my disposal.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
r TCP is likely capped by its effect on the
congestion window, limiting the number of outstanding segments.
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
Jay Vosburgh wrote:
Rick Jones <[EMAIL PROTECTED]> wrote:
I have to wonder if the full description of the different versions of
being a little bit pregnant is worth it. Just saying that using
balance-rr will result in reordering seems much more simple to comprehend.
True, b
be on vacation right now...)
Let me know if this works for you or not.
I don't know if it worked for Stephen, but it certainly worked to get rid of the
last three rename-induced stack traces on my system.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev&quo
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
- balance-rr bond feeds
on.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
---
diff -r 35e54d4beaad Documentation/networking/bonding.txt
--- a/Documentation/networking/bonding.txt Wed Oct 24 05:06:40 2007 +
+++ b/Documentation/networking/bonding.txt Mon Oct 29 03:47:19 2007 -0700
@@ -1696,23 +1696,6 @@
LSAPIC tlb_flush
253:586255449315448982
497702 LSAPIC resched
254:123162161166168154
109 140 LSAPIC IPI
ERR: 0
it appears as eth6.
rick jones
...
is at the mercy of sysctls. I wonder if it would be
better to have it use their FORCE versions to make life easier on the
benchmarker - such as myself - who has an unfortunate habit of forgetting to
update sysctl.conf :)
rick jones
-
To unsubscribe from this list: send the line "unsubs
ory starts so this probably isn't a latent bug.
Although it does rather sound like a driver writer yanking the rope from the
hand's of the sysadmin and hanging him with it rather than letting the sysadmin
do it himself. I've seen other drivers' README's suggesti
I would tend to
prefer the attached patch...
That achieves my desired end result of no warning while compiling on ia64 so I'm
happy with it. I suspect that may also get rid of a warning on parisc so I
should be doubly pleased :)
rick jones
-
To unsubscribe from this list: send the line &qu
: Rick Jones <[EMAIL PROTECTED]>
---
diff -r 35e54d4beaad drivers/net/fealnx.c
--- a/drivers/net/fealnx.c Wed Oct 24 05:06:40 2007 +
+++ b/drivers/net/fealnx.c Fri Oct 26 06:12:00 2007 -0700
@@ -866,7 +866,7 @@ static int netdev_open(struct net_device
// np->bcrvalue=0x04
se, even after reading SubmittingPatches)
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
ot; or the receiver rather than the
sender would be a good thing, and trying again with CKO disabled on the
interface(s) (via ethtool) might be something worth looking at. Ultimately,
doing the partial checksum modificiations in a CKO-friendly manner might be a
good thing.
rick jones
-
To u
me unhappy things when multiple
interfaces are connected to the same broadcast domain.
That the "all interfaces have one MAC" default behaviour on SPARC systems often
ran into troubles is probably cautionary here.
rick jones
-
To unsubscribe from this list: send the line "unsubscri
On Tue, Oct 23, 2007 at 04:03:38PM -0700, Kok, Auke wrote:
> Dave Jones wrote:
> > On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
> >
> > > > In any case, this patch should not be merged. We often send it around
> > to users to
> > &g
On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
> > In any case, this patch should not be merged. We often send it around to
> > users to
> > debug their issue in case it involves eeproms, but merging it will just
> > conceal
> > the real issue and all of a sudden a flood of pe
s to the end of that to constrain the
TCP windows which might be an interesting experiment.
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
On Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote:
> David Mack wrote:
> > It appears that the needed e100 fix made it into the Fedora
> > 2.6.23.1-23.fc8 kernel. Boots reliably now.
> >
> > Huge thanks and great work, guys.
>
> DaveJ, I didn't push anything upstream. Can you verif
try setting the
lowlatency sysctl - both processes being on the same CPU might interact poorly
with the attempts to run things on the receiver's stack.
rick jones
I guess I've not managed to lose the race to a packet trace... :)
-
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
you
cna also switch the output of a TCP_RR test to bits or bytes per second a la the
_STREAM tests.
rick jones
My initial idea was that it has something todo with the different MTU on
loopback. My initial block size was 16k, but the problem stayed when I
changed it to 64k.
Felix
-
To unsubsc
6.18... So, due dilligence and
no good deed going unpunished suggests that Matthew and I are now in a race to
take some tcpdump traces :)
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
the packet trace was a bit too cooked perhaps, but there were indications that
at times the TCP window was going to zero - perhaps something with window
updates or persist timers?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
Failover between disparate link-types sounds like a job for IP and routing.
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
t list all listening TCP sockets, and next list all established
TCP connections. A typical entry of /proc/net/tcp would look like this (split
/proc/net/[tcp|tcp6] are deprecated now right? Perhaps there should be
something to that effect added to the txt.
rick jones
-
To unsubscribe from thi
tainly, but assuming Peter's going to get his broken hardware fixed it
might let him limp along until then.
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
On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote:
> Herbert Xu wrote:
> > On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
> >> The e1000 changes you reference above, is this the changeset you mean?
> >>
> >> commit 416b5d10afdc797c2
On Thu, Sep 27, 2007 at 02:58:27PM +0800, Herbert Xu wrote:
> Kok, Auke <[EMAIL PROTECTED]> wrote:
> > Dave Jones wrote:
> >> Last night, I hit this bug during boot up..
> >> http://www.codemonkey.org.uk/junk/e100-2.jpg
> >>
> >> This m
Reported by a Fedora user this morning.
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: Adding slave eth0.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
bonding: bond0: makin
SendRecv Send Recv (avg) Send (avg)
8 8 0 0 1.181e+09 1452.38812953 16384.00 72065
Maximum
Segment
Size (bytes)
1448
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
th no switch or tg3 with a
ProCurve on my rx2660's.
I can also run bw_tcp from lmbench 3.0a8 and get 106 MB/s.
I don't have a netgear switch to try in all this...
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
3.65-rh
firmware-version: 5704-v3.27
bus-info: :01:02.0
rick jones
net.ipv6.conf.eth2.router_probe_interval = 60
net.ipv6.conf.eth2.accept_ra_rtr_pref = 1
net.ipv6.conf.eth2.accept_ra_pinfo = 1
net.ipv6.conf.eth2.accept_ra_defrtr = 1
net.ipv6.conf.eth2.max_addresses = 16
net.ipv6.conf.eth2.ma
tics to cut-down
on the CPU overhead of bulk transfers. (That they both have them stems from
their being cousins, sharing a common TCP stack ancestor long ago - both of
course have been diverging since then).
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev&q
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
While I am
has anyone already asked whether link-layer flow-control is enabled?
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
application is staying-up with the network. I doubt that SO_&BUF settings would
change that, but perhaps setting watermarks might (wild ass guess). The
watermarks will do nothing on HP-UX though (IIRC).
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev"
uncated packets: 0 pkts
data xmit time: 10.005 secs data xmit time:0.000 secs
idletime max:7.5 msidletime max:7.4 ms
throughput:117979555 Bps throughput:0 Bps
This was taken at the receiving 1
et out.
Alternatively disable checksum offload with ethtool.
Or take the packet traces "outboard" of the NIC somewhere/somehow.
What problem(s) led to your taking the packet trace in the first place?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the b
On Wed, Sep 26, 2007 at 11:10:11AM -0700, Kok, Auke wrote:
> Dave Jones wrote:
> > Last night, I hit this bug during boot up..
> > http://www.codemonkey.org.uk/junk/e100-2.jpg
> >
> > This morning, I got a mail from a Fedora user of the same
> > .23
s no-ops. What about SCTP?
I asked Vlad that very question, since SCTP can preserve message
boundaries. He tells me that a zero-length message is not part of SCTP.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same
.23-rc8 based kernel that has seen a different trace
also implicating e100..
http://www.codemonkey.org.uk/junk/e100.jpg
It may be that the two proble
to max-out the NIC it might still have too much overhead, but
then does pktgen+driver et al actually fit in an L1 cache?
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://
)
+
+ if (!(hw->flags & SKY2_HW_NEW_LE))
mss += ETH_HLEN + ip_hdrlen(skb) + tcp_hdrlen(skb);
Might the same thing apply with SKY2_HW_NEW_LE?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
VICE_ID_NEPTUNE_DCSP 0xf0f7
and shows-up in comments elsewhere, but that same (perhaps too cursory?)
search didn't seem to find "neptune" used as an actual module/driver
name, so why "niu?" To what does niu translate anyway?
sincerely,
rick jones
now left with the qu
Enable users of ip to specify the times for rtt, rttvar and rto_min
in human-friendly terms a la "tc" while maintaining backwards
compatability with the previous "raw" mechanism. Builds upon
David Miller's uncommited patch to set rto_min.
Signed-off-by: Rick Jones <
us places (stacks) as an "accepted" broadcast IP
in the receive path, but not the send path for quite possibly decades now.
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
Enable users of ip to specify the times for rtt, rttvar and rto_min
in human-friendly terms a la "tc" while maintaining backwards
compatability with the previous "raw" mechanism. Builds upon
David Miller's uncommited patch to set rto_min.
Signed-off-by: Ric
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and INET_DIAG_INFO.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
---
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--
get such a counter in is to just send a patch,
don't ask for it.
I will try to work something up after cleaning-up the other listenq
patch to remove the /proc/net/tcp[6] stuff, and an iproute2 patch I have
to allow setting rto_min, rtt and rttvar using tc-esque units.
rick jones
-
To unsubscrib
John Heffner wrote:
Rick Jones wrote:
John Heffner wrote:
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct
doesn't have the idiag_mum
oc/net/tcp I
use tcpi_unacked and tcpi_sacked.
For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
then covers ss.
rick
-John
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structur
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 11:38:09 -0700
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
Reposting the patch is often better because if you quote it
then the copy
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Eric Dumazet &
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
rick jones
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can se
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 10 Sep 2007 11:42:18 -0700
I've been digging around to see about inducing /proc/net/tcp to show
some "interesting" things for listen sockets (eg backlog depth, its max,
and dropped connection request
full duplex or not. also check previous kernel messages
and see what the e1000 driver posted there for link speed messages (as in
"e1000:
Link is UP speed XXX duplex YYY")
Shouldn't there then have been at least _some_ collisions reported in
the stats? And perhaps some late
ot; the time conversion stuff in tc for use in ip.
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
e - but at the very least, having
ip provide at least the illusion of what tc does would seem to be a good
thing.
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
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Eric Dumazet &
By the way, make sure your "Signed-off-by: Rick Jones
<[EMAIL PROTECTED]>" is the first signoff :
You are the main author of this patch, I only reviewed it and added a
contribution.
I just went alphabetically - I take it there is further meaning assigned
to the first person
please ignore - I resent the original patch by mistake...grrr.
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
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Signed-off-by: Rick Jones &
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
---
diff -r bdcdd0e1ee9d Documentation/netw
BTW, what do people think about doing the same thing with the rxqueue
and txqueue's of netstat output?
I dont understand this question, I thought your patch already handled this
(for the txqueue, since rxqueue is already there), as netstat uses
/proc/net/tcp (unfortunatly)
Well, it doesn
ss command from iproute2 package ( http://linux-net.osdl.org/index.php/Iproute2
)
Problem with /proc/net/tcp is its quadratic time O(N^2) to output N lines...
I could see where that might be a problem.
Rick, could you add this part in your patch, and add my Sign-off-by ?
My pleasure.
I ha
slightly lower than the value used by the e1000 driver, so it seems
like a safe upper limit.
FWIW the OFED 1.2 bits take the MTU of IPoIB up to 65520 bytes :)
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More
Eric Dumazet wrote:
Sridhar Samudrala a écrit :
On Mon, 2007-09-10 at 16:13 -0700, Rick Jones wrote:
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
---
diff -r bdcdd0e1ee9d Documentation/netw
Sridhar Samudrala wrote:
On Mon, 2007-09-10 at 11:42 -0700, Rick Jones wrote:
I've been digging around to see about inducing /proc/net/tcp to show
some "interesting" things for listen sockets (eg backlog depth, its max,
and dropped connection requests).
backlog depth(accept
at the
listen queue is full, but only tcp_v[46]_syn_recv_sock increments some
mib stats for dropped connection requests.
Is that deliberate, or is that a hole in the stats?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [E
Pádraig Brady wrote:
Rick Jones wrote:
This was an issue over a decade ago with SPECweb96 benchmarking. The
initial solution was to make the explicit bind() calls and not rely on
the anonymous/ephemeral port space. After that, one starts adding
additional IP's into the mix (at least
That said, it's certainly plausible that, for a given set of N
ethernets all enslaved to a single bonding balance-rr, the individual
ethernets could get out of sync, as it were (e.g., one running a fuller
tx ring, and thus running "behind" the others).
That is the scenario of which I wa
could hit the intermediate device out of
order and so stay that way across the GbE link.
Before I go and patch-out that text I thought I'd double check.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mo
the
ISN allows that today is questionable.
So how about auto enabling recycling for local connections?
I think the standard response is that one can never _really_ know what
is local and what not, particularly in the presence of netfilter and the
rewriting of headers behind one's bac
ny interface in the
system to respond to an ARP request for any of the IP's assigned to any
of the interfaces.
worse, it continues to do it after unconfiguring
eth0:1 and eth0.
As in simply marking it "down?"
rick jones
-
To unsubscribe from this list: send the line &qu
Stephen Hemminger wrote:
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones <[EMAIL PROTECTED]> wrote:
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This i
Stephen Hemminger wrote:
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones <[EMAIL PROTECTED]> wrote:
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This i
from system to system would be error prone.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
---
*** ./lib/utils.c.orig 2007-09-04 13:11:01.0 -0700
--- ./lib/utils.c 2007-09-04 13:06:11.0 -0700
***
*** 61,66
--- 61,141
return 0;
}
+ /
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 31 Aug 2007 13:59:50 -0700
ip is at tcp_rto_min+0x20/0x40
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1ee7212..bbad2cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -560,7
I managed to find iproute2 sources (they were debian lenny/testing
2.6.20-1) and applied the patch, and figured-out how to add a host route
back to one of my systems. I then did a change to set rto_min to 300.
I started a tcpdump and then a netperf, and then forces some
retransmissions the old
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 18:07:13 -0700
Anyhow, I'll try grubbing around the source code (already doing that to
see about writing a pet tcp cong module) but if pointers to the likely
relevant files were available I could
John Heffner wrote:
Rick Jones wrote:
Like I said the consumers of this are a triffle well, "anxious" :)
Just curious, did you or this customer try with F-RTO enabled? Or is
this case you're dealing with truly hopeless?
F-RTO was mentioned to the customer and I'm awa
Stephen Hemminger wrote:
On Thu, 30 Aug 2007 18:09:17 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
While messing about with "sysctl_tcp_rto_min" I went back and forth a
bit as to whether there should have been bounds checking (as did some of
the folks who did some intern
to sundry networking sysctls?
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
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT)
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 sp
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
Krishna Kumar2 wrote:
Hi Rick,
From: Rick Jones <[EMAIL PROTECTED]>
The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking ov
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
The trace I've been sent shows clean RTTs ranging from ~200 milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on su
All of this seems to suggest that the RTO calculation is wrong.
That is a possiblity. Or at least could be enhanced.
It seems that packets in this network can be delayed several orders of
magnitude longer than the usual round trip as measured by TCP.
What exactly causes such a huge delay?
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
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
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
601 - 700 of 1071 matches
Mail list logo
