confirmed issue with decodes


Rob Robinett
 

Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled

Thus your -2 machine is spending half the cycles per bit on decoding, and it is only going to depth 2 instead of depth 4

WSJT-x runs 'wsprd -C 500 -o 4' , so those are the default values used by WD which have been overridden by your config file linwa:

On TP:     WSPRD_CMD_FLAGS="-C 1000 -o 4 -d"
On TP-2   WSPRD_CMD_FLAGS="-C 500 -o 2 -d"

I don't remember making those changes to your config files, but I suspect the changes were mine.

Your screenshot shows that going from -C 500 to 1000  and -o 2 to 4 results in 9 additional spots being detected,  Since both of your machines had at least one receiver detect every one of the 35 signals in that WSPR cycle, and because those receivers are part of a MERGEed logical receiver, only the strongest of the SNR reports was uploaded to wsprnet.org.  That is why the uploaded spots are the same 35 for both.

Your observation shows how your site is perfectly set up to determine the CPU cost versus number of spots benefit of varying the -C and -o values.  

If you would invest some time, you could start by setting both systems to the WSJT-x default values of -C 500 -o 4 to calibrate them against each other.  In my experience there will be a few differences, perhaps due to the difference in wav file recording start/stop times between the two systems.

I would next change the -C value to 250 then to 1000, 2000, ... until that system runs out of CPU time in a WSPR cycle.
I would then return to -C 500 and perform the same test on the -o values, going from 1 to 2 to 3...

A table of the spots for each setting would give us great insight into the costs and benefits of changes of those values

 

On Wed, Jun 22, 2022 at 3:20 PM Thomas Paratore <WA2TP@...> wrote:

HI Rob,

I have now confirmed with 100% certainty that WA2TP Prod has a WD performance issue with decoding.

 

I monitored two consecutive tail ups for  WA2TP-2 and WA2TP.

 

WA2TP recorded 125 total spots and posted 35 unique,

WA2TP-2 recorded 109 total spots and posted 35 unique.

 

Here is where it gets interesting.

 

I was able to identify 4 unique spots that WA2TP recorded and reported  that WA2TP-2 did not; yet they both uploaded the same number of spots - 35.

This should have yielded a net of 4 more unique uploads than WA2TP-2, but as you can see it does not.

 

See screen shots marked up below. Again I noted below that WA2TP has an extra Kiwi: KIWI5.

I placed a dash next to the unique spots captured by WA2TP prod.

 

 

 

 

 

 

Sent from Mail for Windows

 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Rob Robinett
 

Hi Tom,

I can see there are a few difference, the i5 reported N8LWF and the i9 reported EP2C, and I can see the other differences you mention.
Were the i5 and i9 set to the same -C 500 -o 4 when these different spots were reported?

Rob

On Wed, Jun 22, 2022 at 6:23 PM Thomas Paratore <WA2TP@...> wrote:
Hi Rob,

I actually made the change to C 1000 before tonight’s change over at 0000. 

Those spots were before I made that change.

Tom
WA2TP

From: Rob Robinett <rob@...>
Sent: Wednesday, June 22, 2022 9:05:50 PM
To: Thomas Paratore <WA2TP@...>
Cc: Philip Barnard <vk7jj@...>; wsprdaemon@groups.io <wsprdaemon@groups.io>
Subject: Re: confirmed issue with decodes
 
Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled

Thus your -2 machine is spending half the cycles per bit on decoding, and it is only going to depth 2 instead of depth 4

WSJT-x runs 'wsprd -C 500 -o 4' , so those are the default values used by WD which have been overridden by your config file linwa:

On TP:     WSPRD_CMD_FLAGS="-C 1000 -o 4 -d"
On TP-2   WSPRD_CMD_FLAGS="-C 500 -o 2 -d"

I don't remember making those changes to your config files, but I suspect the changes were mine.

Your screenshot shows that going from -C 500 to 1000  and -o 2 to 4 results in 9 additional spots being detected,  Since both of your machines had at least one receiver detect every one of the 35 signals in that WSPR cycle, and because those receivers are part of a MERGEed logical receiver, only the strongest of the SNR reports was uploaded to wsprnet.org.  That is why the uploaded spots are the same 35 for both.

Your observation shows how your site is perfectly set up to determine the CPU cost versus number of spots benefit of varying the -C and -o values.  

If you would invest some time, you could start by setting both systems to the WSJT-x default values of -C 500 -o 4 to calibrate them against each other.  In my experience there will be a few differences, perhaps due to the difference in wav file recording start/stop times between the two systems.

I would next change the -C value to 250 then to 1000, 2000, ... until that system runs out of CPU time in a WSPR cycle.
I would then return to -C 500 and perform the same test on the -o values, going from 1 to 2 to 3...

