RE: TCP receiving buffer
Hi, If you want to set it more than 512KB you need to grow maxsockbuf so: #sysctl -w kern.ipc.maxsockbuf=2147483648 The waste factor is used (see /sys/kern/uipc_socket2.c) to make the socket buffer specifed a multiple of 8 (basically your buffers becomes a multiple of 32bits) for efficient usilisation of memory. good luck. Karim Fodil-Lemelin. Xiphos Technologies. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cheng Jin Sent: Monday, September 23, 2002 7:23 PM To: [EMAIL PROTECTED] Subject: TCP receiving buffer Hi all, I am having a hard time setting TCP receiving buffer space to be large than 512K using setsockopt under FreeBSD 4.6.2-RELEASE #0. I have tried playing with various sysctl variables, but I can't seem to break the 512K barrier. I looked at my kernel config file and didn't really find any hard limit either. here are the systcl vars that I have tried. nmbclusters is small, but I should still be able to get about 12 MB of clusters. Any idea on what sockbuf_waste_factor is?? It was 8 by default. Do I have to reduce the number of sockets for this to work? kern.ipc.maxsockbuf: 4094305 kern.ipc.sockbuf_waste_factor: 4 kern.ipc.somaxconn: 512 kern.ipc.nmbclusters: 6656 kern.ipc.nmbufs: 26624 kern.ipc.maxsockets: 12328 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 4094305 Please cc me a copy when you reply. Thank you very much, Cheng 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
TCP for transaction
Here is a tcpdump output from one FreeBSD box with TCP for transaction enabled and a client supporting the NO_PUSH setsockopt with a windows box: 19:00:15.357281 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: SP 4208572194:420 8572331(137) win 65535 (DF) 19:00:15.357514 192.168.2.7.microsoft-ds > 192.168.3.200.1247: S 2795532295:2795 532295(0) ack 4208572195 win 61680 (DF) 19:00:15.357911 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . ack 1 win 52560 (DF) 19:00:18.356736 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P 1:138(137) ack 1 win 52560 (DF) 19:00:18.357465 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P 1:90(89) ack 13 8 win 61646 (DF) 19:00:18.456659 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . ack 90 win 5256 0 (DF) 19:00:20.611227 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P 138:336(198) ac k 90 win 52560 (DF) 19:00:20.612037 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P 90:359(269) ack 336 win 61597 (DF) I see two problems here (in fact its only one problem with a side effect): 1) When sending the ccnew option T/TCP send data with it. 2) As a results the sender times out and retransmit at 19:00:18.356736 adding 3 seconds to the connection data transfer. Now, in the rfc1644 it is stipulated that a host can send data with the cc.new option. I am a bit confused here since T/TCP should accelerate data transfer for small transaction (saving 1 RTT) and not timing out if the destination host does not support it. I think we should avoid sending data with the cc.new option. Any thoughs? Karim Fodil-Lemelin Network Engineering. Xiphos Technologies www.xiphos.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FW: TCP for transaction
> -Original Message- > From: kfl [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 28, 2003 12:53 PM > To: freebsd - net > Subject: TCP for transaction > > > > Here is a tcpdump output from one FreeBSD box with TCP for > transaction enabled and a client supporting the NO_PUSH > setsockopt with a windows box: > > 19:00:15.357281 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: SP > 4208572194:420 > 8572331(137) win 65535 (DF) > 19:00:15.357514 192.168.2.7.microsoft-ds > 192.168.3.200.1247: S > 2795532295:2795 > 532295(0) ack 4208572195 win 61680 (DF) > 19:00:15.357911 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . > ack 1 win 52560 > (DF) > 19:00:18.356736 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P > 1:138(137) ack > 1 win 52560 (DF) > 19:00:18.357465 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P > 1:90(89) ack 13 > 8 win 61646 (DF) > 19:00:18.456659 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . > ack 90 win 5256 > 0 (DF) > 19:00:20.611227 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P > 138:336(198) ac > k 90 win 52560 (DF) > 19:00:20.612037 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P > 90:359(269) ack > 336 win 61597 (DF) > > I see two problems here (in fact its only one problem with a side effect): > > 1) When sending the ccnew option T/TCP send data with it. > 2) As a results the sender times out and retransmit at > 19:00:18.356736 > adding 3 seconds to the connection data transfer. > > Now, in the rfc1644 it is stipulated that a host can send data > with the cc.new option. I am a bit confused here since T/TCP > should accelerate data transfer for small transaction (saving 1 > RTT) and not timing out if the destination host does not support it. > > I think we should avoid sending data with the cc.new option. > > Any thoughs? > > Karim Fodil-Lemelin > Network Engineering. > Xiphos Technologies > www.xiphos.com > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TCP for transaction
Hi, Here is a tcpdump output from one FreeBSD box with TCP for transaction enabled and a client supporting the NOPUSH setsockopt with a windows box: 19:00:15.357281 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: SP 4208572194:420 8572331(137) win 65535 (DF) 19:00:15.357514 192.168.2.7.microsoft-ds > 192.168.3.200.1247: S 2795532295:2795 532295(0) ack 4208572195 win 61680 (DF) 19:00:15.357911 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . ack 1 win 52560 (DF) 19:00:18.356736 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P 1:138(137) ack 1 win 52560 (DF) 19:00:18.357465 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P 1:90(89) ack 13 8 win 61646 (DF) 19:00:18.456659 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . ack 90 win 5256 0 (DF) 19:00:20.611227 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P 138:336(198) ac k 90 win 52560 (DF) 19:00:20.612037 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P 90:359(269) ack 336 win 61597 (DF) I see two problems here (in fact its only one problem with a side effect): 1) When sending the ccnew option T/TCP send data with it. 2) As a results the sender times out and retransmit at 19:00:18.356736 adding 3 seconds to the connection data transfer. Now, in the rfc1644 it is stipulated that a host can send data with the cc.new option. I am a bit confused here since T/TCP should accelerate data transfer for small transaction (saving 1 RTT) and not timing out if the destination host does not support it. I think we should avoid sending data with the cc.new option. Any thoughs? Karim. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TCP for transaction
Hi, Here is a tcpdump output from one FreeBSD box with TCP for transaction enabled and a client supporting the NOPUSH setsockopt with a windows box: 19:00:15.357281 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: SP 4208572194:420 8572331(137) win 65535 (DF) 19:00:15.357514 192.168.2.7.microsoft-ds > 192.168.3.200.1247: S 2795532295:2795 532295(0) ack 4208572195 win 61680 (DF) 19:00:15.357911 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . ack 1 win 52560 (DF) 19:00:18.356736 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P 1:138(137) ack 1 win 52560 (DF) 19:00:18.357465 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P 1:90(89) ack 13 8 win 61646 (DF) 19:00:18.456659 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: . ack 90 win 5256 0 (DF) 19:00:20.611227 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P 138:336(198) ac k 90 win 52560 (DF) 19:00:20.612037 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P 90:359(269) ack 336 win 61597 (DF) I see two problems here (in fact its only one problem with a side effect): 1) When sending the ccnew option T/TCP send data with it. 2) As a results the sender times out and retransmit at 19:00:18.356736 adding 3 seconds to the connection data transfer. Now, in the rfc1644 it is stipulated that a host can send data with the cc.new option. I am a bit confused here since T/TCP should accelerate data transfer for small transaction (saving 1 RTT) and not timing out if the destination host does not support it. I think we should avoid sending data with the cc.new option. Any thoughs? Karim Fodil-Lemelin Network Engineering. Xiphos Technologies www.xiphos.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 4.8 ipcomp
Does anybody has been successfull running ipcomp (alone or over ipsec) on FBSD4.8? Karim. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: grouping 2 or more interfaces as 1
Look into bridge(4). > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hussain Ali > Sent: Thursday, December 11, 2003 2:59 PM > To: [EMAIL PROTECTED] > Subject: grouping 2 or more interfaces as 1 > > > > Hello, > > I am freebsd newbie, so bear with me. I was searching if its possible > to bond 2 ethernet interfaces as 1 under FreeBsd. Ie similiar to > creating a trunk. > > Any references? > > Thanks, > > -Hussain > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
