Re: FreeBSD mail list etiquette
On Sat, Oct 25, 2003 at 11:54:59AM -0700, Terry Lambert wrote: > Frankly, FreeBSD has too many cooks, and not enough bottle washers; > this is a euphimism for saying that all anyone with a commit bit > seems to want to do any more is write new code, and no one is > willing to take on the integration and maintenance tasks. In Linux, > this work is done by Linus, Alan Cox, and a couple of other people. > People get commit bits so that they can do integration, and so that > patches don't sit in bug databases for 6 years unintegrated. > > The problem with this imbalance, is that you seem to be unwilling > to hire bottle washers, and people willing to wash bottles when > there are no clean bottles left are never given any respect, and > certainly not the level of respect accorded to cooks. I believe that's mostly a problem with FreeBSD 5. I partly agree with your analysis, in that too much attention is given to new developments, and not quite enough to stability fixes. Where I differ is that I believe the problem doesn't lie with commit bits attribution, but rather with the inherent complexity of the FreeBSD 5.x kernel. The 5.x kernel is a hell of a lot more difficult to work on than the 4.x kernel. More than once I've been unable to debug stuff myself under 5.x, due to giant push, locking intricacies, KSE, mutexes... The result seems to be that just a few people master each part of the kernel. The others either work by trial-and-error, or don't dare to work at all except in limited, obvious cases or in their area of competence. Two simple things could probably help: - having minimal documentation for developers about how to develop and debug the 5.x kernel, explaining stuff like KSE, mutexes, ... -- this is easier said than done, and a job in itself. Just maintaining -- or advertising -- a set of pointers to relevant man pages and source code samples, explaining the spirit of this stuff, would be a good start. - extending regression tests, trying to add new relevant tests when bugs are fixed. It is also easier said than done, but it is easier to distribute among people. Following Mike Silbersack's suggestion I've been trying to do that for bugs I fix, which as noted above does not happen often these times. On a different note, the checkpoint code announcement which started all this thread seems an extremely interesting functionality to me, thank you Kip for posting this information. -- Pierre Beyssac [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD performing worse than Linux?
On Thu, Nov 29, 2001 at 10:28:09PM -0500, Leo Bicknell wrote: > > I can't reproduce this result, 16K fills a T1 for 11 ms, which is > > 22000 km (at 2/3 of light speed), enough to get halfway round the > > Your math is a little funny. Right, I knew there was something wrong somewhere :-) > 4000 km one way == 8000 km two way, 8000 / 168300 = 47ms in my book, > theoretial optimum. > > With an RTT of 47ms, you can move 16k per RTT, or or about 340k/sec. It's where I don't quite agree: for a bulk transfer, there is no RTT to account for, you only need to take into account the one-way delay, TCP does the rest for you assuming the window is large enough. Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD performing worse than Linux?
On Thu, Nov 29, 2001 at 08:42:25PM -0500, Leo Bicknell wrote: > *grumble* I'll try to avoid my tirade. 16K _will cause problems for > virtually all users_. You can do the math and see it won't keep a T1 > full across country. I can't reproduce this result, 16K fills a T1 for 11 ms, which is 22000 km (at 2/3 of light speed), enough to get halfway round the earth... > This default _really_ needs to be moved to 32k, with an increase in I'm not sure it is necessary. Remember that you can always use SO_RCVBUF/SO_SNDBUF to get bigger buffer sizes, bulk transfer tools can always set it explicitly to 64K if they like. For interactive tools like telnet or ssh, increasing the default size is not really useful. Interestingly enough, ftpd does set SO_SNDBUF, but from a quick glance at the code ftp doesn't seem to set SO_RCVBUF, and neither does fetch. Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD performing worse than Linux?
On Fri, Nov 30, 2001 at 02:25:47AM +0100, Pierre Beyssac wrote: > This is consistent with the value in the backlog shown by netstat, > > What is the value of net.inet.tcp.sendspace on the server? It's 16K Uh, it wouldn't harm, but it won't do much good either on your example. Actually I should have said: increase net.inet.tcp.recvspace to 32K or 64K on the client instead :-) Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD performing worse than Linux?
On Thu, Nov 29, 2001 at 06:44:14PM +, Josh Paetzel wrote: > > Could you try the same in a telnet or rsh connection? I bet it will > > work. > This gives me the same 1.5megs/sec I am getting with ftp. Doesn't > matter whether I use ssh or telnet. Hmm, sorry, looks like I misunderstood John's initial mail then: I thought the ssh session was completely hung. Having said that, I looked more closely at the TCP session, and it looks like the transfer stops simply when the client's receive window is full. Looks quite normal to me. Client announces a window size of 17376: 21:41:46.418208 client.4427 > server.22: . ack 11489 win 17376 (DF) [tos 0x10] Server sends 1448 bytes: 21:41:47.460903 server.22 > client.4427: . 11489:12937(1448) ack 144 win 17376 (DF) [tos 0x10] Client announces a window size of 15928 (17376 - 1448): 21:41:47.569133 client.4427 > server.22: . ack 12937 win 15928 (DF) [tos 0x10] Client consumes some data internally then increases the window size by 1448 bytes (17376 - 15928): 21:41:49.001039 client.4427 > server.22: P 144:192(48) ack 12937 win 17376 (DF) [tos 0x10] Server sends just enough data to fill the window again: 21:41:49.001073 server.22 > client.4427: . 28049:29497(1448) ack 192 win 17328 (DF) [tos 0x10] This is consistent with the value in the backlog shown by netstat, What is the value of net.inet.tcp.sendspace on the server? It's 16K on -stable, it should be very interesting to try and increase it to 32K or 64K, it makes a lot difference on high bw*delay links. Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD performing worse than Linux?
On Thu, Nov 29, 2001 at 12:42:34AM -0500, John Capo wrote: > sent. find / -print | dd obs=1 will screw up within a few seconds > and stay that way. Netstat in another ssh session shows data ready > to go: Hmm, some ssh versions tend to hang randomly on lossy links (in the protocol perhaps, but I haven't ever tried to investigate this). Could you try the same in a telnet or rsh connection? I bet it will work. Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should jail treat ip-number?
On Tue, Nov 09, 1999 at 12:54:45PM +0900, Yoshinobu Inoue wrote: > Currentlly jail set an ip-number and let prisoned processes > only to bind it. [ the current jail(2) interface and its future WRT IPv6 ] > I think kernel change will not so much for any above addition > or changes, but there will be some backword compatibility > issue for API. (some member addition to the jail structure, > and jail command extensions) There's been a discussion a few weeks ago on freebsd-security on this very matter. See attached mail below. The conclusion was that jail(2) should be fixed to use a sockaddr instead of a 32 bit int to specify the address. That seems to be the first logical step, even before making jail(2) IPv6-compliant. Pierre Date: Sun, 19 Sep 1999 11:58:39 -0400 (EDT) From: Garrett Wollman <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> To: Matthew Dillon <[EMAIL PROTECTED]> Cc: Poul-Henning Kamp <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> < said: > struct sockaddr is the standard for specifying an IP address. Jail > isn't using it, not even for IPV4. It's using an unsigned 32 bit int. > Hell, it isn't even using a struct in_addr! The field is plain and > simply inappropriately specified in the structure. For once, I agree with Matt. As titular networking czar, I'm asking you, Poul, to please fix the interface. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARPs on a bridge
On Tue, Oct 05, 1999 at 10:21:36AM -0400, Dennis wrote:
> Is there a way to force a Freebsd system to route to the same logican IP
> network rather than send a redirect?
Uhm, did you try this?
sysctl -w net.inet.ip.redirect=0
BTW, whether or not sending redirects, the original packet is always
routed to its destination.
--
Pierre Beyssac[EMAIL PROTECTED] [EMAIL PROTECTED]
{Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher
Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tcpdump(1) additions.
On Tue, Jun 29, 1999 at 06:54:06PM -0400, Bill Fumerola wrote:
> Unless there is strong feelings against it, I'd like to commit the smb
> patches (as seen on www.samba.org)
Could you elaborate some more about the SMB patches? I've been to
www.samba.org but it's not obvious to me what's in there for FreeBSD
(except for samba itself).
> and ipsec/ike patches (recently mailed
> to the tcpdump mailing list and [EMAIL PROTECTED]) to tcpdump(1).
>
> Comments?
The IPSEC/IKE stuff for tcpdump seems like a great thing to have!
--
Pierre Beyssac[EMAIL PROTECTED] [EMAIL PROTECTED]
{Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher
Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tcpdump(1) additions.
On Tue, Jun 29, 1999 at 06:54:06PM -0400, Bill Fumerola wrote:
> Unless there is strong feelings against it, I'd like to commit the smb
> patches (as seen on www.samba.org)
Could you elaborate some more about the SMB patches? I've been to
www.samba.org but it's not obvious to me what's in there for FreeBSD
(except for samba itself).
> and ipsec/ike patches (recently mailed
> to the tcpdump mailing list and b...@freebsd.org) to tcpdump(1).
>
> Comments?
The IPSEC/IKE stuff for tcpdump seems like a great thing to have!
--
Pierre Beyssacp...@fasterix.frmug.org p...@fasterix.freenix.org
{Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD, GPL, the world today.
On Sat, May 15, 1999 at 01:48:23AM +0100, Nik Clayton wrote:
> Didn't Knuth say "I've only proven TeX to be correct, I haven't tested
> it" or some such?
That's a quote in /usr/src/games/fortune/datfiles/fortunes:
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
-- Donald Knuth
--
Pierre Beyssacp...@fasterix.frmug.org p...@fasterix.freenix.org
{Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