A table of the spots for each setting would give us great insight into the costs and benefits of changes of those values

 

On Wed, Jun 22, 2022 at 3:20 PM Thomas Paratore <WA2TP@...> wrote:

HI Rob,

I have now confirmed with 100% certainty that WA2TP Prod has a WD performance issue with decoding.

 

I monitored two consecutive tail ups for  WA2TP-2 and WA2TP.

 

WA2TP recorded 125 total spots and posted 35 unique,

WA2TP-2 recorded 109 total spots and posted 35 unique.

 

Here is where it gets interesting.

 

I was able to identify 4 unique spots that WA2TP recorded and reported  that WA2TP-2 did not; yet they both uploaded the same number of spots - 35.

This should have yielded a net of 4 more unique uploads than WA2TP-2, but as you can see it does not.

 

See screen shots marked up below. Again I noted below that WA2TP has an extra Kiwi: KIWI5.

I placed a dash next to the unique spots captured by WA2TP prod.

 

 

 

 

 

 

Sent from Mail for Windows

 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Rob Robinett
 

But the i5 was not decoding bands from KIWI_5, and the differences between the two were on the i9 from signals from KIWI_5.
Until you eliminate all the variables between the two systems, it is hard to draw conclusions.
Even then, I have seen small differences between two WD decoders connected to the same Kiwi which I have attributed to the small timeing differences between wav files.
Except for that wav file timing difference, everything else in the RF to wsprnet processing chain is digital and thus I can't see any other potential source of those differences.


On Wed, Jun 22, 2022 at 7:10 PM Thomas Paratore <WA2TP@...> wrote:
Yes, they were.  I just set the I9 back to 500 a few minutes ago. 

Tom
WA2TP

From: Rob Robinett <rob@...>
Sent: Wednesday, June 22, 2022 10:03:23 PM
To: Thomas Paratore <WA2TP@...>
Cc: Philip Barnard <vk7jj@...>; wsprdaemon@groups.io <wsprdaemon@groups.io>
Subject: Re: confirmed issue with decodes
 
Hi Tom,

I can see there are a few difference, the i5 reported N8LWF and the i9 reported EP2C, and I can see the other differences you mention.
Were the i5 and i9 set to the same -C 500 -o 4 when these different spots were reported?

Rob

On Wed, Jun 22, 2022 at 6:23 PM Thomas Paratore <WA2TP@...> wrote:
Hi Rob,

I actually made the change to C 1000 before tonight’s change over at 0000. 

Those spots were before I made that change.

Tom
WA2TP

From: Rob Robinett <rob@...>
Sent: Wednesday, June 22, 2022 9:05:50 PM
To: Thomas Paratore <WA2TP@...>
Cc: Philip Barnard <vk7jj@...>; wsprdaemon@groups.io <wsprdaemon@groups.io>
Subject: Re: confirmed issue with decodes
 
Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled

Thus your -2 machine is spending half the cycles per bit on decoding, and it is only going to depth 2 instead of depth 4

WSJT-x runs 'wsprd -C 500 -o 4' , so those are the default values used by WD which have been overridden by your config file linwa:

On TP:     WSPRD_CMD_FLAGS="-C 1000 -o 4 -d"
On TP-2   WSPRD_CMD_FLAGS="-C 500 -o 2 -d"

I don't remember making those changes to your config files, but I suspect the changes were mine.

Your screenshot shows that going from -C 500 to 1000  and -o 2 to 4 results in 9 additional spots being detected,  Since both of your machines had at least one receiver detect every one of the 35 signals in that WSPR cycle, and because those receivers are part of a MERGEed logical receiver, only the strongest of the SNR reports was uploaded to wsprnet.org.  That is why the uploaded spots are the same 35 for both.

Your observation shows how your site is perfectly set up to determine the CPU cost versus number of spots benefit of varying the -C and -o values.  

If you would invest some time, you could start by setting both systems to the WSJT-x default values of -C 500 -o 4 to calibrate them against each other.  In my experience there will be a few differences, perhaps due to the difference in wav file recording start/stop times between the two systems.

I would next change the -C value to 250 then to 1000, 2000, ... until that system runs out of CPU time in a WSPR cycle.
I would then return to -C 500 and perform the same test on the -o values, going from 1 to 2 to 3...

A table of the spots for each setting would give us great insight into the costs and benefits of changes of those values

 

On Wed, Jun 22, 2022 at 3:20 PM Thomas Paratore <WA2TP@...> wrote:

HI Rob,

I have now confirmed with 100% certainty that WA2TP Prod has a WD performance issue with decoding.

 

I monitored two consecutive tail ups for  WA2TP-2 and WA2TP.

 

WA2TP recorded 125 total spots and posted 35 unique,

WA2TP-2 recorded 109 total spots and posted 35 unique.

 

