[pskmail] Ideas for a more efficient protocol

From: John Douyere <vk2eta@xxxxxxxxx>
To: pskmail@xxxxxxxxxxxxx
Date: Sat, 25 Dec 2010 13:08:36 +1100
Hi All,

I have been looking at the typical Pskmail exchanges while out "in the bush"
and the way I use the system, I have far more download that uploads in
volume as I check web pages for weather forecast and fire danger alerts and
fire bans here in Australia, plus the email check and small email
transmissions typically to say that "everything is fine" or brag about how
nice it is out there, but all in all I would say 80% download and 20% upload
in volume.

I have noticed that in many cases the most time wasting event is when the
receiving end does not get it's status block heard from the sending end and
in my case that means mostly the server does not hear the status block of
the client.

This is also consistent with the client using a compromise antenna in most
cases but having less QRM.

The logic to improve this situation is in my view to either 1) Reduce the
number of required status exchanges or 2) make them more reliable without
slowing the exchange of data down.

I also noticed that if only status blocks are exchanged, the algorithm
generally settles at a higher speed that when data blocks are sent. This is
logical since data blocks are significantly longer that status blocks and
therefore exhibit in average a lower success rate, resulting in an automatic
speed downgrade.

It is also worth noting that we have adaptative timeouts in the server where
the timeout is kept shorter if no start of block (<SOH> character) is heard
or not as we assume that no SOH means to transmission at all or so garbled
that it is useless.

So here are a few ideas we could implement to go in these directions:

1.  Increase the number of blocks that are sent with each transmission. I
believe this could be either a simple fixed increase or a more adaptative
one.

Compatibility with previous version could be a serious consideration here
too. So the minimal approach could be: double say the number of  data block
to 16 in a transmission, but only if zero or say less than 7 blocks are
missing.

This allows to maintain a maximum list of missing blocks of 8 without
creating a runaway system where the list of missing blocks grow over 8 and
we start to reach the end of the circular buffer.

The adapatitive timeouts logic explained above means that we don't waste
more time if there is no data transmission.

Or we just extend the number of missing blocks in the status transfer but
that would not be compatible with older versions.

2. If there are no data blocks to be sent ( or none being received if we
look at the client from the server side), we could downgrade the TX mode
(respectively RX mode) mode by one compared to what the algorithm suggest so
that status blocks are received more reliably without affecting the speed of
data transfers.

The advantage of the approach above is that this provides advantages to
either direction of heavy data transfer.

Comments and suggestions more than welcomed of course.

All the best,

73's, John (VK2ETA)
[pskmail] Ideas for a more efficient protocol

Other related posts:
