Re: decreasing TIME_WAIT duration(T/TCP?)
Lars Eggert wrote: > > > In article > > [EMAIL PROTECTED]> you write: > > >Hello! > > > > > >It is important to me to have duration of TIME_WAIT state of TCP > > >connection as short time as possible. > > > > Tweak net.inet.tcp.msl, which specifies the 2MSL timeout. > > And know what you are doing, it's there for a reason. If you need to > dramatically change this value, I'd wager your system would benefit from a > design change. > > Lars > -- > Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California Alan Cox wrote: | | > Machine is web serwer with reather big traffic. Why there is | > so much connections in TIME_WAIT state ? | | | "2 mintues" may be how the Linux kernel does it, but it's not the way | TCP says it should be done. | | TIME_WAIT should last for 2*MSL (maximum segment lifetime). I know it's | hard to calculate MSL, and if you make up a hard-coded value it has to | be long enough for the slowest connections. It could be that FreeBSD | 4.0 does do this calculation. If we can calculate semi-accurate MSLs | for each connection, TIME_WAIT states would be minimized. | | Even over a slow Internet link, the MSL can't be much longer than 10 | seconds or so. By then a segment has either been TTL'd out, or is | lost. I don't buy "MSL == 1 minute" at all. How to turn on this calculation for 4.x ? Serg. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: decreasing TIME_WAIT duration(T/TCP?)
In article [EMAIL PROTECTED]> you write: >Lars Eggert wrote: >> >> > In article >> > [EMAIL PROTECTED]> you write: >> > >Hello! >> > > >> > >It is important to me to have duration of TIME_WAIT state of TCP >> > >connection as short time as possible. >> > >> > Tweak net.inet.tcp.msl, which specifies the 2MSL timeout. >> >> And know what you are doing, it's there for a reason. If you need to >> dramatically change this value, I'd wager your system would benefit from a >> design change. >> >> Lars >> -- >> Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute >> http://www.isi.edu/larse/ University of Southern California > > >Alan Cox wrote: >| >| > Machine is web serwer with reather big traffic. Why there is >| > so much connections in TIME_WAIT state ? >| >| >| "2 mintues" may be how the Linux kernel does it, but it's not the way >| TCP says it should be done. >| >| TIME_WAIT should last for 2*MSL (maximum segment lifetime). I know >it's >| hard to calculate MSL, and if you make up a hard-coded value it has to >| be long enough for the slowest connections. It could be that FreeBSD >| 4.0 does do this calculation. If we can calculate semi-accurate MSLs >| for each connection, TIME_WAIT states would be minimized. >| >| Even over a slow Internet link, the MSL can't be much longer than 10 >| seconds or so. By then a segment has either been TTL'd out, or is >| lost. I don't buy "MSL == 1 minute" at all. > >How to turn on this calculation for 4.x ? Unfortunately, this is not calculated; we still rely on a static (default 30sec) MSL quiet period. Ideally, it should be possible to set MSL based on some multiple of RTT for the connection, and default to a hard coded value if there are not enough samples to calculate RTT. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Understanding fxp driver
Hello, Am trying to playaround and understand the Intel NIC fxp driver and it would be of help if you driver-gurus can please clarify a couple of points. I understand that Tx DMA size is 128. 1. what parameter exactly determines how many packets the NIC sends before interrupting the Host Cpu after transmit (assuming no packet is received). 2. Does the NIC interrupt the Host cpu on each packet reception? If so, how are packets that are put into the RFA (while the CPU is busy processing the current interrupt) notified - (my understanding is the "rcvloop" in fxp_intr will automatically take care of this - is it correct?). 3. What is the exact role of tx_threshold 4. Suppose I want to make the NIC interrupt the cpu for each packet, if I just reduce the Tx DMA length to 2-power-0, i.e,1, will it work? Thanks a lot for your time. Murthy _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
if_dc problem identified
I have done some more investigating. I believe if_dc is not correctly interpreting the SROM. It turns out that on Znyx cards, the SIA block is not in the format the driver expects (there is a format bit you need to check to see what format it is in). I manually re-interpreted the data in the SROM and put a special case in dc_apply_fixup() and now 10baseT half duplex works correctly (not only that, but the LEDs do the correct thing too). I won't post a patch, since the hack has SROM data that is specific to this card, but it appears that the SROM parsing section of if_dc and the media selection code needs serious work. According to the sample code I've seen (thanks to Andrew Gallatin for pointing me to the sample below), we're not consulting the SROM for _enough_ information, and we're making too many assumptions about its format. http://www.tru64unix.compaq.com/docs/dev_doc/DOCUMENTATION/HTML/DDK_R2/usr/opt/OSCB505/src/usr/examples/ddk/src/pci/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Understanding fxp driver
In article [EMAIL PROTECTED]> you write: >Hello, > >Am trying to playaround and understand the Intel NIC fxp driver and it would >be of help if you driver-gurus can please clarify a couple of points. > >I understand that Tx DMA size is 128. The number of control blocks is 128; this is not the same as the DMA size. >1. what parameter exactly determines how many packets the NIC >sends before interrupting the Host Cpu after transmit (assuming >no packet is received). /* * Number of completed TX commands at which point an interrupt * will be generated to garbage collect the attached buffers. * Must be at least one less than FXP_NTXCB, and should be * enough less so that the transmitter doesn't becomes idle * during the buffer rundown (which would reduce performance). */ #define FXP_CXINT_THRESH 120 >2. Does the NIC interrupt the Host cpu on each packet reception? Yes, unless the receive interrupt migitation code is enabled. But note that this does not necessarily translate into "one interrupt per packet", as multiple packets may be processed under the same interrupt. >If so, how are packets that are put into the RFA (while the >CPU is busy processing the current interrupt) notified - >(my understanding is the "rcvloop" in fxp_intr will automatically >take care of this - is it correct?). Packets are added at the tail end of the RFA while the cpu processes the head. The code processes all completed entries, then loops again to check for new interrupts before exiting the interrupt handler. >3. What is the exact role of tx_threshold Indicates the # of bytes that should be present on-chip before a transmit starts; if an underrun occurrs (cpu can't provide data to the chip in time to complete a frame), this is increased. >4. Suppose I want to make the NIC interrupt the cpu for each packet, >if I just reduce the Tx DMA length to 2-power-0, i.e,1, will it work? No, that won't work, but why would you want to do that? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: decreasing TIME_WAIT duration(T/TCP?)
< said: > Unfortunately, this is not calculated; we still rely on a static > (default 30sec) MSL quiet period. Ideally, it should be possible to > set MSL based on some multiple of RTT for the connection, and default > to a hard coded value if there are not enough samples to calculate RTT. There is no way to `calculate' the maximum segment lifetime unless you are omniscient. It is assumed to be 30 seconds, but in reality can be much, much more. (As a result, TCP is theoretically broken, but the situations in which this happens are rare enough to be masked by other events.) The RTT gives you the *critical path length* of the graph; it does not have anything to do with the MSL except for trivial (two-node) networks. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Revised polling code for STABLE
[Bcc to -stable in case someone is interested there]
Attached you can find the latest version of the polling code
for STABLE (which is useful to make boxes much more robust
to attacks and have much better responsiveness under [over]load).
Note that this code is only useful for RELENG_4, x86, non-SMP
boxes.
This version includes driver modifications for the following
drivers:
fxp (this is for version 1.110.2.7 of the driver, i.e.
the one in FreeBSD 4.4; hopefully the change should
work for the newer driver as well without too
many changes)
dc
sis (this one includes an i386 optimization which avoids
an additional copy of the packet. The performance
improvement I have measured from this can be as high as
50% in some embedded systems with not a lot of CPU power).
Other drivers should be modified mostly following what is done in
the above drivers.
The sysctl variables to control polling mode are:
net.xorp.polling
set to 1 to enable polling, 0 to disable (default)
net.xorp.poll_burst_max
how many packets are processed at most at each clock
tick. Defaults to 100.
net.xorp.poll_burst
how many packets are processed at each clock tick.
Automatically adjusted depending on system load
between 1 and net.xorp.poll_burst_max
net.xorp.poll_in_trap
how many packets are processed at each trap.
Upper bounded by net.xorp.poll_burst.
net.xorp.sis_quick
set to 1 (default) to avoid the additional copy in the
sis driver. There should be no reason to turn this off
except seeing how much you are gaining.
Installation is trivial:
+ (cd /sys ; patch < polling.patches )
+ add the following two lines to the kernel config:
options HZ=1000
options XORP_ETHER_POLLING
+ build and install the kernel
+ at runtime use the sysctl variables listed above to control polling.
Basically you just need to turn on net.xorp.polling
The files touched by this diff are:
sys/conf/options.i386
option definition
sys/i386/include/asnames.h
sys/net/if.h
sys/net/netisr.h
sys/sys/systm.h
constants, variable and prototypes (mostly one-line changes)
sys/i386/i386/swtch.s
sys/i386/i386/trap.c
calls to ether_poll from the idle loop and traps
sys/kern/kern_clock.c
main polling routines
sys/dev/fxp/if_fxp.c
sys/pci/if_dc.c
sys/pci/if_dcreg.h
sys/pci/if_sis.c
sys/pci/if_sisreg.h
device driver changes
Have fun, please report success or problems if you use this code.
cheers
luigi
--+-
Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
--+-
Index: sys/conf/options.i386
===
RCS file: /home/xorpc/u2/freebsd/src/sys/conf/options.i386,v
retrieving revision 1.132.2.8
diff -u -r1.132.2.8 options.i386
--- sys/conf/options.i386 2001/10/03 07:15:37 1.132.2.8
+++ sys/conf/options.i386 2001/10/27 00:23:01
@@ -208,5 +208,10 @@
SMBFS
# ---
+# Xorp stuff
+# ---
+XORP_ETHER_POLLING opt_global.h
+
+# ---
# EOF
# ---
Index: sys/dev/fxp/if_fxp.c
===
RCS file: /home/xorpc/u2/freebsd/src/sys/dev/fxp/if_fxp.c,v
retrieving revision 1.110.2.7
diff -u -r1.110.2.7 if_fxp.c
--- sys/dev/fxp/if_fxp.c2001/08/31 02:17:02 1.110.2.7
+++ sys/dev/fxp/if_fxp.c2001/11/23 17:54:41
@@ -1123,6 +1123,38 @@
}
}
+static void fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count);
+
+#ifdef XORP_ETHER_POLLING
+static poll_handler_t fxp_poll;
+
+static void
+fxp_poll(struct ifnet *ifp, int cmd, int count)
+{
+ struct fxp_softc *sc = ifp->if_softc;
+ u_int8_t statack ;
+
+ if (cmd == 2) { /* final call, enable interrupts */
+ CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, 0);
+ return;
+ }
+ statack = FXP_SCB_STATACK_CXTNO | FXP_SCB_STATACK_CNA |
+ FXP_SCB_STATACK_FR ;
+ if (cmd == 1) {
+ u_int8_t tmp ;
+ tmp = CSR_READ_1(sc, FXP_CSR_SCB_STATACK);
+ if (tmp == 0xff || tmp == 0)
+ return ; /* nothing to do */
+ tmp &= ~statack ;
+ /* ack what we can */
+ if (tmp != 0)
+ CSR_WRITE_1(sc, FXP_CSR_SCB_STATACK, tmp);
+ statack |= tmp ;
+ }
+ fxp_intr_body(sc, statack, count);
+}
+#endif /* XORP_ETHER_PO
Re: Revised polling code for STABLE
At 11:57 AM 11/26/01 -0800, Luigi Rizzo wrote: >[Bcc to -stable in case someone is interested there] > >Attached you can find the latest version of the polling code >for STABLE (which is useful to make boxes much more robust >to attacks and have much better responsiveness under [over]load). Thanks for this code! Are there any particular compile time options one should use ? e.g. HZ=1000 etc ? The box in question would be running Zebra and BGPd and forwarding lots-o-packets with lots-o-routes (100k+) ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: decreasing TIME_WAIT duration(T/TCP?)
On Mon, Nov 26, 2001 at 02:47:00PM -0500, Garrett Wollman wrote: > < >said: > > > Unfortunately, this is not calculated; we still rely on a static > > (default 30sec) MSL quiet period. Ideally, it should be possible to > > set MSL based on some multiple of RTT for the connection, and default > > to a hard coded value if there are not enough samples to calculate RTT. > > There is no way to `calculate' the maximum segment lifetime unless you > are omniscient. It is assumed to be 30 seconds, but in reality can be > much, much more. (As a result, TCP is theoretically broken, but the > situations in which this happens are rare enough to be masked by other > events.) The RTT gives you the *critical path length* of the graph; > it does not have anything to do with the MSL except for trivial > (two-node) networks. MSL is the maximum time that the segment is assumed to exist in the network; in practice I would interpret this to mean the maximal amount of time it takes to travel from one node endpoint to another, taking into account congestion, route changes, and queuing delay. As you said, there is no way to reliably calculate this value, since the delay is theortically unbounded; in fact RFC 793 sets it at 120 seconds. However, my assertion is that in most cases, the true MSL for segments on a given connection will tend to be tied to some multiple of the RTT; that is, there exists a strong correlation between the two. Packets can be held up for an arbitrarily long length of time, but I would imagine that the number of active segments after (say) 10*RTT would not be significantly different than the number after 30 seconds. Note that it is quite possible I'm wrong in this assertion, though. :-) -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: if_dc problem identified
One more bit of data. The document needed for doing the work I mention is here: http://developer.intel.com/design/network/drivers/srom_409.pdf If no one else steps up, I will probably give this a try in my copious spare time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: decreasing TIME_WAIT duration(T/TCP?)
Jonathan Lemon wrote: > As you said, there is no way to reliably calculate this value, since the > delay is theortically unbounded; in fact RFC 793 sets it at 120 seconds. > > However, my assertion is that in most cases, the true MSL for segments > on a given connection will tend to be tied to some multiple of the RTT; > that is, there exists a strong correlation between the two. While I agree that the average "segment lifetime" of a given connection is probably on the same order of magnitude than the RTT, this does not have any impact on the MAXIMUM segment lifetime: it's an Internet-wide upper bound. Even for connections with millisecond RTTs, packets can be delayed for seconds or longer due to routing glitches. The original poster wanted to shorten the MSL to avoid accumulating TIME WAITs at the server. There are better techniques for that, see for example Ted Faber's paper in INFOCOM '99 (http://www.isi.edu/~faber/pubs.html). Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Understanding fxp driver
Thanks. > > >4. Suppose I want to make the NIC interrupt the cpu for each packet, > >if I just reduce the Tx DMA length to 2-power-0, i.e,1, will it work? > >No, that won't work, but why would you want to do that? --> I have a virtual interface that Round Robins packets over the actual physical interface. ( modified ng_etherchannelbonding). But, the receiver is getting the packets out-of-order - as expected, when packets are of different size, but, I am not understanding, why,even when the 2 NICs are identical and packets are of MTU size, reordering is occuring. Any clues welcome. I was trying to see if the reason is the fact that each NIC puts up a lot of packets at a time to the TX DMA Area - and so, is it possible in any way to gain a better contol over the actual sending of packets. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: arp_rtrequest: bad gateway value
On Fri, 23 Nov 2001, Paul Herman wrote: > On Thu, 22 Nov 2001, Ruslan Ermilov wrote: > > > On Wed, Nov 21, 2001 at 05:32:27PM -0800, Paul Herman wrote: > > > Hi, > > > > > > I'd like to pick some brains before I file a PR. > > > > > There's already a PR open on this, kern/29170. > > > > [...] > > Here's a patch against 4.4-RELEASE that fixes this problem. As mentioned before, the problem happens when a gateway with the RTF_LLINFO set gets polluted with non-link information. routed and route are both culprits. BTW, KAME does this as well by putting AF_INET6 data into gateways with the RTF_LLINFO flag set, which I don't think is a good idea, but it calls rt_setgate() directly and isn't affected by this patch. I've decided to have the kernel leave the gateway untouched and continue, rather than having the kernel return EINVAL. This produces the least astonishment :-) Please review and if it's OK, I'll send it to gnats for the audit trail. Thanks, -Paul. Index: sys/net/rtsock.c === RCS file: /mnt/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.44.2.4 diff -u -r1.44.2.4 rtsock.c --- sys/net/rtsock.c2001/07/11 09:37:37 1.44.2.4 +++ sys/net/rtsock.c2001/11/27 01:33:03 @@ -399,6 +399,14 @@ break; case RTM_CHANGE: + /* Don't let the user specify non-link information +* for a gateway if the RTF_LLINFO flag is set. +* We'll just leave the gateway alone. +*/ + if (gate && (rt->rt_flags & RTF_LLINFO) && + gate->sa_family != AF_LINK) + gate = rt->rt_gateway; + if (gate && (error = rt_setgate(rt, rt_key(rt), gate))) senderr(error); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Very strange network behaviour - can anyone help me analyse tcpdump output?
Hi all,
In the continuing saga of IPSec over PPPoE for a retail POS environment that
I'm maintaing, the problems seem to become more complex as time goes on.
The network is quite simple:
[ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
LAN #2 ]
Both LANs connect using PPPoE with the same ISP, and are one hop apart
(according to traceroute).
The problem is that a connection from the Internet (anywhere) to either of
the FreeBSD gateways will "hang". Usually I can login but doing an 'ls -al'
will display a few lines of text and then nothing. This happens using a
bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native, FreeBSD)
from various ISPs, as well as *between* the gateways, so the problem is most
definitely related to the ISP providing us service. However, they seem to
think that it's our problem ("none of the customers that use Windows have
this problem -- must be that Unix thing that you're using").
I have an ethereal trace of a hanging telnet session from my desktop to one
of the gateway machines, and the corresponding tcpdump trace of the same
session on the gateway. Since I'm not too familiar with TCP/IP at such a
low level, I was wondering if anyone would be willing to take a look at the
two dumps and see if there is anything strange going on.
Thanks,
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Very strange network behaviour - can anyone help me analysetcpdump output?
On Mon, 26 Nov 2001, Matthew Emmerton wrote:
> Hi all,
>
> In the continuing saga of IPSec over PPPoE for a retail POS environment that
> I'm maintaing, the problems seem to become more complex as time goes on.
>
> The network is quite simple:
> [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
> LAN #2 ]
>
> Both LANs connect using PPPoE with the same ISP, and are one hop apart
> (according to traceroute).
>
> The problem is that a connection from the Internet (anywhere) to either of
> the FreeBSD gateways will "hang". Usually I can login but doing an 'ls -al'
> will display a few lines of text and then nothing. This happens using a
> bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native, FreeBSD)
> from various ISPs, as well as *between* the gateways, so the problem is most
> definitely related to the ISP providing us service. However, they seem to
> think that it's our problem ("none of the customers that use Windows have
> this problem -- must be that Unix thing that you're using").
If you are using gif, make sure it has a small MTU (try 512 bytes)
>
> I have an ethereal trace of a hanging telnet session from my desktop to one
> of the gateway machines, and the corresponding tcpdump trace of the same
> session on the gateway. Since I'm not too familiar with TCP/IP at such a
> low level, I was wondering if anyone would be willing to take a look at the
> two dumps and see if there is anything strange going on.
>
> Thanks,
>
> --
> Matt Emmerton
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Very strange network behaviour - can anyone help me analyse tcpdump output?
> On Mon, 26 Nov 2001, Matthew Emmerton wrote:
>
> > Hi all,
> >
> > In the continuing saga of IPSec over PPPoE for a retail POS environment
that
> > I'm maintaing, the problems seem to become more complex as time goes on.
> >
> > The network is quite simple:
> > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] -
[
> > LAN #2 ]
> >
> > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > (according to traceroute).
> >
> > The problem is that a connection from the Internet (anywhere) to either
of
> > the FreeBSD gateways will "hang". Usually I can login but doing an
'ls -al'
> > will display a few lines of text and then nothing. This happens using a
> > bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native,
FreeBSD)
> > from various ISPs, as well as *between* the gateways, so the problem is
most
> > definitely related to the ISP providing us service. However, they seem
to
> > think that it's our problem ("none of the customers that use Windows
have
> > this problem -- must be that Unix thing that you're using").
>
> If you are using gif, make sure it has a small MTU (try 512 bytes)
belmont.heers.on.ca# ifconfig gif0
gif0: flags=8011 mtu 1280
inet 10.0.2.2 --> 10.0.2.130 netmask 0x
belmont.heers.on.ca# ifconfig gif0 mtu 512
ifconfig: ioctl (set mtu): Invalid argument
belmont.heers.on.ca# gifconfig gif0 mtu 512
gifconfig: mtu: bad value
belmont.heers.on.ca#
How am I supposed to change the MTU?
(These machines are running 4.3-RELEASE-p12)
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
