run seedlink client in thread

[megies]

Hi Sebastien! I had a look at your tool yesterday. I like it. :) However I noticed the GUI freezing, especially when all old packets are updated already and new ones only come in slowly. Actually, the GUI main thread gets blocked by the seedlink client, as it never exits the run() method and stays in it forever. So, I moved the code around a bit and refactored the subclassed seedlink client to run in a thread (and only update the stream, leaving the plot updating to the GUI). It might not be very nice/thread-safe right now but it seems to work..

Things to check:

• thread safe handling of the shared stream object necessary? (locking?)
• the seedlink client thread needs to be killed when the GUI is closed
• some of the plot updating logic is commented, maybe that needs to be reintegrated..
• the progressbar is not working right now

This needs some work before it can be merged. I'll give you and Lion push rights to my fork..

[megies]

I just noticed, that resizing the window after start also works now..

[sbonaime]

Hi Tobias ! The threading of seedlink plotter will be a very good improvement ! I think the progressbar and the "updating logic" are not very important. They were usefull for debuging.

I think we should keep the following code after receiving and merging the new samples otherwise after few days, we will run out of memory. And I would like this drum program to start plotting at round hours. But the trim function does not seems to work ! I Can you help me ?

here is the code

        # process packet data
        trace = slpack.getTrace()
        if trace is None:
            print self.__class__.__name__ + ": blockette contains no trace"
            return False

        #limit the length of main stream buffer
        # Stop time will be the next round date
        now = UTCDateTime()
        stop_time = UTCDateTime(now.year, now.month, now.day, now.hour, 0, 0)+3600
        start_time = stop_time-args.backtrace_time

        print "from "+str(start_time)+" to "+str(stop_time)

        # new samples add to the main stream which is then trim
        with self.lock:
            print "before trim "+ str(self.stream)
            self.stream += trace
            self.stream.merge()
            self.stream.trim(start_time,stop_time)
            print "after trim "+ str(self.stream)
        return False

And the output is

from 2013-04-03T08:00:00.000000Z to 2013-04-03T12:00:00.000000Z before trim 1 Trace(s) in Stream: G.SANVU.00.BHZ | 2013-04-03T08:48:50.550000Z - 2013-04-03T11:48:17.900000Z | 20.0 Hz, 215348 samples after trim 1 Trace(s) in Stream: G.SANVU.00.BHZ | 2013-04-03T08:48:50.550000Z - 2013-04-03T11:48:38.100000Z | 20.0 Hz, 215752 samples

I don't understand why self.stream is not trim or cut...

Thank you

[megies]

Oh yes, we definitely need to trim at some point.. I think in your example there is simply nothing to cut away (Trace starts after start_time and ends before stop_time).

[sbonaime]

Thank you ! In fact, I did not notice that you changed the start_time at the begining ! I revert it to start the initial request from a round time. I will push the trim function today

[megies]

Oh, OK, sorry. I didn't notice how this was used to set minutes and seconds to zero.

[sbonaime]

No problem !

[megies]

OK, should be fine to merge the pull request, I think.

[sbonaime]

I am comparing two PCs I have (exactly same hardware) with 2 seedlink_plotter on each. The one with the threaded seedlink plotter has a 36% CPU usage The old version as less than 1% of CPU usage.

I understand that a threaded version iswhat we should do, but I don't understand why I have more CPU usage ! Do you have the same behavior ?

[megies]

I think this is caused by the update_time default of 1 second which constantly causes a complete redraw. I tried a higher value (e.g 10 secs) and then the CPU% stays down in between redraws. There's a tiny bug, I'll push a fix for the update time command line argument..