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

Sandra Loosemore
2015-08-18T16:52:48Z

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