Re: [PATCH 0/2] Better handling of slow remote transfers

[Sandra Loosemore <sandra at codesourcery dot com>]

On 08/18/2015 03:58 AM, Gary Benson wrote:
> For some reason, the Altera 3c120 board you are using is very much
> slower to transfer files over RSP than it is over NFS.
>
> For some reason, neither of the two QUIT patches I mailed work on your
> setup with this Altera 3c120 board you are using even though they work
> just fine on this x86_64 machine I am using.

I would be happy to try to help debug what is going wrong here, but I'm 
not a GDB expert by any means and I'm totally unfamiliar with this part 
of the code and don't know where to start.  If somebody has a theory on 
this, is there someplace I could put in printfs to trace what is 
happening?  From the previous discussion, it seemed like the flow 
through the different layers of abstraction to what the RSP was actually 
doing was very obscure, in terms of where the chunking is happening, etc.

> Your PandaBoard takes 8 seconds.  That doesn't seem so bad to me.
> If this Altera board is the only one with the massive slowdown then
> I don't think we should delay 7.10 any further on this issue--and I
> certainly don't think we should lose the functionality that the
> default sysroot of "target:" brings.

FWIW, I have just tried on a random sampling of our MIPS target boards 
as well, with the same test program and same scenario of continuing to a 
breakpoint on main.  The timings were 1:40 (SEAD-3 LX110 board, M14Kc 
microMips), 1:38 (MALTA 74Kc MIPS16), and 1:20 (MALTA 5Kef MIPS64).  I 
could try some PowerPC boards as well if we need more datapoints.

In any case, I think we should be cautious about declaring that 
functionality that seems to work on x86_64 native should work 
everywhere, and if it doesn't it's the fault of the target or user 
instead of buggy code or poor design.  IMO this is especially true for 
remote debugging, where I think debugging an embedded target is a more 
common scenario than a native one.

-Sandra