From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23538 invoked by alias); 10 Jul 2008 19:09:44 -0000 Received: (qmail 23523 invoked by uid 22791); 10 Jul 2008 19:09:43 -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 19:09:22 +0000 X-IronPort-AV: E=Sophos;i="4.30,338,1212382800"; d="scan'208";a="352701106" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 10 Jul 2008 14:09:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18550.24158.544203.163257@gargle.gargle.HOWL> Date: Thu, 10 Jul 2008 19:09: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> 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/msg00157.txt.bz2 >>>>> "Sandra" == Sandra Loosemore writes: Sandra> Paul Koning wrote: >> I'm not sure this is a good idea. >> >> For one thing, if you want to work on performance, there are much >> more dramatic changes to the protocol that could be done that >> would help much more. I can't believe that the cost of acks is >> significant compared to all the other bottlenecks. 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? paul