Date: Fri, 13 Jul 2001 15:12:57 -0400 From: Leo Bicknell <bicknell@ufp.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Leo Bicknell <bicknell@ufp.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Network performance roadmap. Message-ID: <20010713151257.A27664@ussenterprise.ufp.org> In-Reply-To: <3B4F4534.37D8FC3E@mindspring.com>; from tlambert2@mindspring.com on Fri, Jul 13, 2001 at 12:00:04PM -0700 References: <20010713101107.B9559@ussenterprise.ufp.org> <3B4F4534.37D8FC3E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 13, 2001 at 12:00:04PM -0700, Terry Lambert wrote: > Not quite true. They are administratively limited, because of > the artificial fixed ratio of mbufs to clusters. This is a > design problem, not a physical limitation. I understand they are administratively limited. Also, I understand that it's not a limit, on the sender side it _is_ the buffer size used assuming more than one window of data is transfered by the application. > > B) When the system runs out of MBUF's, really bad things happen. It > > would be nice to make the system handle MBUF exhaustion in a nicer > > way, or avoid it. > > The easiest way to do this is to know ahead of time how many > you _really_ have. Then bad things don't happen. Clearly not true. The system knows how many it has today, at compile time in fact, and takes no steps to keep them from being exhaused. You'll notice I proposed a mechanism to keep them from being exhausted, a mechanism that degrades performance in a very gentle manor when the limit is reached. > Socket buffers are set at boot time. Read the code. Same for > maximum number of connections: you can hop around until you > are blue in the face from typing "sysctl", but it will not > change the number of tcpcb's and inpcb's, etc.. This is an > artifact of the allocator. Right, and as I said before, these are not a limiting resource. The problem is not even a lack of MBUF's (ie, we don't really need more) we just need to be more intelligent about how we use them per connection. I'm curious where you got the impression that other things need to be changed. None of the papers, including the ones you mention, suggest that other items need to be changed to support high bandwidth data connections. > Having larger transmit windows is really dependent on the > type of traffic you expect to serve; in the HTTP case, the > studies indicate that the majority of objects served are > less than 8k in size. Most browsers (except Opera) do > not suport PIPELINING. So we should optimize for HTTP, and tell the people running FTP servers, or news serves, or home desktops sharing files with friends that "tough, we like big web servers"? Let's find a solution that works for all of the above. > Only after you have proven that some significant fraction > of traffic actually ends up hitting the window size limits, > should you make this change to FreeBSD proper. "Significant fraction" will change with the server you monitor. I'll bet, for instance, most all hub news servers hit the per window limit on every connection, as they are sending large streaming amounts of bulk data. I bet FTP sites hit the problem for well more than 10% of their clients, as the people likely to download the 100 Meg demo of XYZ Shoot-Em-Up are unlikely to be on a modem. Again, there's a solution here that works for everyone. > One good way to prevent this is to not unreasonably set > your window size... 8-p. Ah, I see, so to prevent MBUF exhaustion I should not let my socket buffers get large. Sort of like to prevent serious injury in a car crash I should drive at 10MPH on the freeway. Performance limits to save a system from crashing should be a last resort. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010713151257.A27664>