From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: pause after sending S-records to ROM68K monitor Date: Fri, 10 Aug 2001 17:13:00 -0000 Message-id: <3B74789B.3080100@cygnus.com> References: <20010809005554.1CDB75E9D8@zwingli.cygnus.com> <3B72CAC8.1060504@cygnus.com> X-SW-Source: 2001-08/msg00120.html > Andrew Cagney writes: > >> Jim, while an inovative interpretation of baud, I don't know that the >> patch is either correct or robust. > > > Well, okay. Can you suggest a correct and robust implementation for > downloading S-records to a monitor which provides no hardware > handshaking on the serial line, and no handshaking in the protocol > (say, by transmitting a `+' after each record)? > > >> It sounds like you've got a latency problem while the patch you have is >> playing with the bandwidth knob. > > > In the absence of any per-record feedback, I don't see any > alternative. I think you've got it half right The time taken is something like: size-of-pipe * amount-of-data + round-trip (I don't have my AST networks book handy to don't trust this). round-trip is loosely defined by remote_timeout. As you note the baud loosely defines the transfer-rate. This is if we assume 100% efficiency :-) In your case, it is probably more exactly defined as: ABOVE - (current-time - start-time) remember, if you are talking down a real serial port then the buffering will be zero and you only want to wait for round-trip time. Using this, i'd expect something like if (remote_throughput (??better-name??) >= 0) transfer_time = remote_throughput * sizeoftransfer; else transfer_time = something made up from the baud-rate timeout = transfer_time - (current_time - start_time) + remote_timeout Andrew