Here is where it gets interesting.

 

I was able to identify 4 unique spots that WA2TP recorded and reported  that WA2TP-2 did not; yet they both uploaded the same number of spots - 35.

This should have yielded a net of 4 more unique uploads than WA2TP-2, but as you can see it does not.

 

See screen shots marked up below. Again I noted below that WA2TP has an extra Kiwi: KIWI5.

I placed a dash next to the unique spots captured by WA2TP prod.

 

 

 

 

 

 

Sent from Mail for Windows

 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Gwyn Griffiths
 

As the change in the -o parameter (  -o n (0<=n<=5), decoding depth for OSD) only affects the Ordered Statistics Decoder, which is only invoked in wsprd when the Fano decoder cannot decode the signal, the changes you make for o may affect the rate of false decodes.
The extended set of parameters in the wsprdaemon_spots_s table can help document, in that the actual number of Fano decode_cycles is listed (this is the one affected by your choice of C), as is metric, which is 810 if the OSD has been invoked when decode_type is 1.

regards
Gwyn


KD2OM
 

My i7 is set to wsprd -C 10000 -o 4, is there any advantage to changing it to another value?


Steve KD2OM

On 6/23/22 02:38, Rob Robinett wrote:
But the i5 was not decoding bands from KIWI_5, and the differences between the two were on the i9 from signals from KIWI_5.
Until you eliminate all the variables between the two systems, it is hard to draw conclusions.
Even then, I have seen small differences between two WD decoders connected to the same Kiwi which I have attributed to the small timeing differences between wav files.
Except for that wav file timing difference, everything else in the RF to wsprnet processing chain is digital and thus I can't see any other potential source of those differences.


On Wed, Jun 22, 2022 at 7:10 PM Thomas Paratore <WA2TP@...> wrote:
Yes, they were.  I just set the I9 back to 500 a few minutes ago. 

Tom
WA2TP

From: Rob Robinett <rob@...>
Sent: Wednesday, June 22, 2022 10:03:23 PM
To: Thomas Paratore <WA2TP@...>
Cc: Philip Barnard <vk7jj@...>; wsprdaemon@groups.io <wsprdaemon@groups.io>
Subject: Re: confirmed issue with decodes
 
Hi Tom,

I can see there are a few difference, the i5 reported N8LWF and the i9 reported EP2C, and I can see the other differences you mention.
Were the i5 and i9 set to the same -C 500 -o 4 when these different spots were reported?

Rob

On Wed, Jun 22, 2022 at 6:23 PM Thomas Paratore <WA2TP@...> wrote:
Hi Rob,

I actually made the change to C 1000 before tonight’s change over at 0000. 

Those spots were before I made that change.

Tom
WA2TP

From: Rob Robinett <rob@...>
Sent: Wednesday, June 22, 2022 9:05:50 PM
To: Thomas Paratore <WA2TP@...>
Cc: Philip Barnard <vk7jj@...>; wsprdaemon@groups.io <wsprdaemon@groups.io>
Subject: Re: confirmed issue with decodes
 
Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled

Thus your -2 machine is spending half the cycles per bit on decoding, and it is only going to depth 2 instead of depth 4

WSJT-x runs 'wsprd -C 500 -o 4' , so those are the default values used by WD which have been overridden by your config file linwa:

On TP:     WSPRD_CMD_FLAGS="-C 1000 -o 4 -d"
On TP-2   WSPRD_CMD_FLAGS="-C 500 -o 2 -d"

I don't remember making those changes to your config files, but I suspect the changes were mine.

Your screenshot shows that going from -C 500 to 1000  and -o 2 to 4 results in 9 additional spots being detected,  Since both of your machines had at least one receiver detect every one of the 35 signals in that WSPR cycle, and because those receivers are part of a MERGEed logical receiver, only the strongest of the SNR reports was uploaded to wsprnet.org.  That is why the uploaded spots are the same 35 for both.

Your observation shows how your site is perfectly set up to determine the CPU cost versus number of spots benefit of varying the -C and -o values.  

If you would invest some time, you could start by setting both systems to the WSJT-x default values of -C 500 -o 4 to calibrate them against each other.  In my experience there will be a few differences, perhaps due to the difference in wav file recording start/stop times between the two systems.

I would next change the -C value to 250 then to 1000, 2000, ... until that system runs out of CPU time in a WSPR cycle.
I would then return to -C 500 and perform the same test on the -o values, going from 1 to 2 to 3...

A table of the spots for each setting would give us great insight into the costs and benefits of changes of those values

 

On Wed, Jun 22, 2022 at 3:20 PM Thomas Paratore <WA2TP@...> wrote:

HI Rob,

I have now confirmed with 100% certainty that WA2TP Prod has a WD performance issue with decoding.

 

