Date: Mon, 11 Dec 2006 02:05:39 -0600 From: Craig Boston <craig@feniz.gank.org> To: David Gilbert <dgilbert@dclg.ca> Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein <uspoerlein@gmail.com> Subject: Re: ggate still broken on 6.2-RC1 for amd64. Message-ID: <20061211080539.GA47265@nowhere> In-Reply-To: <17789.3357.574773.690262@canoe.dclg.ca> References: <17774.32960.176956.52924@canoe.dclg.ca> <20061203171221.GB2369@roadrunner.q.local> <20061211024353.GA1220@nowhere> <17789.3357.574773.690262@canoe.dclg.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 11, 2006 at 02:47:41AM -0500, David Gilbert wrote: > That doesn't square with my experience. Although bigger buffers could > be involved in a performance problem, what we're dealing with here is > a _zero_ traffic situation. It seems that it works enough for tasting > to be successful, but any significant load wedges it hard. The problem I observed was also a zero traffic situation. A quick way to test is to do something like this (assuming you don't care about the contents of the device!) dd if=/dev/zero of=/dev/ggateX bs=1m and watch the network traffic to see what happens. When I ran into it, small block sizes worked fine, but anything bigger than the send buffer size would cause the entire ggate device to wedge with zero traffic. The ggatec logs in my mail archive say 128k, which itself is a little odd because I thought GEOM broke big transfers into 64k chunks. In any case, ggatec got stuck in a loop getting EAGAIN from send(), so the packets never made it out to the wire. However checking my mail archive also indicates that was a year ago so chances are this is a different problem. The symptoms just sounded a little familiar. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061211080539.GA47265>