[Coco] os9/drivewire driver: success!

[Boisy G. Pitre]

Here's my take:  the round trip time of sending a check packet, and then IF there is data, sending another packet to retrieve the data costs more in terms of performance than just asking at every interrupt interval for data.  You're going to send a request anyway and get back a response, just two bytes instead of one, and it's all done within one transaction.

Because at the speeds at which we are talking about (115200bps) there is not enough time to look at an incoming byte as a counter for the number of incoming bytes that follow... unless the server throttles  the rate at which it sends data to the CoCo.  So known-sized responses to the CoCo are the key to DriveWire's success.  You could build in a fixed size message that always returns the same number of bytes, but with a counter that indicates the number of VALID bytes:

1. Send OP_SERREAD to the server
2. Server sends an 8 byte packet to the CoCo: 1st byte is valid number of bytes (0-7) and the remaining 7 bytes are valid up to the number reported in the first byte.

The ISR could then shuffle the bytes into the incoming buffer, up to a max of 7.

You could enforce a larger or smaller packet size.

Boisy

On Nov 10, 2009, at 2:10 PM, Aaron Wolfe wrote:

> On Tue, Nov 10, 2009 at 2:54 PM, William Astle <lost at l-w.ca> wrote:
>> Aaron Wolfe wrote:
>>> One question about combining SERREAD and SERCHECK:
>>> 
>>> My original idea was that SERCHECK would return the number of bytes in
>>> the server's buffer, and then SERREAD would ask for a flush of X
>>> bytes, typically the number returned by SERCHECK.  The server would
>>> then write out the # of bytes requested.  This was (in my head) a way
>>> to improve performance for things like rzsz over the virtual serial
>>> port.
>>> 
>>> By combining them, I will be cutting the potential throughput in half
>>> since there are two bytes for each data byte, and also taking a
>>> penalty of having to ask for each byte individually (which is
>>> admittedly how my current driver works, but it was supposed to be
>>> better :)
>>> 
>>> Are there outside factors that mitigate the losses in combining the
>>> calls?  If there is some other reason it will be slow anyway, then I
>>> agree it would make it simpler to combine them.
>>> -Aaron
>> 
>> Why not make the request include a maximum number of bytes to return.
>> Then have the response include the number of bytes returned and those bytes.
>> 
>> This would require tinkering the drivewire scheme so it could handle
>> variable length return packets in some manner but it should provide the
>> maximum theoretical efficiency.
>> 
> 
> This would be nice, but as it stands the dw calls require you to know
> how many bytes are coming/going when you call them.. not sure if I'm
> ready to touch anything in dw itself :)  maybe at some point though..
> i agree this would be ideal.
> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco