On Sun, Feb 5, 2012 at 5:07 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
So performance degradation seems to scale with the size of OUTPUT_RECORD_SIZE in gr_oscope_guts.cc. This basically determines howOn 02/05/2012 04:44 PM, Marcus D. Leech wrote:
On 02/05/2012 04:08 PM, Tom Rondeau wrote:
So, what if it was your *own* commit that seemed to be causing a problem? Wouldn't that be embarrassing? I think so :-( :-(
commit 2a2411a598c222e2ef82b857c0b53e0a9d1daf3f
Author: Marcus Leech <mleech@ripnet.com>
Date: Sun Jan 15 23:49:52 2012 -0500
core: fix for off-by-one issue in strip chart. Increases buffer size for longer displays.
I have no idea why this should be a problem, the buffer-shifting for stripchart mode is all done on the C++ side, and the updates are
done at a fairly lazy rate (a few Hz). So it's probably an issue on the Python side with bigger plot buffers. Perhaps there's some kind of
N**2 scaling ugliness going on that wasn't immediately obvious to me when I did that patch.
I think ultimately, the plotting stuff has to move so that most of the computational stuff is done in C++ land, with only the thinnest pieces
done on the Python side.
big the messages are that are sent along to the plotter routines in Python, but the STRIPCHART routine uses it to store the strip-chart
samples in.
It sounds like we need someone to work on a strip-chart functionality for the qtgui sinks. They do everything in C++ land, so we could optimize there more easily.
In other news, glad you found the problem. What do you want to do about it in the meantime, since it's your code, and I think you're the primary user of the oscope under these conditions.
Tom
No comments:
Post a Comment