Get The SonATA Distro Working

From setiquest wiki

Jump to: navigation, search

Contents

Get the SonATA Distro Working Project

An OpenSUSE distribution all set up to install and run SonATA has been graciously created and made available by user KHRM (good job!). A discussion of this distribution is at SonATA Distro http://setiquest.org/forum/topic/customised-distro-run-sonata .

This distribution can be downloaded and booted as a stand alone OpenSUSE environment that has all the necessary libraries and version necessary to download the OpenSonATA source code, build it, and run a demo to prove it is working. This is really nice. But there is a problem.

The problem is that on several installations (all I have tried) the demo will not run, it crashes. This is not the fault of the distro, or how KHRM configured it. The fault lies within the DX code, it is not robust enough to start up consistently in all but the most perfect environment. I am running the distro in a virtual machine, VMFusion (VMWare), which is not as screaming fast as the Dell servers used at the Allen Telescope Array for real-time observations.

Note that sometimes I can get the demo to work in my virtual instance of openSUSE. The error occurs always the first time after a reboot. And quite often it works the second time. Sometimes not. It is elusive.

How to recreate the problem

Follow the instructions at SonATA Distro http://setiquest.org/forum/topic/customised-distro-run-sonata . You'll need to be experienced installing Linux on a separate partition and booting from it, or using VMWare/VMFusion.

After install run "test_sonata". You should get a bunch of terminal windows filling the screen. Wait till the large "System Status" on the right, shows the chan1x and dx1000 ready for action. chan1x and dx1000 need to have the following states:

System-status-window-components-ready.png

After that, in the SSE-Seeker window (lower right) type in "source vger-demo-xpol.tcl" as shown here:

Sse-seeker-window-command.png

This should start up the demo. You should be able to open another terminal and issue the command "waterfallDisplay", File->open and select a compamp file, and see the Voyager waterfall plot being created as the demo runs.

But, no luck. After about 20 seconds the SSE-Seeker window (lower right) shows this:

Dx-error-1.png

And in the system log file window (on the right):

Dx-error-2.png

Debugging - So far

I've (me, jrseti) have tracked this down to

sig-pkg/dx/src/ReceiverTask.cpp in the function "routine()". Great name!

ReceiverTask.cpp-routine-screenshot.png

I've added the "1==>" and "2==>" for discussion here.

First - At "1==>" this crashes if you do not have a multicast IP address specified on the command line of the Dx instance. Example, "127.0.0.1" will case an assert. Is there a better way to handle this? It should not assert here, right?

But, in my example I am using the defaults as installed so it is using a multicast address. So that is not the issue at the moment.

Second, at "2==>" there is the problem. No data is received, and it times out, and then it gets down into the other "routine()" function that seems to assert on addGroup().

ReceiverTask.cpp-routine-2.png

Can you help me find out what is happening here? Why is it not receiving any data from the packetsend process? The packetsend process is reading the Voyager demo data file and streaming the contents over multicast UDP.

Udp->recv() Problem

One part of the problem "may" be in the upd->recv() function. See it used above in sig-pkg/dx/src/ReceiverTask.cpp in the function "routine()" screenshot.

Udp.cpp-recv-screenshot.png

See that if 0 bytes are received (which is not an error as far as recvFrom is concerned) this function returns errno. This is definitely a mistake. If recvFrom() received 0 bytes, this is not a recvFrom() error and the errno that is returned is from some previous unrelated error. The calling function is mistakenly using this errno. Not good.

But what should be done here? First - why is it receiving 0 bytes. Second - can receiving 0 bytes be properly handled to wait fot the next packet of data and not be used?

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox