Michael, Comments/questions below:
On 10/23/06, Michael Dickens <[EMAIL PROTECTED]> wrote:
Hence I would believe that if you're running on a single-cpu G4 or G5, even up to 2 GHz, the wxGUI stuff probably won't be very effective. OTOH, running a dual-G4 @ 1.25 GHz -just barely- works, so running a Dual-G5 @ 2.0 GHz, or the new Core-Duo's at 2.0 GHz, will surely be good enough to get a reasonable display - but nothing special compared do the same hardware running Linux.
OK, that is interesting....are these things (G4s) really that slow? Or is something killing the performance in the middle on a Mac? I know how to limit FFT CPU utilization via the window sizes, but is there a way to limit the WxPython window updates to something lower?
I would be quite curious about the CPU utilization of a Linux box - along with the hardware specs to make the judgement relatively correct. Even better would be to try an Intel Mac running both OSX and Linux and compare the CPU utilization ... hmmm ... that would be pretty cool so I'll look into it. - MLD
I just posted another message on this last night (haven't seen it come across the list yet) but my Fry's budget linux box (AMD 2200+ 1.5 GHz no-frills w/onboard video) can't quite handle the usrp_wfm_rcv.py script. I get a slight pause in the FFT window update, a slight pause in the audio playback and underruns/overruns (OouOou) on the CLI. The CPU hits about 65% with the "python" process and Xorg takes the rest of the CPU (35%) according to Top. The usrp_wfm_nogui puts out audio fine, at about 35% cpu load if I recall. It seems that the WxPython is quite a resource consumer on any platform... Dave _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
