RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Tuesday, 11 May 2010 10:55 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On Wed, May 12, 2010 at 04:34:36PM +0930, Ian Holland wrote: Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. Ian, I still suspect something in your host setup. Is the USRP2 connected directly to the host or does it go through a switch? If there's a switch in the path, please remove it. Note that the cpu throttling / clock scaling hypothesis would explain why it works better under higher load than lower load. Are you sure that your cpu isn't being throttled? When you're seeing the problem, try: $ grep 'cpu MHz' /proc/cpuinfo and see if all cores are running at full speed. E.g., Idling laptop (throttled back from 1.83GHz): [...@cyan ~]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 1000.000 cpu MHz : 1000.000 Server with cpu scaling disabled: [...@octo swig]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 Eric -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric I was not running through a switch. I tried what you suggested, and can confirm that the CPUs are not being throttled. I have then discovered that for some reason I can only get the problem to occur on one of my two host PCs. I am trying to install the new Ubuntu (actually, the 64-bit version thereof) for the time being, after formatting the hard drive, and am hoping it will work on this PC afterwards. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Thursday, 13 May 2010 4:07 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Wed, May 12, 2010 at 04:34:36PM +0930, Ian Holland wrote: Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. Ian, I still suspect something in your host setup. Is the USRP2 connected directly to the host or does it go through a switch? If there's a switch in the path, please remove it. Note that the cpu throttling / clock scaling hypothesis would explain why it works better under higher load than lower load. Are you sure that your cpu isn't being throttled? When you're seeing the problem, try: $ grep 'cpu MHz' /proc/cpuinfo and see if all cores are running at full speed. E.g., Idling laptop (throttled back from 1.83GHz): [...@cyan ~]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 1000.000 cpu MHz : 1000.000 Server with cpu scaling disabled: [...@octo swig]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 Eric -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On Tue, May 11, 2010 at 09:24:18AM +0930, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? Thanks Ian. What GNU Radio version are you using? git? tarball? What kind of hardware are you running on? How much RAM is in the machine? What OS and distribution are you running? What kernel version are you using? What else is running on the machine? What USRP firmware are you using? What does $ sudo ethtool -a ethN report? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On 05/10/2010 04:54 PM, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 – 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? I don't know what exactly is happening here, as I have not seen this behavior, but I just want to clarify a little terminology. The S you are seeing indicates sequence number errors. While getting packets out of sequence would give this error, that isn't that is happening. The sequence number errors really indicate that you are dropping packets because you can't keep up. Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt I've run into that problem (in a different context--not with USRP2). If you make your filter transition bandwidth some fraction of the overall bandwidth of the filter, you can end up with longish filters and lower bandwidths. I was used to using an expression like (filter_bandwidth/10) for the transition bands, but that ends up with quite long filters. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric Please find my answers inline below. Cheers Ian. What GNU Radio version are you using? git? tarball? Git - Taken from trunk on 25 March 2010. What kind of hardware are you running on? HP Intel Core 2 Duo - 2 x 2 GHz CPUs How much RAM is in the machine? 3513M (according to free -mt) What OS and distribution are you running? Ubuntu 9.10 What kernel version are you using? Release: 2.6.31-20-generic Version: #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 (according to uname -v) What else is running on the machine? Netbeans 6.8, and System Monitor. What USRP firmware are you using? u2_rev3.bin and txrx.bin, which were taken from the latest versions as of 29 January 2010. What does $ sudo ethtool -a ethN report? Pause parameters for eth0: Autonegotiate: on RX:on TX:off ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Matt and Marcus. I understand it is indicating dropped packets, hence causing later ones to show up out-of-sequence. Re the processing, this occurs even with the usrp2_fft.py script as well. I don't think that does more processing for higher values of decimation factor, though please correct me if I am wrong here. Also, I am not doing any special filtering with my code, simply capturing raw complex samples, and comparing their magnitude to a threshold. Of course, once the threshold is crossed I do more computations, but these S's appear even while I am still listening. On the other hand, when I reduce the decimation factor, then I don't have this problem until I do my other processing, which then leads to lost packets due to excessive computational load. As such, I haven't found a value of decimation factor that I can use. Cheers Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Tuesday, 11 May 2010 9:46 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On 05/10/2010 04:54 PM, Ian Holland wrote: Hi All I am coming across problems when using USRP2s with certain decimation factors, and these problems are somewhat counterintuitive. For instance, either using our own code while simply waiting for samples to cross a threshold (so very little computation), I find that I am getting SSS, indicating out-of-sequence packets. This was for a decimation factor of 20. However, when I tried a decimation factor of 10, which should have increased both the Ethernet and the computational requirements, I no longer observed out-of-sequence packets. I tried the same sort of thing with usrp2_fft.py, trying decimations of 10, 16, and 20. For decimations 16 and 20, I got out-of-sequence packets within about 10 - 20 seconds, but with decimation factor 10 I saw no out-of-sequence packets even after a few minutes. Can anybody suggest what might be going on here? I don't know what exactly is happening here, as I have not seen this behavior, but I just want to clarify a little terminology. The S you are seeing indicates sequence number errors. While getting packets out of sequence would give this error, that isn't that is happening. The sequence number errors really indicate that you are dropping packets because you can't keep up. Typically, if you can't keep up at a slow decimation, going to a faster one would make things worse, not better. The only thing I can think of to explain what you are seeing is that you might be doing a lot more processing at the lower rate. For example, at the lower sample rate, you might be making your filter transition bands very narrow, resulting in very long filters. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Tuesday, 11 May 2010 10:55 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
