[drats_users] File and Form Transfers over Repeater/Reflector

[Dan Smith]

> 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. 

That's correct.

> 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.

Ignoring the obvious case of taking this to an extreme, this is correct.

> 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?

Yes, the count is the number of blocks to send per round, and the size 
is how big each of those are.  So, a 1024-byte block with a count of 
more than about 2 is probably too much.  It will result in the best 
transfer speed, but may melt your radio :)

> 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. 

Well, there's something else I didn't tell you about pipelining because 
this has nothing to do with it.  I took the opportunity while adding a 
new transport type to change the semantics of the compression.  When you 
use pipelining, it reads the entire file into memory and compresses it 
as a whole instead of per-packet.  This has the potential to yield a 
much better compression ratio than just doing it per-packet.  It's 
negligible for small files in most cases, but it will never be worse. 
So, I don't really see any reason to turn off pipelining unless you're 
trying to send to someone who has an older version and thus no support 
for that.

> Example
> Pipeline off
> Block size 1024kb
> File Transfer time 30 secs
> 
> Pipeline On
> Block size 256
> Pipeline Block 4
> File Transfer time  25 secs

Correct, this is functionally equivalent, although the pipelined case 
will have 3 extra block headers in it, so if there are no retransmits, 
you might see slightly worse performance (very slight, and probably less 
than the gain you'd see from the improved compression as mentioned above).

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

Correct.

> 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?

It only comes into play, meaning it's only useful when someone is using 
a handheld, yes.  Turning it off when you know nobody with a handheld 
(with power save on) will improve performance.

However, as I mentioned, it may be useful for "priming" the reflectors, 
but that needs to be tested.

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