From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25154 invoked by alias); 10 Jul 2008 20:13:44 -0000 Received: (qmail 25136 invoked by uid 22791); 10 Jul 2008 20:13:44 -0000 X-Spam-Check-By: sourceware.org Received: from aussmtpmrkpc120.us.dell.com (HELO aussmtpmrkpc120.us.dell.com) (143.166.82.159) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 20:13:24 +0000 X-IronPort-AV: E=Sophos;i="4.30,338,1212382800"; d="scan'208";a="352704042" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 10 Jul 2008 15:13:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18550.28000.759268.379468@gargle.gargle.HOWL> Date: Thu, 10 Jul 2008 20:13:00 -0000 From: Paul Koning To: sandra@codesourcery.com Cc: gdb@sourceware.org, gdb-patches@sourceware.org, pedro@codesourcery.com Subject: Re: [remote protocol] support for disabling packet acknowledgement References: <48765B8A.6080805@codesourcery.com> <18550.24158.544203.163257@gargle.gargle.HOWL> <48766999.6070001@codesourcery.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00163.txt.bz2 >>>>> "Sandra" == Sandra Loosemore writes: Sandra> Paul Koning wrote: >>>>>>> "Sandra" == Sandra Loosemore >>>>>>> writes: >> Sandra> You'll note the documentation says turning off acks may be Sandra> desirable to reduce communication overhead *or* "for other Sandra> reasons". In fact, it is the "other reasons" that motivated Sandra> this patch. We are working on designing the extensions to Sandra> the remote protocol to support nonstop mode, and we realized Sandra> that we simply cannot do it in combination with using +/- Sandra> acks on the asynchronous responses. If we need a reliable Sandra> transport layer to support nonstop mode, we might as well Sandra> turn the acks off completely instead of dealing with the Sandra> extra complexity of trying to design the nonstop protocol Sandra> around them. >> Ok, so does that mean the nonstop mode features won't work unless >> the remote protocol is layered on TCP? Given that a lot of the >> time the remote link is simply a UART serial link, is there an >> issue here? Sandra> Probably so, but the +/- acks are not the way to solve it. Sandra> :-( Sandra> Our internal discussion on that issue was getting more and Sandra> more complicated, to the point where I could not even follow Sandra> what the exact problem was. ... Sandra> There's current practice (the existing Apple implementation) Sandra> to support disabling +/- acks and it seems useful as a Sandra> performance hack for TCP connections independently of the Sandra> nonstop extensions, so why not formalize it? Let me see if I understand this right. 1. +/- ACKs are fine for the clasis (without non-stop) remote protocol. 2. ACKs are needed if the underlying transport isn't a reliable transport (for example a raw UART). They aren't needed if the underlying transport is TCP or equivalent. 3. +/- ACKs are not good enough for non-stop mode. (It's not clear to me why -- is it because there may need to be more than one packet in flight? An explanation of what exactly is wrong would be helpful to understand how to fix the issue.) and finally 4. The proposal is to have a way to turn off +/-ACKs and this will be used for non-stop mode. The implication is that the non-stop mode design abandons support for non-TCP transports. This doesn't seem like a good thing. I would argue you need to identify why +/- ACKs aren't good enough, and propose a replacement that is good enough. With that replacement you have a way to add the non-stop mode. If the overhead of that replacement is significant in some plausible use case, you could then add a way to turn it off for the case where TCP is used end to end. By the way, note that "target remote host:port" does NOT mean that you have TCP end to end. You may have TCP to a terminal server and raw UART the rest of the way, so you still need ACKs (of one kind or another). paul