Re: [wsjt-devel] WSPR decoder: Jelinek vs Fano
Joe, Here are my results for your data set. I ran 3 cases. The execution times are the average of two runs. Cases 1. wsprd 2. wsprd_exp (Fano, 1 cycles) 3. wsprd_exp (Jelinek, 5000 cycles) Results 1. 2657 (2) decodes in 359s 2. 2760 (13) decodes in 359s 3. 2749 (3) decodes in 346s The interesting part is the number in parentheses. This time, I paid attention to the number of obviously bad decodes. It’s not easy to find the bad decodes that show up as type 1 callsigns - but it is easy to find and count the ones that show up as type 2 or 3 callsigns with a forward slash “/“. The number in parentheses is the number of bad decodes with a slash in the callsign. It needs to be said that we see only the bad decodes that aren’t trapped by a sanity check in the unpacking routines. There is something funny going on with the Fano decoder in case 2. Here is the result of doing a grep for “/“ in the ALL_WSPR results from the three cases: Case 1. wsprd $ grep / Results_wsprd 0342 -28 0.5 0.001523 0 PH6/OK1SCE 10 0630 -14 -0.8 0.001518 0 M0N/BX6IJG 30 Case 2. wsprd_exp Fano $ grep / Results_Fano.txt 0114 -16 -0.3 0.001524 0 88Y/9E3XMR 33 0148 -22 -0.9 0.001523 0 C4S/U23 27 0512 -12 -1.4 0.001544 -1 EYJ/BD3OWF 43 0526 -5 -1.1 0.001515 -1 J28/JH9VOA 10 0530 -10 -1.3 0.001527 -1 XIR/L12IRI 57 0534 -21 0.1 0.001451 0 5EY/588TIB 53 0540 -9 -1.3 0.001498 -1 286/CI7RCI 13 0614 -8 -1.2 0.001523 -1 W64/CZ9IYO 13 0616 -31 -1.0 0.001491 0 M2Q/ZG4VPX 13 0704 -10 -1.3 0.001550 -1 KN4OHP/44 53 0746 -8 -1.4 0.001525 -1 ATD/012KCR 27 0856 -19 -0.8 0.001523 0 I02/VK3PNP 20 1400 -17 -0.5 0.001459 0 P2INE/2 53 Case 3. wsprd_exp Jelinek $ grep / Results_Jelinek5000.txt 0114 -16 -0.3 0.001524 0 88Y/9E3XMR 33 0616 -31 -1.0 0.001491 0 M2Q/ZG4VPX 13 0654 -12 -1.3 0.001523 -1 1LY/GH4 40 Note the large number of bad decodes coming out of the Fano decoder in case 2. There is only one bad decode that is common to cases 2 and 3. If you look at the times, it appears that the bad decodes in case 2 are coming in bursts. I have to wonder if this corresponds to special noise conditions, e.g. lightning storm. It’s hard to reconcile the large difference in bad decodes between pairs 1-2 and 2-3. In 1-2 the decoding algorithm is the same and in 2-3 the candidates are the same. Strange, eh? I’ve just gone back and looked at bad decodes using the same “forward-slash” criterion on two groups of my own wav files and in each case I see either 2 or 3 bad decodes out of about 2000 for Fano and Jelinek. There are no big differences between the number of bad decodes in cases 1-3 for my test data. Still strange. Steve k9an > On Jul 30, 2015, at 8:01 AM, Joe Taylor wrote: > > Hi Greg, > > I have updated Makefile.win32 in ^/branches/wsjtx so that it builds > Steve's new wsprd_exp.exe correctly. > > I have made a tarfile with the set of WSPR *.wav files I used most > recently. It is now posted at > > http://physics.princeton.edu/pulsar/K1JT/wspr_data.tgz > > It's about 1 GB in size. > > -- Joe, K1JT > > On 7/29/2015 11:52 PM, KI7MT wrote: >> Hi Steve, Joe, >> >> I hit another show stopper error also. I'll look at what Joe is using in >> ^/branches/wsjtx_exp and see what the diff's are from the main devel >> branch. >> >> By chance, do you all have a standard set of WSPR .wav files that your >> using to compare with? Would be nice to be able to use a standard set >> for testing. >> >> 73's >> Greg, KI7MT >> >> >> >> On 07/29/2015 07:36 PM, Steven Franke wrote: >>> Greg - >>> The windows Makefile has not been updated for the stack decoder. I’ve only >>> tested it on linux and osx. It looks like the Makefile in Joe’s >>> experimental branch is close to what would be needed - though it shouldn’t >>> need the extended stacksize anymore since we moved the big arrays to heap >>> storage. >>> Steve k9an >>> On Jul 29, 2015, at 1:22 AM, Greg Beam wrote: Hi Joe, Steve, This is off list. I tried to build wsprd_exp on Windows (using Qt 5.2.1 Tool-Chain, not the 5.5 Tool-Chain) and ran into an error. I'm using ^/branches/wsjtx/lib/wsprd folder, and Makefile.win32, is that the correct location and Makefile file? Here's the error I'm getting: - wsprd_exp.o:wsprd_exp.c:(.text.startup+0x244c): undefined reference to `jelinek' collect2.exe: error: ld returned 1 exit status Makefile.win32:34: recipe for target 'wsprd_exp' failed mingw32-make: *** [wsprd_exp] Error 1 Any Ideas? 73's Greg, KI7MT On 7/28/2015 1:49 PM, Steven Franke wrote: > Hi Greg and Joe, > > As Joe said, the stack decoder is only in wsprd_exp and it requires a > command-line argument (-J) to activate it, as the default algorithm in > wsprd_exp is the Fano algorithm. > > The tests conducted by me and Joe show that my implementation of > Jelinek’s stack-bucket alg
Re: [wsjt-devel] JTSDK Nix v2.0.12 Available
Hi ALan,
Ah, ok, that's good to know.
Maybe a change in Makefile.in should be made. I've not specifically
tested changing ownership to just $USER, rather than both $USER:$USER (
user and group).
I'll do some testing on that for the next update. To make sure I've got
your edits correct, can you send me a quick patch between the orig, and
modified Makefile and / or Makefile.in ?
Thanks.
73's
Greg, KI7MT
On 7/30/2015 4:01 PM, Alan VK2ZIW wrote:
> Hi Greg,
>
> Fedora 21 x86_64
>
> "./autogen.sh" ran fine.
>
> "make" failed:
>
> Package : JTSDK 2.0.12
> /bin/sh: -c: line 0: syntax error near unexpected token `('
> /bin/sh: -c: line 0: `echo " Distribution ..: "Fedora release 21
> (Twenty One)" x86_64"'
> Makefile:96: recipe for target 'make-summary' failed
> make: *** [make-summary] Error 1
>
> So I changed DESC in Makefile, removed "()".
>
> Running "make install" failed:
> ..Changing /home/alanb/jtsdk Ownership to: [ alanb ]
> /usr/bin/chown: invalid group: ‘alanb:alanb’
> Makefile:116: recipe for target 'install' failed
> make: *** [install] Error 1
>
> ---
> My system does not have a group named "alanb",
> this is up to the sys-admin.
>
> Thanks
>
> Alan VK2ZIW
>
>
>
>
>
> On Thu, 30 Jul 2015 14:52:07 -0600, KI7MT wrote
>> Hi Pino,
>>
>> Thanks for catching the URL Typo:
>>
>> Correct SVN TAGS URL for jtsdk-nix-2.0.12:
>>
>> svn co https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-nix/tags/jtsdk-
>> nix-2.0.12
>>
>> 73's
>> Greg, KI7MT
>>
>> --
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> Alan
>
> Man's greatest waste of time: Worshipping the wrong God.
> Consider Jesus.
> ---
> Alan Beard Unix Support Technician from 1984 to today
> 70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS
> Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc..
> +61 2 47353013 (h) Support Programming, shell scripting, "C", assembler
> 0414 353013 (mobile) After uni, electronics tech
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JTSDK Nix v2.0.12 Available
Hi Greg,
Fedora 21 x86_64
"./autogen.sh" ran fine.
"make" failed:
Package : JTSDK 2.0.12
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `echo " Distribution ..: "Fedora release 21
(Twenty One)" x86_64"'
Makefile:96: recipe for target 'make-summary' failed
make: *** [make-summary] Error 1
So I changed DESC in Makefile, removed "()".
Running "make install" failed:
..Changing /home/alanb/jtsdk Ownership to: [ alanb ]
/usr/bin/chown: invalid group: ‘alanb:alanb’
Makefile:116: recipe for target 'install' failed
make: *** [install] Error 1
---
My system does not have a group named "alanb",
this is up to the sys-admin.
Thanks
Alan VK2ZIW
On Thu, 30 Jul 2015 14:52:07 -0600, KI7MT wrote
> Hi Pino,
>
> Thanks for catching the URL Typo:
>
> Correct SVN TAGS URL for jtsdk-nix-2.0.12:
>
> svn co https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-nix/tags/jtsdk-
> nix-2.0.12
>
> 73's
> Greg, KI7MT
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Alan
Man's greatest waste of time: Worshipping the wrong God.
Consider Jesus.
---
Alan Beard Unix Support Technician from 1984 to today
70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS
Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc..
+61 2 47353013 (h) Support Programming, shell scripting, "C", assembler
0414 353013 (mobile) After uni, electronics tech
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] JTSDK Win32 - Planned Upgrades
Hello All,
Following Bill's ( G4WJS ) message to the development list regarding
Qt5.5 / GCC 4.9 tool chain testing:
OP: http://sourceforge.net/p/wsjt/mailman/message/34322744/
I've updated the the WSJT-X + Hamlib3 build scripts in JTSDK Win32 to
allow for testing ( switching between ) QT5.5 / GCC 4.9 and Qt5.2 / GCC
4.8 frame works.
The upgrade will require two actions:
1. Updating JTSDK Scripts ( Start Menu or JTSDK Maintenance terminal )
2. Installing jtsdk-win32-u2.exe ( InnoSetup Installer )
At present, Sourceforge is still restoring various developer services,
the files download section being one of them. ETA JUL-31st.
Once the files section is restored, I can then add the U2 installer so
folks to download it. This is a fairly hefty file ~600MG compressed,
requiring ~4GB install space, as it's a full QT55, GCC Mingw 4.9 and
QtCreator installation.
Operating the switch if fairly simple - ( Note, this will not function
properly until the U2 installer has been run, but should not affect
builds using the Qt5.2 / GCC 4.8 )
* Open JTSDK-QT
* Type: qt55-enable
* Close and Then re-open JTSDK-QT
That should set the Qt5.5 and MinGW 4.9 tool chain as the default tool
set. You should see, on the opening screen, messages indicating which
tool-chain / QT framework is active.
To switch back to the Qt5.2 / GCC 4.8 tool-chain:
* Open JTSDK-QT
* Type: qt55-disable
* Close and Then re-open JTSDK-QT
The build, install and package directories are all separate from the
standard locations, including Hamlib3, suffixed with "-qt55", for example:
When Disabled: ( using Qt5.2 / GCC 4.8 ):
C:\JTSDK\wsjtx\{build,install,package .. .. ..}
C:\JTSDK\hamlib3\{bin,include,lib .. .. ..}
When Enabled: ( using Qt5.5 / GCC 4.9 )::
C:\JTSDK\wsjtx-qt55\{build,install,package .. .. ..}
C:\JTSDK\hamlib3-qt55\{bin,include,lib .. .. ..}
The source directories, for both WSJTX and Hamlib3 remain as is:
C:\JTSDk\src\ .. .. ..
All build commands remain as is:
* checkout-wsjtx
* build-wsjtx rinstall
and so on.
Before building WSJT-X, using the QT5.5 / GCC 4.9 tool-chain, remember
to build Hamlib3 first, otherwise, you will likely get a Cmake fault
during the configuration phase stating Hamlib3 cannot be found.
Additionally, QT5.5 was built with MSVC-2013 as opposed to MSVC-2010 for
Qt5.2. As such, if you do not have the MSVC 2013 Redist DLL's installed,
which "may be" required for proper runtime testing, you will need to
install them. Not too worry, the Qt55 installation bundles the correct
Redist-Instller. You will find find the Redist-Installer located in:
C:\JTSDK\qt55\redist
or similar location. Simply running the installer should get you what is
needed.
When the jtsdk-win32-u2.exe installer is available from Sourceforge, I
will send out additional information on how-to perform the upgrade and
installation for JTSDK Win32.
73's
Greg, KI7MT
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JTSDK Nix v2.0.12 Available
Hi Pino, Thanks for catching the URL Typo: Correct SVN TAGS URL for jtsdk-nix-2.0.12: svn co https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-nix/tags/jtsdk-nix-2.0.12 73's Greg, KI7MT -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] JTSDK Nix v2.0.12 Available
El 30/07/15 a las 16:17, wsjt-devel-requ...@lists.sourceforge.net escribió: > *DEBIAN/UBUNTU UPGRADE INSTRUCTIONS* > > * Supported ARCH: i386, amd64 and ARMv7 > * Open a terminal, then > * sudo apt-get update && sudo apt-get upgrade > > > * SOURCE BUILD UPGRADE INSTRUCTIONS* > * Open a terminal, then > * svn co https://svn.code.sf.net/p/jtsdk/jtsdk/tags/jtsdk-nix-2.0.12 > * cd jtsdk-nix-2.0.12 > * ./autogen.sh && make && sudo make install && sudo -k > > NOTE: The Sourceforge file downloading area is current undergoing > maintenance. ETA is End of Day JUL-31st. At which point, a tar.gz file > will be made available for JTSDK v2.0.12. Until this time, using the > tags section of the svn repos should suffice. > > > 73's > Greg, KI7MT svn co https://svn.code.sf.net/p/jtsdk/jtsdk/tags/jtsdk-nix-2.0.12 svn: E17: El URL «https://svn.code.sf.net/p/jtsdk/jtsdk/tags/jtsdk-nix-2.0.12» no existe pino@Radio3:~$ URL does not exist :-( 73 Pino ZP4KFX -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] JTSDK Nix v2.0.12 Available
Hello All, Thanks to Tom (N8TL) and others for sending in issues reports and testing fixes. *CHANGE-LOG* -Fixed various $USER path issues with configure, make, make install -Fixed path issue in jtsdk-wspr which cased the script to error out -Fixed / Added KVASD link function with messaging -Added WSJT-X v1.6.0-devel branch Superbuild script -Updated On-Screen Messages -Re-Activated WSJT-X v1.6.1 builds ( WSJT-X EXP builds ) -De-Activated WSJT-X RC Builds as there are no pending releases -Ubuntu 14.10 ( Utopic ) is now EOL. Updates are no longer available. *SUPERBUILD-NOTES* The WSJT-X Superbuild from Bill ( G4WJS ) is a new feature addition to JTSDK. It's been in the SVN repo for some time, but just now being added to JTSDK Nix. Superbuild is also used to produce the wsjtx.tgz files used in compiling the WSJTX-NEXT PPA. Basically, it will perform the following tasks ( all from the SVN repositories ): * Downloads WSJT-X v1.6.0 ( ^/branches/wsjtx ) & Hamlib3 sources * Create a single tar.gz file ready for compiling or transfer * Configures and Builds WSJT-X using the downloaded Hamlib3 sources * Install WSJT-X v1.6.0 to the user space for testing * All build and install locations are separated from the normal v1.6.0 build and install paths *SUPERBUILD-INFO* Link: http://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx-superbuild/ *DEBIAN/UBUNTU UPGRADE INSTRUCTIONS* * Supported ARCH: i386, amd64 and ARMv7 * Open a terminal, then * sudo apt-get update && sudo apt-get upgrade * SOURCE BUILD UPGRADE INSTRUCTIONS* * Open a terminal, then * svn co https://svn.code.sf.net/p/jtsdk/jtsdk/tags/jtsdk-nix-2.0.12 * cd jtsdk-nix-2.0.12 * ./autogen.sh && make && sudo make install && sudo -k NOTE: The Sourceforge file downloading area is current undergoing maintenance. ETA is End of Day JUL-31st. At which point, a tar.gz file will be made available for JTSDK v2.0.12. Until this time, using the tags section of the svn repos should suffice. 73's Greg, KI7MT -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR decoder: Jelinek vs Fano
Hi Joe,
Thanks. I'm downloading the data now and will do some test runs later
this evening.
73's
Greg, KI7MT
On 07/30/2015 07:01 AM, Joe Taylor wrote:
> Hi Greg,
>
> I have updated Makefile.win32 in ^/branches/wsjtx so that it builds
> Steve's new wsprd_exp.exe correctly.
>
> I have made a tarfile with the set of WSPR *.wav files I used most
> recently. It is now posted at
>
> http://physics.princeton.edu/pulsar/K1JT/wspr_data.tgz
>
> It's about 1 GB in size.
>
> -- Joe, K1JT
>
> On 7/29/2015 11:52 PM, KI7MT wrote:
>> Hi Steve, Joe,
>>
>> I hit another show stopper error also. I'll look at what Joe is using in
>> ^/branches/wsjtx_exp and see what the diff's are from the main devel
>> branch.
>>
>> By chance, do you all have a standard set of WSPR .wav files that your
>> using to compare with? Would be nice to be able to use a standard set
>> for testing.
>>
>> 73's
>> Greg, KI7MT
>>
>>
>>
>> On 07/29/2015 07:36 PM, Steven Franke wrote:
>>> Greg -
>>> The windows Makefile has not been updated for the stack decoder. I’ve only
>>> tested it on linux and osx. It looks like the Makefile in Joe’s
>>> experimental branch is close to what would be needed - though it shouldn’t
>>> need the extended stacksize anymore since we moved the big arrays to heap
>>> storage.
>>> Steve k9an
>>>
On Jul 29, 2015, at 1:22 AM, Greg Beam wrote:
Hi Joe, Steve,
This is off list.
I tried to build wsprd_exp on Windows (using Qt 5.2.1 Tool-Chain, not the
5.5 Tool-Chain) and ran into an error. I'm using
^/branches/wsjtx/lib/wsprd folder, and Makefile.win32, is that the correct
location and Makefile file?
Here's the error I'm getting:
-
wsprd_exp.o:wsprd_exp.c:(.text.startup+0x244c): undefined reference to
`jelinek'
collect2.exe: error: ld returned 1 exit status
Makefile.win32:34: recipe for target 'wsprd_exp' failed
mingw32-make: *** [wsprd_exp] Error 1
Any Ideas?
73's
Greg, KI7MT
On 7/28/2015 1:49 PM, Steven Franke wrote:
> Hi Greg and Joe,
>
> As Joe said, the stack decoder is only in wsprd_exp and it requires a
> command-line argument (-J) to activate it, as the default algorithm in
> wsprd_exp is the Fano algorithm.
>
> The tests conducted by me and Joe show that my implementation of
> Jelinek’s stack-bucket algorithm doesn’t seem to provide any significant
> advantage over the Fano decoder in the wspr application. I am still
> inclined to replace the current wsprd with the Fano version of wsprd_exp.
> All of my tests indicate that the default configuration of wsprd_exp
> produces more decodes in less time than wsprd does. This is due to
> improvements in the sync algorithm and not due to anything related to the
> sequential decoder. However --- when Joe compared wsprd to wsprd_exp
> (Fano) he didn’t find any significant difference between the two. If you
> decide to do some tests, Greg, it’d be interesting to see if you see any
> difference between wsprd and wsprd_exp (with the default settings).
>
> Steve
>
>> On Jul 28, 2015, at 2:22 PM, Joe Taylor wrote:
>>
>> Hi Greg,
>>
>> The experimental ("Jelinek") decoder is currently being built only as
>> wsprd_exp.
>> -- Joe
>>
>> On 7/28/2015 3:08 PM, Greg Beam wrote:
>>> Hi Joe, Steve,
>>>
>>> Are these updates in the main wsprd binary, or do we still need to build
>>> the wsprd_exp binary and copy it over to wsprd to test the changes?
>>>
>>> 73's
>>> Greg, KI7MT
>>>
>>> On 7/28/2015 12:22 PM, Joe Taylor wrote:
Hi Steve,
Nice job with implementation of a sequential decoder using the Jelinek
Stack Algorithm!
I have now run some reasonably thorough tests of it, comparing results
with the default Fano decoder in wsprd. I confirm essentially all of
your basic conclusions. Jelinek with maxcycles=5000 produces nearly
the
same results, in the same execution time, as Fano with maxcycles=1.
In my tests the command-line "-d" option produced about 7-8% more
decodes, at the cost of roughly 5 x longer execution time. Again, this
was true for both Fano and Jelinek.
Now we know... which is good!
-- Joe, K1JT
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>> --
>>> ___
>>> wsjt-devel mailing list
Re: [wsjt-devel] WSPR decoder: Jelinek vs Fano
Hi Greg,
I have updated Makefile.win32 in ^/branches/wsjtx so that it builds
Steve's new wsprd_exp.exe correctly.
I have made a tarfile with the set of WSPR *.wav files I used most
recently. It is now posted at
http://physics.princeton.edu/pulsar/K1JT/wspr_data.tgz
It's about 1 GB in size.
-- Joe, K1JT
On 7/29/2015 11:52 PM, KI7MT wrote:
> Hi Steve, Joe,
>
> I hit another show stopper error also. I'll look at what Joe is using in
> ^/branches/wsjtx_exp and see what the diff's are from the main devel
> branch.
>
> By chance, do you all have a standard set of WSPR .wav files that your
> using to compare with? Would be nice to be able to use a standard set
> for testing.
>
> 73's
> Greg, KI7MT
>
>
>
> On 07/29/2015 07:36 PM, Steven Franke wrote:
>> Greg -
>> The windows Makefile has not been updated for the stack decoder. I’ve only
>> tested it on linux and osx. It looks like the Makefile in Joe’s experimental
>> branch is close to what would be needed - though it shouldn’t need the
>> extended stacksize anymore since we moved the big arrays to heap storage.
>> Steve k9an
>>
>>> On Jul 29, 2015, at 1:22 AM, Greg Beam wrote:
>>>
>>> Hi Joe, Steve,
>>>
>>> This is off list.
>>>
>>> I tried to build wsprd_exp on Windows (using Qt 5.2.1 Tool-Chain, not the
>>> 5.5 Tool-Chain) and ran into an error. I'm using ^/branches/wsjtx/lib/wsprd
>>> folder, and Makefile.win32, is that the correct location and Makefile file?
>>>
>>> Here's the error I'm getting:
>>> -
>>> wsprd_exp.o:wsprd_exp.c:(.text.startup+0x244c): undefined reference to
>>> `jelinek'
>>> collect2.exe: error: ld returned 1 exit status
>>> Makefile.win32:34: recipe for target 'wsprd_exp' failed
>>> mingw32-make: *** [wsprd_exp] Error 1
>>>
>>>
>>> Any Ideas?
>>>
>>> 73's
>>> Greg, KI7MT
>>>
>>>
>>>
>>> On 7/28/2015 1:49 PM, Steven Franke wrote:
Hi Greg and Joe,
As Joe said, the stack decoder is only in wsprd_exp and it requires a
command-line argument (-J) to activate it, as the default algorithm in
wsprd_exp is the Fano algorithm.
The tests conducted by me and Joe show that my implementation of Jelinek’s
stack-bucket algorithm doesn’t seem to provide any significant advantage
over the Fano decoder in the wspr application. I am still inclined to
replace the current wsprd with the Fano version of wsprd_exp. All of my
tests indicate that the default configuration of wsprd_exp produces more
decodes in less time than wsprd does. This is due to improvements in the
sync algorithm and not due to anything related to the sequential decoder.
However --- when Joe compared wsprd to wsprd_exp (Fano) he didn’t find any
significant difference between the two. If you decide to do some tests,
Greg, it’d be interesting to see if you see any difference between wsprd
and wsprd_exp (with the default settings).
Steve
> On Jul 28, 2015, at 2:22 PM, Joe Taylor wrote:
>
> Hi Greg,
>
> The experimental ("Jelinek") decoder is currently being built only as
> wsprd_exp.
> -- Joe
>
> On 7/28/2015 3:08 PM, Greg Beam wrote:
>> Hi Joe, Steve,
>>
>> Are these updates in the main wsprd binary, or do we still need to build
>> the wsprd_exp binary and copy it over to wsprd to test the changes?
>>
>> 73's
>> Greg, KI7MT
>>
>> On 7/28/2015 12:22 PM, Joe Taylor wrote:
>>> Hi Steve,
>>>
>>> Nice job with implementation of a sequential decoder using the Jelinek
>>> Stack Algorithm!
>>>
>>> I have now run some reasonably thorough tests of it, comparing results
>>> with the default Fano decoder in wsprd. I confirm essentially all of
>>> your basic conclusions. Jelinek with maxcycles=5000 produces nearly the
>>> same results, in the same execution time, as Fano with maxcycles=1.
>>>
>>> In my tests the command-line "-d" option produced about 7-8% more
>>> decodes, at the cost of roughly 5 x longer execution time. Again, this
>>> was true for both Fano and Jelinek.
>>>
>>> Now we know... which is good!
>>>
>>> -- Joe, K1JT
>>>
>>> --
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>> --
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> http
Re: [wsjt-devel] UDP messages dropped
Well..by "busy" I mean he's got only 2 idle cores when running. The other 6 are not pegged at all but run 25-50% or so. 73 Mike W9MDB -Original Message- From: KI7MT [mailto:ki...@yahoo.com] Sent: Wednesday, July 29, 2015 11:26 PM To: WSJT software development Subject: Re: [wsjt-devel] UDP messages dropped I wouldn't think the box is loaded to hard with an 8350 engine, those have a bit of pep to them, unless he's go allot of background tasking going on. Way OT here, but: I've had a pile of the AMD FX Black edition CPU's at one point, and still have a couple in the basement running as servers. Early models were not too good, but the 8-Series seems ok. My next build is going to be on a Tyan or Supermicro motherboard, with at least 2x 6-Series Opteron's, like the 6344's or there about would be nice.. I'd like a 4-hole motherboard, but that can get expensive in a hurry :-) 73's Greg, KI7MT On 07/29/2015 09:48 PM, Michael Black wrote: > Ran some tests and confirmed WSJT-X was sending out all packets. > Interesting that when we used multicast no packets got dropped > ever.only when using unicast localhost. > > > > Laurie said JTAlert only has a 128 byte buffer so that may explain the > problem. He's aware now and hopefully we'll have a fix soon. > > > > I have to write a test program for my friend as his system appears to > be single-threading WSJT-X. He's running a Flex 3000 so his 8-core > system is still pretty busy but the JT9 decodes have a noticeable > delay after the JT65 and are all bunched together. > > So I'll create a program to test how many cores his system reports. > Is an AMD 8350 CPU. > > > > 73 > > Mike W9MDB > > > > From: Bill Somerville [mailto:g4...@classdesign.com] > Sent: Wednesday, July 29, 2015 10:30 AM > To: wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] UDP messages dropped > > > > On 29/07/2015 16:19, Michael Black wrote: > Hi Mike, > > Actually just tested and looks like JTAlert is doing multicast too. > So I'll see about tracking this with him. > > That can't be so if you cannot change the server address, multicast > will only work with a multicast group address as it requires > cooperation from the NIC and any routers in the network path. > > Beware of running multiple servers on the same host without multicast > addressing, in that case each datagram will only be delivered to one > application and appear dropped to the other(s). > > > > I watched his system for a while and didn't see interspersed JT9's but > I'll watch close next time. > > Gotta' get some activity on the bands to see this I think. I'll watch > my own system but can't say I've noticed this (and not sure I would > have either since I wasn't looking for it). > > Was really obvious on his systems since he doesn't have many JT9's and > they were all missing from JTAlert. > > > > I'm not sure of the underlying logic which causes UDP reordering. I > went through an argument with a banking software firm many years ago > having to inform them that TCP wasn't a guaranteed protocol which they > though it was and they were blaming our software for dropping > transactions when it wasn't our fault at all and they finally had to > add another layer of ACK/NAK to the transactions to ensure end-to-end integrity even over dropped connections. > > UDP reordering usually requires a complex network of routers (the > Internet > usually) it can happen if a router fails, has to retry or, decides a > lower cost path is possible. Not really relevant to our application > although WSJT-X doesn't make any assumptions about where on the > Internet the UDP server lives. > > > > > > Thanks and I'll let you know the results. > > > > 73 > > Mike W9MDB > > 73 > Bill > G4WJS. > > > > > > From: Bill Somerville [mailto:g4...@classdesign.com] > Sent: Wednesday, July 29, 2015 10:08 AM > To: wsjt-devel@lists.sourceforge.net > Subject: Re: [wsjt-devel] UDP messages dropped > > > > On 29/07/2015 15:58, Michael Black wrote: > Hi Mike, > > Actually he's running a Flex 3000 and an 8-core machine. > > Interesting, is it possible he has set CPU affinity. Maybe it was just > that all the JT9 decodes took longer than the longest JT65 decode but > that is fairly unusual. > > > > > JTAlert doesn't currently allow setting the IP address so it's not > multi-cast. I'll see if about getting that done though. > > It's not quite as simple as setting the address, a multicast server > has to join the group as well. > > > > > Side-by-side is good idea. > > And a sequence number does take a step towards TCP but is still not a > bad idea so you can at least detect dropped packets. People could be > using this now and not know they are missing decodes. > > Datagrams can also be delivered out of order so it gets complicated fast. > Anyway on a loopback connector neither out of order delivery nor > dropped datagrams should happen unless the re
