Date: Thu, 10 Apr 2003 15:11:42 +0200 From: Borje Josefsson <bj@dc.luth.se> To: Eric Anderson <anderson@centtech.com> Cc: David Gilbert <dgilbert@velocet.ca> Subject: Re: tcp_output starving -- is due to mbuf get delay? Message-ID: <200304101311.h3ADBgjY022790@samson.dc.luth.se> In-Reply-To: Your message of Thu, 10 Apr 2003 07:31:25 CDT. <3E95641D.1080100@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Apr 2003 07:31:25 CDT Eric Anderson wrote: > David Gilbert wrote: > >>>>>>"Jin" =3D=3D Jin Guojun <[DSD]" <j_guojun@lbl.gov>> writes: > >>>>> > > = > > Jin> Some details was left behind -- The machine is 2 GHz Intel P4 > > Jin> with 1 GB memory, so the delay is not from either CPU or lack of= > > Jin> memory. > > = > > I just want to quickly jump in with the comment that our GigE tests o= f > > routing through FreeBSD have exposed several-order-of-magnitude > > differences by changing ram/motherboard/which-slot-the-card-is-in. > > = > > Do not assume that a fast CPU is the key. We went through 10 > > motherboards to commission the current routers ... and sometimes > > faster cpus would route slower (in various combinations of > > motherboards and RAM). > = > Wow - this is very interesting. I have two machines with GigE in them,= = > one has 6 gige nics (intel pro/1000T server), in a dual Xeon 1.5Ghz = > (P4), with 2gb of ram. I haven't put it into production yet, so if = > there are any tests I can do, let me know. It would be good to know th= e = > pitfalls before I bring it up live.. :) > = I am also *very* interested in participating in this. I did apply [some = version of] Sean Chittendens patch, but that didn't help. With that patch= = applied my system deadlocked(?) when stressing it vith ttcp. To me (but = bear in mind that I'm not at all a kernel hacker) one of the if-statement= s = in the patch seem to cover to little - i.e. when having the fastscan OIS = unset - code that has to do with fastscan is still executed, at least in = the version I tried. I get Mar 27 11:42:41 stinky kernel: sbappend: bad tail 0x0xc0ef8200 instead of= = 0x0xc0ef4b00 when "fastscan" is unset. I have two test systems with xeon CPUs, that can handle a 1000 km (21 ms)= = full speed GE-connection quite well with NetBSD (I get approx 970 Mbit/se= c = with ttcp), but I run out of CPU when using FreeBSD long before I can fil= l = then network. I could stay with NetBSD, but since I am used to FreeBSD I'= d = rader have that instead. We have tested with Linux too on the same = distance, and it seems that they can handle this too. What we did in NetBSD (-current) was to increase IFQ_MAXLEN in (their) = sys/net/if.h, apart from that it's only "traditional" TCP tuning. My hosts are connected directly to core routers in a 10Gbps nationwide = network, so if anybody is interested in some testing I am more than = willing to participate. If anybody produces a patch, I have a third syste= m = that I can use for piloting of that too. --B=F6rje
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304101311.h3ADBgjY022790>