From: Sandra Loosemore <sandra@codesourcery.com>
To: Paul Koning <Paul_Koning@dell.com>
Cc: gdb@sourceware.org, gdb-patches@sourceware.org,
Pedro Alves <pedro@codesourcery.com>
Subject: Re: [remote protocol] support for disabling packet acknowledgement
Date: Thu, 10 Jul 2008 18:59:00 -0000 [thread overview]
Message-ID: <48765B8A.6080805@codesourcery.com> (raw)
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.
You'll note the documentation says turning off acks may be desirable to reduce
communication overhead *or* "for other reasons". In fact, it is the "other
reasons" that motivated this patch. We are working on designing the extensions
to the remote protocol to support nonstop mode, and we realized that we simply
cannot do it in combination with using +/- acks on the asynchronous responses.
If we need a reliable transport layer to support nonstop mode, we might as well
turn the acks off completely instead of dealing with the extra complexity of
trying to design the nonstop protocol around them.
> Also, TCP is reliable delivery at the transport layer. It doesn't do
> reliable delivery at the application layer -- that's what the gdb
> remote protocol ACKs do. The fact that TCP delivered a packet to the
> stub doesn't mean the stub acted on it.
The +/- acks don't mean the stub acted on a packet, either; only that the stub
received it and that its checksum passed. The packet responses are what tell
GDB that the stub has acted (or refused to act, as the case may be).
-Sandra
next reply other threads:[~2008-07-10 18:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 18:59 Sandra Loosemore [this message]
2008-07-10 19:09 ` Paul Koning
2008-07-10 19:59 ` Sandra Loosemore
2008-07-10 20:13 ` Paul Koning
2008-07-10 22:33 ` Daniel Jacobowitz
2008-07-11 0:22 ` Sandra Loosemore
2008-07-11 0:43 ` Daniel Jacobowitz
2008-07-11 13:43 ` Paul Koning
2008-07-11 14:35 ` Daniel Jacobowitz
[not found] ` <20080710223312.GA19058__14539.8706700236$1215729298$gmane$org@caradoc.them.org>
2008-07-11 3:05 ` Frank Ch. Eigler
2008-07-11 3:25 ` Daniel Jacobowitz
2008-07-11 15:11 ` Pedro Alves
2008-07-11 15:24 ` Daniel Jacobowitz
2008-07-11 15:54 ` Paul Koning
2008-07-11 17:59 ` Pedro Alves
2008-07-11 18:54 ` Paul Koning
2008-07-11 19:10 ` Pedro Alves
2008-07-25 13:41 ` Eli Zaretskii
2008-07-25 14:14 ` Sandra Loosemore
2008-07-26 5:54 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2008-07-10 17:23 Pedro Alves
2008-07-10 18:44 ` Paul Koning
2008-07-10 19:08 ` Daniel Jacobowitz
2008-07-25 13:39 ` Eli Zaretskii
2008-08-11 19:40 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48765B8A.6080805@codesourcery.com \
--to=sandra@codesourcery.com \
--cc=Paul_Koning@dell.com \
--cc=gdb-patches@sourceware.org \
--cc=gdb@sourceware.org \
--cc=pedro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox