From owner-freebsd-geom@FreeBSD.ORG Fri Oct 17 01:26:21 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1430C8D3 for ; Fri, 17 Oct 2014 01:26:21 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0078.outbound.protection.outlook.com [157.56.111.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE120C37 for ; Fri, 17 Oct 2014 01:26:19 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 17 Oct 2014 01:10:12 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.00.1049.012; Fri, 17 Oct 2014 01:10:12 +0000 From: "Pokala, Ravi" To: "freebsd-geom@freebsd.org" Subject: Minor addition to confdot (w/ patch) Thread-Topic: Minor addition to confdot (w/ patch) Thread-Index: AQHP6acZ20Kw8n8E9Em2C83KYVfWKA== Date: Fri, 17 Oct 2014 01:10:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.80.217.3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0944; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(189002)(199003)(107886001)(106356001)(77096002)(105586002)(229853001)(120916001)(80022003)(66066001)(40100003)(86362001)(54356999)(2351001)(99286002)(107046002)(2656002)(95666004)(85852003)(99396003)(106116001)(21056001)(87936001)(76482002)(85306004)(92566001)(101416001)(97736003)(31966008)(110136001)(122556002)(83506001)(20776003)(64706001)(36756003)(19580395003)(50986999)(92726001)(46102003)(4396001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0944; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <14E0127C728B2A40B686A22A768C6B08@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:26:21 -0000 Hi folks, The GEOM stack diagrams created by 'sysctl -b kern.geom.confdot' (and then run through `dot') are really quite handy. One thing that we really needed at Panasas, but which is not included in the diagram, is the providers' sectorsize and stripesize. This small change adds that info; if there are no objections, could someone submit it on my behalf? Thanks, Ravi Index: sys/geom/geom_dump.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/geom/geom_dump.c (revision 273186) +++ sys/geom/geom_dump.c (working copy) @@ -61,8 +61,8 @@ g_confdot_provider(struct sbuf *sb, struct g_provider *pp) { =20 - sbuf_printf(sb, "z%p [shape=3Dhexagon,label=3D\"%s\\nr%dw%de%d\\nerr#%d\"];\n", - pp, pp->name, pp->acr, pp->acw, pp->ace, pp->error); + sbuf_printf(sb, "z%p [shape=3Dhexagon,label=3D\"%s\\nr%dw%de%d\\nerr#%d\\nsector=3D%d\\nstripe= =3D%d\"];\ n", + pp, pp->name, pp->acr, pp->acw, pp->ace, pp->error, pp->sectorsize, pp->stripesize); } =20 static void From owner-freebsd-geom@FreeBSD.ORG Fri Oct 17 06:59:51 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A0AEBB5 for ; Fri, 17 Oct 2014 06:59:51 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 94EC84494; Fri, 17 Oct 2014 06:59:50 +0000 (UTC) Message-ID: <5440BDF5.7090101@FreeBSD.org> Date: Fri, 17 Oct 2014 10:57:57 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Pokala, Ravi" , "freebsd-geom@freebsd.org" Subject: Re: Minor addition to confdot (w/ patch) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 06:59:51 -0000 On 17.10.2014 05:10, Pokala, Ravi wrote: > Hi folks, > > The GEOM stack diagrams created by 'sysctl -b kern.geom.confdot' (and then > run through `dot') are really quite handy. One thing that we really needed > at Panasas, but which is not included in the diagram, is the providers' > sectorsize and stripesize. This small change adds that info; if there are > no objections, could someone submit it on my behalf? Hi, committed with r273208. -- WBR, Andrey V. Elsukov From owner-freebsd-geom@FreeBSD.ORG Fri Oct 17 12:04:58 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFFEF670 for ; Fri, 17 Oct 2014 12:04:57 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B135CDF8 for ; Fri, 17 Oct 2014 12:04:57 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tp5so579122ieb.14 for ; Fri, 17 Oct 2014 05:04:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WU6RvMs84/3ZNrGeeenHvROHr/UCI2ZHDrBsaRh/iBc=; b=mzWj3XL5GwL28KuvyMmWC60SH2BDJXLVM1RUW3FOlw0SIseIRFzpW4Maj43KgEXfiS 8KLRjiZ8qlQOgUbNXlALWQ3EIBkHNEOzxKWlf41evSfpqpgJMPa5vSXNAf+AfWq67vQr 11rQnerRp36biJoOkcF+VSfOSNUedvMiO+G9snM+YM6pv6oN61H5jdqz9y9/X8lkmVUI DNqkwc4NZJfmsjjRxOHXG1WWm9zebD9vF4uWC/9Fz4w1dMPKNjNPWcRBzTBLmh1UjDI4 Oq39avhK956E71zX5ljpjYjhTM5i03F1vkXS6MTdmG4dIEqVnXVK/NtEZa1IbqrmnKqe lYUw== X-Gm-Message-State: ALoCoQn1A0SiwQMNVUcu8A2CrC5GIyBgJyhBf4bc2SWQRvImKxAFgCB7J0JjbkAMdJ66LzGfv5S8 MIME-Version: 1.0 X-Received: by 10.42.8.70 with SMTP id h6mr1253730ich.85.1413547489293; Fri, 17 Oct 2014 05:04:49 -0700 (PDT) Received: by 10.107.9.8 with HTTP; Fri, 17 Oct 2014 05:04:49 -0700 (PDT) Date: Fri, 17 Oct 2014 17:34:49 +0530 Message-ID: Subject: geom gate network From: Sourish Mazumder To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:04:58 -0000 Hi, I am planning to use geom gate network for accessing remote disks. I set up geom gate as per the freebsd handbook. I am using freebsd 9.2. I am noticing heavy performance impact for disk IO when using geom gate. I am using the dd command to directly write to the SSD for testing performance. The IOPS gets cut down to 1/3 when accessing the SSD remotely over a geom gate network, compared to the IOPS achieved when writing to the SSD directly on the system where the SSD is attached. I thought that there might be some problems with the network, so decided to create a geom gate disk on the same system where the SSD is attached. This way the IO is not going over the network. However, in this use case I noticed the IOPS get cut down to 2/3 compared to IOPS achieved when writing to the SSD directly. So, I have a SSD and its geom gate network disk created on the same node and the same IOPS test using the dd command gives 2/3 IOPS performance for the geom gate disk compared to running the IOPS test directly on the SSD. This points to some performance issues with the geom gate itself. Is anyone aware of any such performance issues when using geom gate network disks? If so, what is the reason for such IO performance drop and are there any solutions or tuning parameters to rectify the performance drop? Any information regarding the same will be highly appreciated. -- Sourish Mazumder Software Architect CloudByte Inc. From owner-freebsd-geom@FreeBSD.ORG Fri Oct 17 15:01:25 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63A1B864 for ; Fri, 17 Oct 2014 15:01:25 +0000 (UTC) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtpout004.mac.com [17.172.81.3]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 392DF1B9 for ; Fri, 17 Oct 2014 15:01:24 +0000 (UTC) Received: from [192.168.1.4] (c-24-6-178-251.hsd1.ca.comcast.net [24.6.178.251]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NDL00856DLZX310@st11p00mm-asmtp004.mac.com> for freebsd-geom@freebsd.org; Fri, 17 Oct 2014 14:01:16 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-17_04:2014-10-17,2014-10-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410170125 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Fri, 17 Oct 2014 07:01:11 -0700 Subject: Re: Minor addition to confdot (w/ patch) From: Ravi Pokala To: freebsd-geom@freebsd.org Message-id: Thread-topic: Minor addition to confdot (w/ patch) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:01:25 -0000 > >Date: Fri, 17 Oct 2014 10:57:57 +0400 >From: "Andrey V. Elsukov" >To: "Pokala, Ravi" , "freebsd-geom@freebsd.org" > >Subject: Re: Minor addition to confdot (w/ patch) >Message-ID: <5440BDF5.7090101@FreeBSD.org> >Content-Type: text/plain; charset=windows-1252 > >On 17.10.2014 05:10, Pokala, Ravi wrote: >> Hi folks, >> >> The GEOM stack diagrams created by 'sysctl -b kern.geom.confdot' (and >>then >> run through `dot') are really quite handy. One thing that we really >>needed >> at Panasas, but which is not included in the diagram, is the providers' >> sectorsize and stripesize. This small change adds that info; if there >>are >> no objections, could someone submit it on my behalf? > >Hi, > >committed with r273208. Thanks Andrey! -Ravi >-- >WBR, Andrey V. Elsukov From owner-freebsd-geom@FreeBSD.ORG Fri Oct 17 16:58:53 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E27E3B5F for ; Fri, 17 Oct 2014 16:58:52 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B1A47F0 for ; Fri, 17 Oct 2014 16:58:52 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9HGwnxw077714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 09:58:50 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9HGwngN077713; Fri, 17 Oct 2014 09:58:49 -0700 (PDT) (envelope-from jmg) Date: Fri, 17 Oct 2014 09:58:49 -0700 From: John-Mark Gurney To: Sourish Mazumder Subject: Re: geom gate network Message-ID: <20141017165849.GX1852@funkthat.com> Mail-Followup-To: Sourish Mazumder , freebsd-geom@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 17 Oct 2014 09:58:50 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:58:53 -0000 Sourish Mazumder wrote this message on Fri, Oct 17, 2014 at 17:34 +0530: > I am planning to use geom gate network for accessing remote disks. I set up > geom gate as per the freebsd handbook. I am using freebsd 9.2. > I am noticing heavy performance impact for disk IO when using geom gate. I > am using the dd command to directly write to the SSD for testing > performance. The IOPS gets cut down to 1/3 when accessing the SSD remotely > over a geom gate network, compared to the IOPS achieved when writing to the > SSD directly on the system where the SSD is attached. > I thought that there might be some problems with the network, so decided to > create a geom gate disk on the same system where the SSD is attached. This > way the IO is not going over the network. However, in this use case I > noticed the IOPS get cut down to 2/3 compared to IOPS achieved when writing > to the SSD directly. > > So, I have a SSD and its geom gate network disk created on the same node > and the same IOPS test using the dd command gives 2/3 IOPS performance for > the geom gate disk compared to running the IOPS test directly on the SSD. > > This points to some performance issues with the geom gate itself. Not necessarily... Yes, it's slower, but at the same time, you now have to run lots of network and TCP code in addition to the IO for each and every IO... > Is anyone aware of any such performance issues when using geom gate network > disks? If so, what is the reason for such IO performance drop and are there > any solutions or tuning parameters to rectify the performance drop? > > Any information regarding the same will be highly appreciated. I did some work at this a while back... and if you're interested in improving performance and willing to do some testing... I can send you some patches.. There are a couple issues that I know about.. First, ggate specificly sets the buffer sizes, which disables the autosizing of TCP's window.. This means that if you have a high latency, high bandwidth link, you'll be limited to 128k / rtt of bandwidth. Second is that ggate isn't issueing multiple IOs at a time. This means that any NCQ or tagging isn't able to be used, where as when running natively they can be used... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Sat Oct 18 13:30:24 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25054E7F for ; Sat, 18 Oct 2014 13:30:24 +0000 (UTC) Received: from cargobay.net (cargobay.net [174.136.100.98]) by mx1.freebsd.org (Postfix) with ESMTP id 01C66E31 for ; Sat, 18 Oct 2014 13:30:23 +0000 (UTC) Received: from [192.168.112.8] (unknown [65.35.132.177]) by cargobay.net (Postfix) with ESMTPSA id 3D71527C; Fri, 17 Oct 2014 13:23:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: geom gate network From: "Chad J. Milios" X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Fri, 17 Oct 2014 09:22:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55184ECF-DCC3-4ACE-A798-D1E7F5BDDB58@ccsys.com> References: To: Sourish Mazumder Cc: "freebsd-geom@freebsd.org" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 13:30:24 -0000 > On Oct 17, 2014, at 8:04 AM, Sourish Mazumder wrot= e: >=20 > Hi, >=20 > I am planning to use geom gate network for accessing remote disks. I set u= p > geom gate as per the freebsd handbook. I am using freebsd 9.2. > I am noticing heavy performance impact for disk IO when using geom gate. I= > am using the dd command to directly write to the SSD for testing > performance. The IOPS gets cut down to 1/3 when accessing the SSD remotely= > over a geom gate network, compared to the IOPS achieved when writing to th= e > SSD directly on the system where the SSD is attached. > I thought that there might be some problems with the network, so decided t= o > create a geom gate disk on the same system where the SSD is attached. This= > way the IO is not going over the network. However, in this use case I > noticed the IOPS get cut down to 2/3 compared to IOPS achieved when writin= g > to the SSD directly. >=20 > So, I have a SSD and its geom gate network disk created on the same node > and the same IOPS test using the dd command gives 2/3 IOPS performance for= > the geom gate disk compared to running the IOPS test directly on the SSD. >=20 > This points to some performance issues with the geom gate itself. >=20 >=20 > Is anyone aware of any such performance issues when using geom gate networ= k > disks? If so, what is the reason for such IO performance drop and are ther= e > any solutions or tuning parameters to rectify the performance drop? >=20 > Any information regarding the same will be highly appreciated. >=20 > --=20 > Sourish Mazumder > Software Architect > CloudByte Inc. What hardware are we talking about, specifically? Systems, NICs, SSDs. To me= , the ratios you are describing don't seem that unreasonable. You surely rea= lize you're asking for a lot out of a software solution and comparing it to d= irectly attached hardware. SSDs generally handle a LOT of IOPS. SANs in gene= ral are not going to get you anywhere close to direct attached performance w= ithout everything in the chain being REALLY expensive. I see IOPS are your m= ain concern but could you also post throughput numbers, to compare and contr= ast? We need real numbers and real hardware makes/models to get an idea. Wha= t block sizes have you tried with dd and what is your baseline direct attach= ed performance? Have you tried iSCSI, either the new in-kernel stack or the o= ld user land tools? Have you compared this to any linux setups on the same s= ystem? When you said "create a geom gate disk on the same system" do you mea= n using ggatel or still using ggated/ggatec? It'd be useful to have both tho= se situations benchmarked for more insight regarding the factors at play. Is there room for optimization and tweaking within the system as you describ= ed it? Probably. To me though my first instinct was that the problem is more= likely in your expectations of ggate and TCP. I think iSCSI will get you cl= oser to what you expect, how much closer I'm not sure without trying it out.= And 9.2? That's deprecated, man. Can you use 9.3 or 10.x? :) I realize you no doubt have real work to perform and don't have all day to b= enchmark umpteen variations and permutations of what at first glance seems l= ike it should be a simple system. Sorry I couldn't be of more help. Maybe so= meone else's intuition will bring you a better answer with less headache. I o= nly hope to have shed some light on the many factors at play here.=