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

[Todd Whitesel <toddpw at wrs dot com>]

> This would argue that we look at replacing the remote protocol that we
> look at windowed framing schemes so we can have multiple commands out-
> standing.

This is not the only approach; it is definitely worth pursuing however.

Even at 38400 baud, you will find that utilization of the serial line is
abysmal with 250 byte packets.

Why? Because of the slosh in the host O/S scheduler. When you send a serial
packet down and block waiting for the response, the O/S doesn't go out of
its way to wake you up the microsecond the return data comes in. You usually
end up waiting for another process to give up _its_ timeslice and then you
get switched back in.

Try this experiment: enhance a target stub to fire up a timer interrupt and
send itself interrupts at 50 or 60 hz. Add LED code to your serial port
routines and the timer interrupt: turn on LEDs when handling serial port
events, and turn off the LEDs when a timer interrupt comes in. You could
use a serial port tester to get the same information, but the direct LED
method is easier to observe (and it can be expanded to show other events).

Use the target for a bit and gag at how poorly the serial line is being
utilized during complex debugger operations.

-- 
Todd Whitesel
toddpw @ wrs.com