Re: mbuf tuning
On Mon, 19 Jan 2004, CHOI Junho wrote: Hi, What is general guidelines of mbuf cluster tunables? I usually use There are no good guidelines other than don't set it too high. Andre and I have talked about some ideas on how to make mbuf usage more dynamic, I think that he has something in the works. But at present, once you hit the wall, that's it. One way to reduce mbuf cluster usage is to use sendfile where possible. Data sent via sendfile does not use mbuf clusters, and is more memory efficient. If you run 5.2 or above, it's *much* more memory efficient, due to change Alan Cox recently made. Apache 2 will use sendfile by default, so if you're running apache 1, that may be one reason for an upgrade. Increasing kern.ipc.nmbclusters caused frequent kernel panic under 4.7/4.8/4.9. How can I set more nmbclusters value with 64K tcp buffers? Or is any dependency for mbufclusters value? (e.g. RAM size, kern.maxusers value or etc) p.s. RAM is 2G, Xeon 2.0G x 1 or 2 machines. You probably need to bump up KVA_PAGES to fit in all the extra mbuf clusters you're allocating. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: forged tsecr giving -ve numbers in rtt calculation causing retran
On Fri, 16 Jan 2004, Richard Wendland wrote: I'd hazard a guess that you are seeing zero, not forged, TSECRs. Windows sets TSECR zero on SYN-ACK when it does a passive open. This is established Windows behaviour for several years, and there is a reading of RFC1323 that might justify this. Hm, wasn't this accounted for in rev 1.174 / 1.107.2.31? From Matt's commit log: --- ... FreeBSD sends a timestamp with the SYN, W2K returns a timestamp of 0 in the SYN+ACK causing FreeBSD to calculate an insane SRTT and RTT, resulting in a maximal retransmit timeout (60 seconds). ... This commit works around the W2K bug. --- Of course, that doesn't account for other non-zero strange values. I guess the timestamp code needs a lot of work. :( Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PPPOE server with pppoed and mppe
Hi, G How much Mbytes/sec have you got with MPPE? I get about 70-80 kbytes/s, while without encrytion the speed is 150-160 kbytes/s (and that's my hardware limit). A friend of mine tested my configuration in a LAN and got no decrease in the performance with encryption added. I am going to try to exclude the VLAN and VDSL parts (over which my connection goes) and see what happens. It seems that no one has seen this problem before, so it must be something specific for my configuration. I'll post a follow-up as soon as I discover the problem. Thanks for the cooperation though :) Regards, Emil Filipov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
netgraph questions on ng_tee, ng_iface, ng_socket
hey all, am beginning to learn on how to manipulate netgraph nodes. i've read archie cobbs' paper at http://www.daemonnews.org/23/netgraph.html and it provided a good backgrounder on using netgraph. i'm now playing around with ng_socket, ng_tee, ng_one2many and ng_iface to accomplish round robin routing for a freebsd box with two interfaces going to two ISPs. what i intent to achieve in principle is to have packets going out alternately over each of the two interfaces with source ip address set to the appropriate interface so the reply packets come back in properly. i looked at the examples which archie gave in the daemonnews paper, and am a little stumped at the behaviour of the whole thing. this could be due to my lack of understanding of the whole thing. what i want do is similar to this: i presently have two NICs on the box, fxp0 (192.168.0.5) and aue0 (10.1.1.25). both fxp0 and aue0 go out to different ISPs. currently, default route is thru ISP1 on fxp0, i.e. defroute to 192.168.0.1. what i want to do is to round robin outgoing packets across both ISP links, i.e. one packet out on fxp0 then the next out on aue0 and then the next out on fxp0 ad nauseaum. of course, packets going out on fxp0 will have a src address of 192.168.0.5 and packets going out on aue0 will have a src address of 10.1.1.25. create a new interface (presumably using ng_iface). give this iface an ip address, set the default route thru this iface (ng0). then, using ng_one2many, chain ng0 to both fxp0 and aue0. an example to do this for ethernet frames is given in the ng_one2many(4) man page, however i want to do it for IP packets with the underlying src address being changed where appropriate. i need some understanding on what exactly ng_iface achieves, as it makes a reference to the hook inet being connected to something. however, connecting the ng_iface hook inet to ng_ether's upper or lower doesnt make any sense because ng_ether itself does not do an encasulation of the IP packet into an ethernet frame. or am i wrong here, and just configuring it wrongly ? any pointers/explanations would sure help a lot. thanx in advance. Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf tuning
From: Mike Silbersack [EMAIL PROTECTED] Subject: Re: mbuf tuning Date: Mon, 19 Jan 2004 01:12:08 -0600 (CST) There are no good guidelines other than don't set it too high. Andre and I have talked about some ideas on how to make mbuf usage more dynamic, I think that he has something in the works. But at present, once you hit the wall, that's it. One way to reduce mbuf cluster usage is to use sendfile where possible. Data sent via sendfile does not use mbuf clusters, and is more memory efficient. If you run 5.2 or above, it's *much* more memory efficient, due to change Alan Cox recently made. Apache 2 will use sendfile by default, so if you're running apache 1, that may be one reason for an upgrade. I am using custom version of thttpd. It allocates mmap() first(builtin method of thttpd), and it try to use sendfile() if mmap() fails(out of mmap memory). It really works good in normal status but the problem is that sendfile buffer is also easy to flood. I need more sendfile buffers but I don't know how to increase sendfile buffers either(I think it's hidden sysctl but it was more difficult to tune than nmbclusters). With higher traffic, thttpd sometimes stuck at sfbufa status when I run top(I guess it's sendfile buffer allocation status). 5.2 is fair good quality in my desktop but I have no experience in production environment. I'll consider it once 5.x enters -STABLE tree, but not now. Apache2 is one of my targets. How much better than apache-1.3.x in static file service? Increasing kern.ipc.nmbclusters caused frequent kernel panic under 4.7/4.8/4.9. How can I set more nmbclusters value with 64K tcp buffers? Or is any dependency for mbufclusters value? (e.g. RAM size, kern.maxusers value or etc) p.s. RAM is 2G, Xeon 2.0G x 1 or 2 machines. You probably need to bump up KVA_PAGES to fit in all the extra mbuf clusters you're allocating. Can you tell me in more detail? Mike Silby Silbersack Thanks, -- CHOI Junho http://www.kr.FreeBSD.org/~cjh KFUG cjh at kr.FreeBSD.org FreeBSD Project cjh at FreeBSD.orgWeb Data Bank cjh at wdb.co.kr Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf tuning
On Mon, 19 Jan 2004, 19:22+0900, CHOI Junho wrote: From: Mike Silbersack [EMAIL PROTECTED] Subject: Re: mbuf tuning Date: Mon, 19 Jan 2004 01:12:08 -0600 (CST) There are no good guidelines other than don't set it too high. Andre and I have talked about some ideas on how to make mbuf usage more dynamic, I think that he has something in the works. But at present, once you hit the wall, that's it. One way to reduce mbuf cluster usage is to use sendfile where possible. Data sent via sendfile does not use mbuf clusters, and is more memory efficient. If you run 5.2 or above, it's *much* more memory efficient, due to change Alan Cox recently made. Apache 2 will use sendfile by default, so if you're running apache 1, that may be one reason for an upgrade. I am using custom version of thttpd. It allocates mmap() first(builtin method of thttpd), and it try to use sendfile() if mmap() fails(out of mmap memory). It really works good in normal status but the problem is that sendfile buffer is also easy to flood. I need more sendfile buffers but I don't know how to increase sendfile buffers either(I think it's hidden sysctl but it was more difficult to tune than nmbclusters). With higher traffic, thttpd sometimes stuck at sfbufa status when I run top(I guess it's sendfile buffer allocation status). man 2 sendfile, man 7 tuning are a good start. In 5.2 you can monitor sendfile buffers usage via kern.ipc.nsfbufs* sysctls or netstat(1). [...] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Multihomed UDP server
Simple question: Very simple UDP server daemon. Many clients (connect(2)'ing a socket for each is not an option) Multihomed machine. What's the simple trick to replying with the same source-IP as the client used as destination-IP ? Notice I said simple, monitoring the routetable or polling the interface configuration does not count as simple. It seems to me that if there is no simple way to do this, it's about time we added it... As I see it, we need recvfromto() and sendtofrom(). Any takers ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multihomed UDP server
On Mon, 19 Jan 2004, 12:07+0100, Poul-Henning Kamp wrote: Simple question: Very simple UDP server daemon. Many clients (connect(2)'ing a socket for each is not an option) Multihomed machine. What's the simple trick to replying with the same source-IP as the client used as destination-IP ? Probably bin/58012 worth to look (Multihomed tftpd enhancement). Yes, it relies on protocol but still. [...] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multihomed UDP server
In message [EMAIL PROTECTED], Maxim Konovalov writes: On Mon, 19 Jan 2004, 12:07+0100, Poul-Henning Kamp wrote: Simple question: Very simple UDP server daemon. Many clients (connect(2)'ing a socket for each is not an option) Multihomed machine. What's the simple trick to replying with the same source-IP as the client used as destination-IP ? Probably bin/58012 worth to look (Multihomed tftpd enhancement). Yes, it relies on protocol but still. But that's not a general solution, and it certainly doesn't solve the problem for my application. I'm considering ways to make sendmsg(2)/recvmsg(2) DTRT, and my current candidate is give them a flag bit which says msg_name has both addresses. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netgraph questions on ng_tee, ng_iface, ng_socket
Hi all, Monday, January 19, 2004, 12:34:25 PM, you wrote: DN hey all, skiped DN i need some understanding on what exactly ng_iface achieves, as it makes a DN reference to the hook inet being connected to something. however, DN connecting the ng_iface hook inet to ng_ether's upper or lower doesnt make DN any sense because ng_ether itself does not do an encasulation of the IP DN packet into an ethernet frame. or am i wrong here, and just configuring it DN wrongly ? DN any pointers/explanations would sure help a lot. thanx in advance. Connecting ng_iface:inet and ng_ether:upper/lower do nothing, well, it do something but not what you are waiting for, i think. As wrotes in man ng_iface: This node type supports the following hooks: inetTransmission and reception of IP packets. ng_iface works with IP-packets, but ng_ether works with ethernet frames, so connecting it together require at least transformation module between IP-packets and ether-frames. -- Andrewmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multihomed UDP server
In message [EMAIL PROTECTED], Randall R. Stewart (home) writes: On Mon, 19 Jan 2004, 12:07+0100, Poul-Henning Kamp wrote: Simple question: Very simple UDP server daemon. Many clients (connect(2)'ing a socket for each is not an option) Multihomed machine. What's the simple trick to replying with the same source-IP as the client used as destination-IP ? I'm considering ways to make sendmsg(2)/recvmsg(2) DTRT, and my current candidate is give them a flag bit which says msg_name has both addresses. Following the code it seems that it is in fact possible to do with sendmsg(2)/recvmsg(2) already, and my test shows that at least the receive side works. I challenge anybody to point out where this is mentioned in the docs, and once people give up I'll tell how to do it :-) Poul: One of the problems I think that is fundamental to BSD and multi-homing is the lack of supports for multiple-default routes. I agree. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PPPoE problem: Too many LQR packets lost
On Sun, 18 Jan 2004 13:52:24 -0500, in sentex.lists.freebsd.net you wrote: BTW, the lcp.c patch suggested by someone else is not the correct approach. It would be great to see a proper config option disable it. However, I dont see any such patches. In the mean time, it works for me. Otherwise pppoe is pretty broken in that there is no link state detection. ---Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PPPoE problem: Too many LQR packets lost
[EMAIL PROTECTED] wrote: [ ... ] Short of actually fixing this LQR negotiation issue (?), might the suggestion of a ppp.conf option to force LCP echo usage be good? Yes. I am surprized it doesn't already have that option since thats a more common scenario. Alternately you could use another pppoe implementation, perhaps the one based on pppd/netgraph. BTW, the lcp.c patch suggested by someone else is not the correct approach. There also seems to be a problem with the way the FreeBSD kernel PPP implementation handles LQR and you can see it in the log below. (The unisphere at the other end isn't perfect either and has its own issues!) regards, niranjan Thanks for your analysis Niranjan. Could you please elaborate on what you meant about the lcp.c patch not being the correct approach? I think Mike has tested it in multiple situations, and it has worked well for a guy in the same situation down here too. cheers, nik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Two ISP lines
Ok, I asked already asked something similar to this in the past, but it's not the same thing... maybe it's a trivial question... If I had two lines to the Internet: how would I use both? Could I just provide two default routes? How? What algorithm would be used to choose among the two? What if one failed? bye Thanks av. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Two ISP lines
On Mon, 19 Jan 2004, Andrea Venturoli wrote: lines to the Internet: how would I use both? Could I just provide two default routes? How? What algorithm would be used to choose among the two? What if one failed? seems to be the topic of the week over at freebsd-questions. short end of the stick is, freebsd as it is today does not do multipath routing, so you cant add a default route to two gateways for round robin usage. however, there was a multipath patch for 4-STABLE some months back, though for the life of me, i don't know where it's archived anymore. check -questions archives for this thread. Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netgraph questions on ng_tee, ng_iface, ng_socket
On Mon, 19 Jan 2004, Andrew Riabtsev wrote: DN connecting the ng_iface hook inet to ng_ether's upper or lower doesnt make DN any sense because ng_ether itself does not do an encasulation of the IP DN packet into an ethernet frame. or am i wrong here, and just configuring it DN wrongly ? Connecting ng_iface:inet and ng_ether:upper/lower do nothing, well, it do something but not what you are waiting for, i think. i know, hence was asking if there was something i could do, even if it meant writing an extension to ng_ether to create a new netgraph type. Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description --- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Two ISP lines
On Tue, Jan 20, 2004 at 01:50:57AM +0800, Dinesh Nair wrote: there was a multipath patch for 4-STABLE some months back, though for the life of me, i don't know where it's archived anymore. Are you referring to these patches? http://lists.freebsd.org/pipermail/freebsd-hackers/2003-July/001843.html -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Two ISP lines
On Monday 19 January 2004 18:50, Dinesh Nair wrote: On Mon, 19 Jan 2004, Andrea Venturoli wrote: lines to the Internet: how would I use both? Could I just provide two default routes? How? What algorithm would be used to choose among the two? What if one failed? seems to be the topic of the week over at freebsd-questions. short end of the stick is, freebsd as it is today does not do multipath routing, so you cant add a default route to two gateways for round robin usage. however, there was a multipath patch for 4-STABLE some months back, though for the life of me, i don't know where it's archived anymore. check -questions archives for this thread. take a look at secuirty/pf (from ports) it can make use of more than one uplink. It provides round-robin and source-hash load balancing and you can define even finer policy routing with it. It works currently for 5.x only, for a 4.x version check KAME. -- Best regards, | [EMAIL PROTECTED] Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multihomed UDP server
In message [EMAIL PROTECTED], Garrett Wollman writes: On Mon, 19 Jan 2004 12:58:00 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said: I'm considering ways to make sendmsg(2)/recvmsg(2) DTRT, and my current candidate is give them a flag bit which says msg_name has both addresses. Um, they already do the right thing. That's what the IP_RECVDESTADDR option (and its dual whose name I forget right now) is all about. Yeah, I found that out. Now, where on the earth is that documented ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multihomed UDP server
In message [EMAIL PROTECTED], Bjo ern A. Zeeb writes: You mean for FreeBSD or in ISBN 0-13-490012-X ? For FreeBSD it is man 4 ip: --- cite --- If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the destination IP address for a UDP data- gram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: --- cite --- That really belongs on udp(4) more than ip(4)... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multihomed UDP server
On Mon, 19 Jan 2004, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Garrett Wollman writes: On Mon, 19 Jan 2004 12:58:00 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said: I'm considering ways to make sendmsg(2)/recvmsg(2) DTRT, and my current candidate is give them a flag bit which says msg_name has both addresses. Um, they already do the right thing. That's what the IP_RECVDESTADDR actually it is IP_RECVDSTADDR (no E). option (and its dual whose name I forget right now) is all about. Yeah, I found that out. Now, where on the earth is that documented ? You mean for FreeBSD or in ISBN 0-13-490012-X ? For FreeBSD it is man 4 ip: --- cite --- If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the destination IP address for a UDP data- gram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: --- cite --- -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf tuning
On Mon, 19 Jan 2004, CHOI Junho wrote: From: Mike Silbersack [EMAIL PROTECTED] Subject: Re: mbuf tuning Date: Mon, 19 Jan 2004 01:12:08 -0600 (CST) There are no good guidelines other than don't set it too high. Andre and I have talked about some ideas on how to make mbuf usage more dynamic, I think that he has something in the works. But at present, once you hit the wall, that's it. One way to reduce mbuf cluster usage is to use sendfile where possible. Data sent via sendfile does not use mbuf clusters, and is more memory efficient. If you run 5.2 or above, it's *much* more memory efficient, due to change Alan Cox recently made. Apache 2 will use sendfile by default, so if you're running apache 1, that may be one reason for an upgrade. I am using custom version of thttpd. It allocates mmap() first(builtin method of thttpd), and it try to use sendfile() if mmap() fails(out of mmap memory). It really works good in normal status but the problem is that sendfile buffer is also easy to flood. I need more sendfile buffers but I don't know how to increase sendfile buffers either(I think it's hidden sysctl but it was more difficult to tune than nmbclusters). With higher traffic, thttpd sometimes stuck at sfbufa status when I run top(I guess it's sendfile buffer allocation status). In 4.x you have to rebuild the kernel with options NSFBUFS=16384 It equals to (512 + maxusers * 16) by default. By the way, why do you want to use the big net.inet.tcp.sendspace and net.inet.tcp.recvspace ? It makes a sense for Apache but thttpd can easy work with the small buffers, say, 16K or even 8K. Increasing kern.ipc.nmbclusters caused frequent kernel panic under 4.7/4.8/4.9. How can I set more nmbclusters value with 64K tcp buffers? Or is any dependency for mbufclusters value? (e.g. RAM size, kern.maxusers value or etc) p.s. RAM is 2G, Xeon 2.0G x 1 or 2 machines. You probably need to bump up KVA_PAGES to fit in all the extra mbuf clusters you're allocating. Can you tell me in more detail? From LINT: --- # # Change the size of the kernel virtual address space. Due to # constraints in loader(8) on i386, this must be a multiple of 4. # 256 = 1 GB of kernel address space. Increasing this also causes # a reduction of the address space in user processes. 512 splits # the 4GB cpu address space in half (2GB user, 2GB kernel). # options KVA_PAGES=260 --- Default KVA_PAGES are 256. Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: forged tsecr giving -ve numbers in rtt calculation causing retran
Hm, wasn't this accounted for in rev 1.174 / 1.107.2.31? From Matt's commit log: True. My notes must have been from an older version. Sorry. Of course, that doesn't account for other non-zero strange values. I guess the timestamp code needs a lot of work. :( This does suggest Ken is seeing TSecr messed up in some other way than simple zeroing. I'd expect this to be a pretty rare event, and perhaps my suggestion that the 64 sec TCPTV_REXMTMAX limit be implemented correctly is a good enough solution on its own for a rare event. It should certainly avoid the insane -45000 tp-t_rxtcur Ken has seen. It's simple to implement, does what was probably originally intended, and also protects from bizarre problems with non-timestamp option SRTT calculation. Full validation of TSecr would be nice, but perhaps excessive for something that should not happen. A 64 second RTO may discourage such strangeness :) Richard -- Richard Wendland[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PPPoE problem: Too many LQR packets lost
[EMAIL PROTECTED] wrote: Thanks for your analysis Niranjan. Could you please elaborate on what you meant about the lcp.c patch not being the correct approach? I think Mike has tested it in multiple situations, and it has worked well for a guy in the same situation down here too. cheers, nik Hi Nik, The comment was from the perspective of a long term cleanup of the LQM code. For instance, lqr.c currently assumes that you can either enable LQR or LCP echoes, but not both at the same time. The RFCs, however, do not disallow this scenario and LCP echoes have other uses beyond link quality monitoring. If Mike's patch offers a short term solution for your needs, go for it! (Although, I am wondering, how it would be different, if you simply did not enable LQR in ppp.conf. lqr_Setup() in lqr.c sets LQM_ECHO by default. If LQM_LQR is not set, the code will fall back to sending LCP echoes.. see SendLqrReport()...I haven't looked at this version of PPP in the greatest detail, so its possible there is a clause somewhere preventing this...) Regards, Niranjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
timersub/timeradd/timercmp
could anyone let me know why timersub/add/cmp are disabled in the kernel? they were introduced in 4.4BSD, and (non-)availability of these macro makes it difficult for kame/rrs to deal with multiple *BSDs. (guessing: are you trying to enforce the use of timespec in the kernel?) itojun ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
