CQ-Contest
[Top] [All Lists]

Re: [CQ-Contest] [sysops] RBN Announcement on FT8 Spotting

To: Michael Adams <mda@n1en.org>, "sysops@dxcluster.info" <sysops@dxcluster.info>, "cq-contest@contesting.com" <cq-contest@contesting.com>
Subject: Re: [CQ-Contest] [sysops] RBN Announcement on FT8 Spotting
From: Timothy Coker via CQ-Contest <cq-contest@contesting.com>
Reply-to: Timothy Coker <n6win@yahoo.com>
Date: Tue, 12 Jun 2018 19:10:18 +0000 (UTC)
List-post: <mailto:cq-contest@contesting.com>
I think you bring up some valid points. My fear is that during contest periods 
the RBN is overloaded.
I’m not a RTTY guy, but I did spend the software license fee to monitor and 
post RTTY spots to the server. During big CW contest weekends I turn off my 
RTTY Skimmer server so as to keep my computer from being delayed in processing 
all of the CW spots.
I’d be up for posting FT8 spots to help those ops and the general collection of 
propagation also.
I’m curious as to the load of all the new FT8 spots that is being caused to the 
RBN?
As I’m not an FT8 guy I filtered out all incoming FT8 spots from VE7CC’s client 
software which then keeps my DX alerts and contest software load down to a 
minimum, so I’m not concerned about my client side loads.
What have other’s been experiencing?
73,
Tim / N6WIN.


Sent from Yahoo Mail for iPhone


On Tuesday, June 12, 2018, 09:47, Michael Adams <mda@n1en.org> wrote:

A couple of thoughts on FT8 in the RBN:

I view the RBN as a multi-purpose tool.  For me, it's critical in contesting (I 
like assisted S&P; it might not be as magical as spinning the dial, but rate is 
fun all on its own!), it's a valuable tool in DX-award chasing, and it's useful 
in monitoring propagation patterns...something I'm particularly interested in 
before/during big DXpeditions and before contests.

With a couple of DXpeditions now trying out FT8, and given the volume of 
activity on the mode...I think it's OK in principle to keep FT8 in the RBN mix.

However, the RBN won't be a usable tool if it crashes under the added burden of 
a bajillion spots.

Breaking out the FT8 spots into a separate feed makes a certain amount of 
sense, but perhaps some additional throttling might be appropriate, depending 
on how loads develop.  A few ideas:


  *  Does the aggregator attempt to limit itself to only those stations whose 
exchanges suggest they might be running?  Propagation data from non-running 
stations is interesting, but perhaps that data is expendable if load is an 
issue.


  *  Perhaps there might be some value in limiting the number of stations that 
can relay FT8 spots, or in throttling the rate at which they can relay those 
spots?  If throttling, could there be some logic to prioritize the "most 
interesting" spots?


  *  Refusing to accept FT8 spots on "big contest" weekends would make 
sense...but I suspect that encroachment of contest modes into the FT8 watering 
holes will take care of at least part of that problem naturally.

--
Michael Adams | mda@n1en.org
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest



_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
<Prev in Thread] Current Thread [Next in Thread>