Re: RFA: patch to remote.c for larger download packet support (part 1)

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Frank" == Frank Ch Eigler <fche@cygnus.com> writes:
Frank> The following patches are one step in loosening the remote
Frank> protocols' packet size limiting code, so that downloads to
Frank> versatile targets across reliable channels may be quicker.
Frank> This is done by making remote_write_bytes() and putpkt() be
Frank> able to accept packets up to "remotewritesize" bytes in length.

How much faster do you expect this to be?  Worst case, PBUFSIZ is 400
bytes.  With protocol overhead of 4 bytes for framing plus around 16
for the command, we're still getting ~95% efficiency.  Is it just the
packet latency caused by a stop-and-wait protocol?  Assuming that the
delay is in the transport layer itself, that's only ~0.006 seconds per
packet on a 9600bps serial line.  Using huge packets seems to be going
down the path of diminishing returns.

As for the patch, if a user sets remotewritesize to a value larger
than the maximum packet size supported by the target's debug agent,
putpkt_binary() will fail and getpkt() will time out.  But since
neither error is caught, the user has no reason to believe that the
write did not succeed.  This would occur if the value of PBUFSIZ in
GDB and the debug agent differed, but at least that's not a knob
available to the user.

        --jtc

-- 
J.T. Conklin
RedBack Networks