I monitored two consecutive tail ups for  WA2TP-2 and WA2TP.

 

WA2TP recorded 125 total spots and posted 35 unique,

WA2TP-2 recorded 109 total spots and posted 35 unique.

 

Here is where it gets interesting.

 

I was able to identify 4 unique spots that WA2TP recorded and reported  that WA2TP-2 did not; yet they both uploaded the same number of spots - 35.

This should have yielded a net of 4 more unique uploads than WA2TP-2, but as you can see it does not.

 

See screen shots marked up below. Again I noted below that WA2TP has an extra Kiwi: KIWI5.

I placed a dash next to the unique spots captured by WA2TP prod.

 

 

 

 

 

 

Sent from Mail for Windows

 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Gwyn Griffiths
 

Steve,
With those settings you are effectively 'maxed-out'.
The advantage of reducing the C value would only be in reducing the load on your i7
It probably would be almost imperceptible.
The histogram below shows the actual value of decode_cycles for all your 40 m spots on 22 June 2022.
Note the log Y axis scale of number of instances. While there is a very long tail out to your max of 10,000 on the x axis
the number of instances in each 50-cycle x axis bin is less than 10 whereas over 10,000 of your decoded spots needed less than 50 cycles.

Gwyn G3ZIL


Edward (W3ENR / K3WRG)
 

When this is all reducible to a pointer, or set of simplified instructions, for history majors and similarly hopeless carbon based units, I would appreciate receiving the output!

Edward

W3ENR/K3WRG


On 6/23/22 16:57, Gwyn Griffiths via groups.io wrote:
Steve,
With those settings you are effectively 'maxed-out'.
The advantage of reducing the C value would only be in reducing the load on your i7
It probably would be almost imperceptible.
The histogram below shows the actual value of decode_cycles for all your 40 m spots on 22 June 2022.
Note the log Y axis scale of number of instances. While there is a very long tail out to your max of 10,000 on the x axis
the number of instances in each 50-cycle x axis bin is less than 10 whereas over 10,000 of your decoded spots needed less than 50 cycles.

Gwyn G3ZIL


Phil Karn
 

10,000 is a *lot* of decoder cycles per bit for a sequential decoder. Do you not see some false decodes (on noise) with that setting?

Phil

On 6/22/22 18:05, Rob Robinett wrote:
Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled


Jim Lill
 


That defaults on wsprd -h is misleading.  I consider the values used by wsjt-x to be more the real default,  and they are -C 500 -o 4 which is what I believe WD uses.

-------- Forwarded Message --------
Subject: Re: [wsprdaemon] confirmed issue with decodes
Date: Thu, 23 Jun 2022 20:03:09 -0700
From: Phil Karn <karn@...>
Reply-To: wsprdaemon@groups.io
To: wsprdaemon@groups.io, Thomas Paratore <WA2TP@...>
CC: Philip Barnard <vk7jj@...>


10,000 is a *lot* of decoder cycles per bit for a sequential decoder. Do you not see some false decodes (on noise) with that setting?

Phil

On 6/22/22 18:05, Rob Robinett wrote:
Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled


KD2OM
 

Phil,

I see some, not very many each day.

Steve KD2OM

On 6/24/22 03:03, Phil Karn wrote:

10,000 is a *lot* of decoder cycles per bit for a sequential decoder. Do you not see some false decodes (on noise) with that setting?

Phil

On 6/22/22 18:05, Rob Robinett wrote:
Hi Tom,

I am cc'ing this to the group since it seems of general importance to WD users.

Thanks for looking so closely at that difference which I think can be explained by the difference in how WD is run on the two systems:

           WA2TP    executes 'wsprd -C 1000 -o 4"
while WA2TP-2 executes  'wsprd -C  500  -o 2"

From the wsprd help output:
   -C maximum number of decoder cycles per bit, default 10000
   -o n (0<=n<=5), decoding depth for OSD, default is disabled


KD2OM
 

Thanks Gwyn. I seem to have some headroom most of the time so It really isn't taxing the pc too much. I am considering adding a 4th receiver, mostly because I would like to use the receiver to listen as well as run wspr, right now all three are in 14 channel mode and not too many empty channels.

Steve KD2OM

On 6/23/22 13:57, Gwyn Griffiths via groups.io wrote:
Steve,
With those settings you are effectively 'maxed-out'.
The advantage of reducing the C value would only be in reducing the load on your i7
It probably would be almost imperceptible.
The histogram below shows the actual value of decode_cycles for all your 40 m spots on 22 June 2022.
Note the log Y axis scale of number of instances. While there is a very long tail out to your max of 10,000 on the x axis
the number of instances in each 50-cycle x axis bin is less than 10 whereas over 10,000 of your decoded spots needed less than 50 cycles.

Gwyn G3ZIL