[drats_users] File and Form Transfers over Repeater/Reflector

[Dave Cooley]

So if I am reading this correctly:

In an ideal world where no errors or corrupt data is received, pipelining
would not be necessary. But given the many variables effecting the data and
RF ( I guess we still have to consider that part too) corrupt or missing
data is inevitable.  Furthermore, as the quality of the transport decreases
and more errors become present (requiring more re-transmits requests) it
would make sense to decrease the size of the blocks "Outgoing Block Size"
and increasing the "Piplelined Blocks" Setting. While this may add more
overhead and increase transfer time for a given amount of data, it should
decrease the time needed for resends and ultimately reduce overall transfer
time.

This brings me a to another question:
If the outgoing block size set to 1024 kb and the pipleined blocks is set to
5, does this mean that each time that D-RATS send data to the radio that it
is trying to send 5120kb of data at a time? (5x1024) Given the results many
have posted for file transfer rates, is this a bit much? 

Just thinking out loud but to test the whether Pipelining is needed, one
should try a file transfer without it and then, with pipeline enabled,
reduce the block size by the number of blocks pipelined and see if it is
quicker. 

Example
Pipeline off
Block size 1024kb
File Transfer time 30 secs

Pipeline On
Block size 256
Pipeline Block 4
File Transfer time  25 secs

This would indicate that a NAK was received and Pipelining is beneficial. 


As far as the warm up length and timeout setting are concerned, they only
come into play with an HT using power safe mode, correct?

Thanks
Dave Cooley
WA4DOC

-----Original Message-----
From: Dan Smith [mailto:dsmith at danplanet.com] 
Sent: Wednesday, October 01, 2008 11:49 AM
To: Discussion of D-RATS
Subject: Re: [drats_users] File and Form Transfers over Repeater/Reflector


> After some trial and error I have found that I get a much better
> success rate if I set the "force delay between transmissions" to 1or 2 
> seconds for repeaters and 3-4 for reflectors. This ultimately will 
> extend the transfer time but helps insure a better success rate by 
> allowing for any repeater bounce or unlinking from reflectors. There are 
> probably different amounts of latency for different repeaters and 
> reflectors so you may have to play with this a bit.

Great, thanks for the report!  Maybe we need a note on the wiki about 
some of this.  A "tips" or "troubleshooting" page perhaps.

> Also could someone shed more light on the Pipeline Blocks,

Originally, the transport algorithm was:

  1. Read a block from the file being sent
  2. Send it to the remote side
  3. Wait for ACK
  4. If ACK goto 1
  5. If NAK goto 2

This was safe, but it meant that you had to use pretty good size blocks 
to get a reasonable transfer rate, and if you had a single bit error, 
you had to retransmit the whole thing.  I added pipelining which reads 
multiple blocks in step 1 and sends multiple blocks in step 2.  During 
each "round" the remote can ACK/NAK any of the blocks that were sent. 
So, if we send 5 small blocks and one doesn't make it, the next time 
around we resend the one missed block, as well as four more new blocks.

The smaller blocks mean less needs to be resent while keeping the 
transmitter busy longer, and thus more throughput.

> Warm Up Length and Warm Up Timeout settings?

Let me first tell you the initial reasoning for adding this.  The 
handhelds, when power save mode is enabled, start to go to sleep for 
longer and longer, depending on how long it's been since the last 
received signal.  Thus if it's been 10 seconds or so, they are pretty 
asleep and will inevitably miss the beginning of any new signal that is 
sent.  The "warm up" sends a fake block before any real block to attempt 
to "wake up" any handhelds that might be listening, before the real 
block goes out.  To avoid transmitting fake blocks all the time, I only 
send that fake block if it's been a while since we last transmitted.

The "length" is how big the fake block is, and the "timeout" is the time 
period since the last transmission before we send a warmup.  So, if 
timeout is set to 10 seconds, then if we send two messages 3 seconds 
apart, no warmup will be sent.  If we set it to 1, then it would be sent.

The best values for these settings are unknown to me, and I'm more than 
willing to take input on what the defaults should be.  I added knobs for 
these because I figured they may help "prime" the reflector before 
sending data as well.

Do those explanations make sense?  Sometimes I'd kill for a whiteboard... :)

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS