|
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
|
|
|
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.
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
|
|
|
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.
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.
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
|
|
|
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:
toggle quoted message
Show quoted text
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.
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.
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
|
|
|
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 
|
|
|
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:
toggle quoted message
Show quoted text
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
|
|
|
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:
toggle quoted message
Show quoted text
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
|
|
|
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 --------
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:
toggle quoted message
Show quoted text
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:
toggle quoted message
Show quoted text
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:
toggle quoted message
Show quoted text
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
|
|
|
