[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Debugging overruns

From: Dan Halperin
Subject: Re: [Discuss-gnuradio] Debugging overruns
Date: Mon, 29 Jan 2007 10:23:37 -0800
User-agent: Thunderbird (X11/20070103)

An unanswered question from before:
>> Also, another (incidental) question, I get really bad performance when the 
>> fusb_options set by realtime being true are used....
What are the fusb_options all about, and how can I get intuition on the
right settings for them?
> I think you're burning up all the cycles constructing the string
> of random bytes.  Building the string byte by byte is very expensive.
> Basically O(N^2).
> Try this:
>   def random_bytes(number):
>     return ''.join([chr(randint(0, 255)) for x in range(number)])
> Also, are you sure you're not holding onto references to old payloads
> somewhere?  If you are, no amount of garbage collection or reference
> counting will save you ;)
I implemented the above change and a few other optimizations (googling
for python optimization is an effective tactic); but the problem
persists. It does seem to be tied to Python's randomization choking
after python's randint was called ~512k times; in particular, 512k =
524288 bytes and I was running into massive overruns after generating:

~445 1200-byte packets (1200*445 = 534000)
~524 1024-byte packets (1024*524 = 536576)
~700 768-byte packets (768*700 = 537600)

Old payloads are definitely not being kept around; they are processed
and the only output is the number of bit errors in each packet.

I'll figure out another way around the randomness problem, maybe using
an LRS or something.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]