Antoni Burguera wrote:
>Alex Wulms wrote:
>>Not with Maarten's algorithm. He does not sent a new bit before the
>>previous
>>one has been acknowledged by the receiving side. That is one of the big
>>advantages of using a proper asynchronous algorithm.
I agree, but it means you double your data trafic (1bit, 1ack, 1bit, 1ack, etc)
Which is VERY slow...
>This algorithm, called Idle RQ, has a big problem: performance. Using this
>method the transfer rate is reduced a lot.
>Normally it is used an algorithm like this. It has a name... but I don't
>remember which.
[snip]
The protocol you described is called Continuous RQ with Selective Repeat
The only problem is we're still one step down the OSI ladder and not
really up to the protocol part, but still in the data transmission part.
We can't even send 'blocks' of data yet. As of yet every bit needs an
ACK from the receiver.
To me, this is way too slow, and we need to at least send a byte (block)
at a time, before needing an ACK from the receiving side. But I cannot
come up with a good sollution.
If we want to use Turbo R's in 28.6mHz mode in our network, we can neither
use a good synchronous data transmission (either with external clock or
with built in clock) nor an asychronous one, except the one Maarten is
using at this moment. (as far as I know)
So we must either eliminate the TR's in turbo mode, or start with a propper
handshake...
I say we first need to send a byte in either syn or asyn mode before starting
to talk about transfer protocols, like Idle RQ, Continuous RQ, Sliding Window,
Go-Back-N or anything alike.
Does anybody have any good suggestions as to send a block (byte) of data?!
(either syn or asyn)
Greetz,
Patsie
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
