Oddities in trunk [@8800 - @8850]
a few days ago I bought a new host system for my GNURadio development
activities. Intel E8400 CPU, G35 express chipset.
All tests with such machine were ok. Reported chipset throughputs were
32MB/s etc…
Then I compiled and ran my Soft-DVB modulator code.
It built successfully and the application seemed to work all right but
the
signal was not recognized by any of my receivers.
I actually started blaming any single piece of the HW and tested all of
them
but nothing was wrong.
at last I foud the problem to be the revision of the trunk I used.
More precisely, using Exactly The Same Soft-DVB code on every revision I
get:
1.all revisions provide flawless building and instantiation of Soft-DVB
application
2.all revisions prior to 8800 have soft DVB producing a perfectly
receivable
signal
3.all revisions after 8850 have soft DVB producing a totally corrupted
signal.
currently I’m testing to see what could be the modification responsible
for
this and report that to the list… actually this effort of testing
various
trunk samples taken from the trunk evolution is quite time consuming…
but I’ll report any discovery to this list.
If anybody has suggestions… they’d be enormously appreciated
really thanks
vincenzo
PS
I suspect something that has got to do with syncronization of computed
output chunks… but It’s just a feeling and, indeed
quite generic… 
On Sat, Sep 06, 2008 at 03:20:28AM +0200, Vincenzo P. wrote:
signal was not recognized by any of my receivers.
I actually started blaming any single piece of the HW and tested all of them
but nothing was wrong.
Vincenzo,
Are there any warning produced when you compile your code?
If so, make whatever changes are required to make them go away.
What distribution and what version of g++ are you using?
We’ve found that gcc 4.3 does different optimization than earlier
versions, and code that worked before (but might have unspecified
behavior in some cases) might need some corrections.
3.all revisions after 8850 have soft DVB producing a totally corrupted
signal.
Please continue to bisect. log2(50) is ~6 so it shouldn’t take too
long (particularly if you’re using ccache).
On Sun, Sep 07, 2008 at 12:41:32AM +0200, Vincenzo P. wrote:
Ok, I really don’t Yet know why but:
If I restore the mistake you corrected in changeset 8835,
everything seems fine… :-o !
And Soft-DVB works even with the latest trunk in the single threaded mode.
Can you post a a link to your code?
Do you know which of your blocks is failing?
Unfortunately If I select the TPB mode, the signal isn’t readable any
longer again…
I expect that this is really a synchronization issue,
still I’ve got no Idea what the hell happened with gr_sync_interpolator
before and after changeset 8835
Are you subclassing gr_sync_interpolator?
Are you overriding forecast in the same class?
For sure, Soft-DVB has been working with trunks from october 2007 to
changeset 8835
Please let me know what you think…
vincenzo
I’m guessing that if you are overriding forecast, there’s a bug in it.
OK, I’ve solved it. It was my fault as usual… 
Are you subclassing gr_sync_interpolator?
YUP
Are you overriding forecast in the same class?
NOPE
what happened is that I mistook gr_sync_interpolator buggy behavior for
a
feature belonging to gnuradio.
It was indeed a useful feature for my purposes, and I built upon it.
Before
8835, you could lock the value of noutput_items when using an
interpolator
by simply feeding into it a noutput_items-long vector.
after 8335, this was no longer true and set me into troubles.
right now, I’m overriding fixed_rate_ninput_to_noutput in order to
obtain
the same result.
It works. (using set output multiple did not)
If there’s a better way, I’m eagerly listening.
Still TPB scheduler does not work with Soft-DVB.
Indeed I’m looking forward to parallelizing Soft-DVB code, and I need to
understand more of all this. I’ll look for references and direction on
the
wiki.
Just a preliminary question. Do we have already the new scheduler
working
also on the cell? I mean would it just do on the PS3 the same
parallelization it is doing un my intel dual core cpu?
really thanks for support…
I wouldn’t have fixed the thing without your suggestions…
vincenzo
On Mon, Sep 08, 2008 at 12:39:43AM +0200, Vincenzo P. wrote:
right now, I’m overriding fixed_rate_ninput_to_noutput in order to obtain
the same result.
It works. (using set output multiple did not)
If there’s a better way, I’m eagerly listening.
I think you misunderstand what gr_sync_interpolator is for.
To override fixed_rate_ninput_to_noutput would be very nonstandard.
If you are using gr_sync_interpolator, you should be prepared to deal
with whatever it passes to the work method.
What are you trying to accomplish? Is there some kind of constraint
that you are trying to impose on how work is called? If so, what is it?
Just a preliminary question. Do we have already the new scheduler
working also on the cell? I mean would it just do on the PS3 the
same parallelization it is doing un my intel dual core cpu?
The new scheduler works on the cell, but it doesn’t schedule the
blocks onto the SPEs. At this time you need to write SPE-aware
blocks that use the gcell library. Look for lots of examples in the
next month or so.
really thanks for support…
I wouldn’t have fixed the thing without your suggestions…
You’re welcome!
Eric
