Forums › BB Series Discussions › BB60C Sweep Test CPU Load Issue
- This topic has 5 replies, 2 voices, and was last updated 7 years, 8 months ago by
blackmore90.
- AuthorPosts
blackmore90ParticipantHello,
I am working on a project in which i need to get sweep data from BB60C and then process those dB-scaled samples on PC. My goal is to divide the 0-6GHz band into two subbands, obtain one sweep for each using two different RBWs and merge them. However, I end up with too much CPU load. The development platform is Visual Studio 2010. To investigate this problem, I use Intel’s V-Tune XE Amplifier 2013 integrated to VS2010. It points to somewhere in bb_api.dll file as most CPU-time utilizing point.I use the following CPP code in a loop so i can continually get sweep data for each spectrum part and merge them:
double reflvl = -30.0;
uint64_t timestamp=0;// Get First Sweep
configure_sweep(362.5e6, 675e6, 30e3, 30e3, 0.2, BB_RBW_SHAPE_FLATTOP, BB_NO_SPUR_REJECT,reflvl, BB_AUTO_ATTEN);
initialize_sweep(timestamp);
bbQueryTraceInfo(devhandle, &swpsize_first, &binsize_first, &startfreq_first);
float* sweep_first_copy = new float[swpsize_first];
bbFetchTrace_32f(devhandle, swpsize_first, sweep_first_copy, sweep_first);// Get Second Sweep
configure_sweep(3.345e9, 5.29e9, 300e3, 300e3, 0.2, BB_RBW_SHAPE_FLATTOP, BB_NO_SPUR_REJECT,reflvl, BB_AUTO_ATTEN);
initialize_sweep(timestamp);
bbQueryTraceInfo(devhandle, &swpsize_second, &binsize_second, &startfreq_second);
float* sweep_second_copy = new float[swpsize_second];
bbFetchTrace_32f(devhandle, swpsize_second, sweep_second_copy, sweep_second);// Merge Sweep
memcpy(merged_sweep, sweep_first, swpsize_first*sizeof(float));
memcpy(merged_sweep+swpsize_first, sweep_second, swpsize_second*sizeof(float));delete [] sweep_first_copy;
delete [] sweep_second_copy;Also, I have attached the V-Tune’s Bottom-Up report. Actually, I could not figure out the problem. Maybe I am calling API functions in an improper way. I will be very happy if you could give an idea on that.
Thank you.
Attachments:
You must be logged in to view attached files.
AndrewModeratorHello blackmore90,
The Vtune report is probably not reporting symbols properly, as the bbGetTimebaseCorrection function appears in there erroneously, although I would expect both the log function and the fft functions to appear at the top of the list.
The API should be idle between bbFetchTrace function calls yes? The bbFetchTrace function will perform the full acquisition and processing necessary to get you the sweep requested. Very little processing takes place on the receiver. The receiver sends ADC IF samples to the PC for further processing, which includes potentially hundreds/thousands of FFTs, logarithmic, and arithmetic functions on the data. The processing is also spread out on several threads to finish the processing as quickly as possible. If you are continually requesting sweeps the API will be continually processing these sweeps as quickly as your computer will allow.
If you think you are seeing behavior outside of this, we can investigate further. I don’t see anything suspect in your code snippet.
Let me know if you have further questions.
Regards,
Andrew
blackmore90ParticipantThank you very much for your fast response Andrew.
I have decided to minimize the test complexity to eliminate potential effects of other sub-projects. I have created the following very simple CPP code:
#include <iostream>
#include “bb_api.h”int main()
{
int handle = 0;
bbStatus openStatus = bbOpenDevice(&handle);
bbConfigureAcquisition(handle, BB_AVERAGE, BB_LOG_SCALE);
bbConfigureCenterSpan(handle, 3.000005e9, 5.999991e9);
bbConfigureLevel(handle, -30, BB_AUTO_ATTEN);
bbConfigureGain(handle, BB_AUTO_GAIN);
bbConfigureSweepCoupling(handle, 5e3, 5e3, 1e-3, BB_RBW_SHAPE_FLATTOP, BB_NO_SPUR_REJECT);
bbConfigureProcUnits(handle, BB_POWER);
bbStatus initStatus = bbInitiate(handle, BB_SWEEPING, 0);
unsigned int sweepsize;
double binsize, startfreq;
bbQueryTraceInfo(handle, &sweepsize, &binsize, &startfreq);
float *min_swp = new float[sweepsize];
float *max_swp = new float[sweepsize];
for(int i = 0; i<1e6; i++){
bbStatus swpStatus = bbFetchTrace_32f(handle, sweepsize, min_swp, max_swp);
}
return 0;
}It results in about 18% CPU usage on my ASUS laptop. The system has i7-4700hq CPU, 16GB of RAM and the BB60C is connected to USB 3.0 port. Configuration is x64. This code uses about 8 threads and I have attached the thread display if you would like to check.
Actually, I am planning to port the code to another computer which will have Intel Atom series processor. My project will likely result in a huge CPU load on that PC.
Does that test really make sense in roughly measuring the CPU load?
Thank you.
Attachments:
You must be logged in to view attached files.
blackmore90ParticipantUpdate: I have run the project and the test applications on a laptop with intel atom cpu. It starts with 90% load and decreases gradually with time. About 10 minutes later it drops to about 30% but i get sweep data with very high latency after that time. Seems like Atom CPU cannot process the sweep data fast enough.
AndrewModeratorblackmore90,
There is no notion of falling behind or not being able to process sweep data fast enough for the BB60C. For any given sweep there is a fixed amount of processing that needs to take place, the Atom processor will simply take a bit longer to do this compared to others, which means that in your sweep loop test code, more time is spent processing per sweep so you see the CPU usage increase.
The CPU usage numbers you are seeing look normal, as you are simply in a busy loop by telling the receiver to sweep as quickly as possible. If you wanted to reduce power consumption or reduce CPU load you could introduce a delay between each sweep. This would average out your CPU usage to a smaller number.
Let me know if you have additional questions.
Regards,
Andrew
blackmore90ParticipantAndrew thank you very much, i have placed a sleep for 1 seconds and now the load is reduced to 6% on i7 and 30% on atom on average, significant downgrade.
- AuthorPosts
You must be logged in to reply to this topic.