Rick Jones wrote:
The timeout is also to cover datagrams which just got "stuck" somewhere
too (IIRC) and may not necessarily require a multiple path situation.
I guess that's a fair point. Originally, the only possible place for a
packet to get "stuck" was in a router but I suppose that may no
Stephen Hemminger wrote:
TCP can not assume anything about the path that a packet may take.
We have declared a moratorium on loopback benchmark foolishness.
Go optimize the idle loop instead ;-)
Sure - A delay loop with fewer instructions is a worthwhile optimization
because it has less impact o
On Tue, 06 Mar 2007 14:07:09 -0800
Howard Chu <[EMAIL PROTECTED]> wrote:
> David Miller wrote:
> > From: Rick Jones <[EMAIL PROTECTED]>
> > Date: Tue, 06 Mar 2007 13:25:35 -0800
> >
> >>> On the other hand, being able to configure a small MSL for the loopback
> >>> device is perfectly safe. Bein
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2007 13:25:35 -0800
On the other hand, being able to configure a small MSL for the loopback
device is perfectly safe. Being able to configure a small MSL for other
interfaces may be safe, depending on the rest of the ne
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2007 13:25:35 -0800
> > On the other hand, being able to configure a small MSL for the loopback
> > device is perfectly safe. Being able to configure a small MSL for other
> > interfaces may be safe, depending on the rest of the network layo
On the other hand, being able to configure a small MSL for the loopback
device is perfectly safe. Being able to configure a small MSL for other
interfaces may be safe, depending on the rest of the network layout.
A peanut gallery question - I seem to recall prior discussions about how
one cann
Eric Dumazet wrote:
Arf... dont tell me you forgot to do this...
echo 1 >/proc/sys/net/ipv4/tcp_tw_recycle
echo 1 >/proc/sys/net/ipv4/tcp_tw_reuse
That does not appear to me to be a safe thing to do on a production
machine. Tweaks that are only good in a test environment really don't
help t
With transparant bridging, nobody knows how long the datagram may be
out there. Admittedly, the chances of a datagram living for a full
two minutes these days is probably nil, but just being in the same IP
subnet doesn't really mean anything when it comes to physical locality.
Bridging isn't
Howard Chu a écrit :
Eric Dumazet wrote:
Let me see, any chance you can try the prog on 2.6.20 ?
Not any time soon.
If not, please send :
grep . /proc/sys/net/ipv4/*
This is the output on the laptop:
/proc/sys/net/ipv4/icmp_echo_ignore_all:0
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts:
Eric Dumazet wrote:
Let me see, any chance you can try the prog on 2.6.20 ?
Not any time soon.
If not, please send :
grep . /proc/sys/net/ipv4/*
This is the output on the laptop:
/proc/sys/net/ipv4/icmp_echo_ignore_all:0
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts:1
/proc/sys/net/ipv4/i
Howard Chu a écrit :
Eric Dumazet wrote:
On Tuesday 06 March 2007 10:22, Howard Chu wrote:
It's a combination of 2MSL and /proc/sys/net/ipv4/ip_local_port_range -
on my system the default port range is 32768-61000. That means if I use
up 28232 ports in less than 2MSL then everything stops. net
Rick Jones wrote:
This is probably not something that happens in real world deployments.
I But it's not 60,000 concurrent connections, it's 60,000 within a 2
minute span.
Sounds like a case of Doctor! Doctor! It hurts when I do this.
I guess. In the cases where it matters, we use LDAP over U
This is probably not something that happens in real world deployments. I
But it's not 60,000 concurrent connections, it's 60,000 within a 2
minute span.
Sounds like a case of Doctor! Doctor! It hurts when I do this.
I'm not saying this is a high priority problem, I only encountered it in
a
Eric Dumazet wrote:
On Tuesday 06 March 2007 10:22, Howard Chu wrote:
It's a combination of 2MSL and /proc/sys/net/ipv4/ip_local_port_range -
on my system the default port range is 32768-61000. That means if I use
up 28232 ports in less than 2MSL then everything stops. netstat will
show that al
From: Howard Chu <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2007 01:22:18 -0800
> OK, I just subscribed to netdev...
Unlike other mailing lists you don't have to subscribe
to netdev in order to post to it and ask questions :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Tuesday 06 March 2007 10:22, Howard Chu wrote:
>
> It's a combination of 2MSL and /proc/sys/net/ipv4/ip_local_port_range -
> on my system the default port range is 32768-61000. That means if I use
> up 28232 ports in less than 2MSL then everything stops. netstat will
> show that all the availab
Eric Dumazet wrote:
On Monday 05 March 2007 12:20, Howard Chu wrote:
Why is the Maximum Segment Lifetime a global parameter? Surely the
maximum possible lifetime of a particular TCP segment depends on the
actual connection. At the very least, it would be useful to be able to
set it on a per-inte
On Monday 05 March 2007 12:20, Howard Chu wrote:
> Why is the Maximum Segment Lifetime a global parameter? Surely the
> maximum possible lifetime of a particular TCP segment depends on the
> actual connection. At the very least, it would be useful to be able to
> set it on a per-interface basis. E.
18 matches
Mail list logo
