Using a USRP

[Kevin McDermott]

Hello gentlemen,

 

I am trying to run OpenLTE through a N210 with SBX daughterboard right now.  I ran the osld_tx_usrp.app config but had an error.

 

It let me load and initiate. But then when I had it run it immediately gave me this:

 

“module resmapp returned error from work() function. Trying a clean stop UUUUUUUWaveform ./osld_tx_usrp.app was cleanly removed…”

 

What is the next move in this case or how to I rectify this issue? Has anyone experienced this?

 

Thank you for your time,

Kevin McDermott

 

[Ismael Gomez]

Hi, 

The output "UUUUUUU" comes from the UHD driver and means that data is not arriving to the USRP in real-time.

- Are you running aloe with root/sudo permission? (you need this to run in real-time)

- What CPU(s) do you have? Are the CPUs multi-threaded?

- How does your config file looks like? Which is your time slot duration? 

If you want to run ALOE in a multicore processor, first make sure you are using physical cores and not threads. Second, unless your CPU is powerful enough, you may need to use a Xenomai hard real-time OS to be able to meet the real-time deadlines. 

Hope this helps,

Kind regards,

Ismael

2013/8/15 Kevin McDermott <kevi...@hume.ictas.vt.edu>

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/006b01ce99ec%2483661500%248a323f00%24%40hume.ictas.vt.edu.
For more options, visit https://groups.google.com/groups/opt_out.

[Kevin McDermott]

Guys,

 

I am running ALOE with sudo permission as far as I know.

My processor is an intel i7 4770, plenty of processing cores.  Left the config file at 1 core though along with the suggested time slot for USRP which is 1ms (I believe?)

Since the timeslot was already 1ms I did not alter the config file in any way. Let me know if you want me to attach it or anything like that.

 

Thoughts?

 

Thanks,

Kevin

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/CAAC4g6sckzzn-Wrku_nie%3D-hWvrfJBhMmfYyvih_EwirT0v-4g%40mail.gmail.com.

[Ismael Gomez]

OK, let's try the following: 

1) Make sure the CPU frequency is fixed to its maximum (i.e. disable dynamic frequency scaling). I use cpufreq-indicator in ubuntu to do this

2) If you run ALOE from the x-windows, many devices are willing to access the CPU and may interrupt it, producing real-time faults. One way to limit this interference...

   2a) In the app_dl/config file, edit cores="1"  --> cores="2," (don't forget the comma!!). This is telling aloe to use 1 core, but core idx 2 rather than core idx 0 (default). Because most of the kernel threads run on core 0, this will avoid the interference to some extend. Also, you may need to choose "3," or "4,", depending on your processor architecture (see 'cat /proc/cpuinfo'). For instance, I have a 4-core processor (i5), which in fact is a 2-core, but each core has 2 threads (threads are like cores but with shared execution units). When it comes to real-time, nothing can be shared. Then, in my setup I would use "cores=2," because core idx 0 and 1 belong to the first core.

   2b) In the app_dl/config file, set thread_sync_on_finish=true; 

3) Other useful things: 

   3a) start linux only with the minimal services/kernel modules (this includes x windows too)

   3b) disable hyperthreading

Once the waveform is running, type 'e' <enter> in the console to see how much of your processor is being used. You may see that no more than 50-60% is actually being used. If you try to increase the load, you'll have rtfaults. The reason is that aloe is a *HARD* real-time system. As such, the execution time of all waveform modules *must* be completely deterministic. Any variation has fatal consequences (i.e. application stops working). The small variance inherent in common linux is absorbed by this unused 40% processing time. 

Aloe relies on a hard real-time system, but linux is not a hard real-time system. Drivers or kernel threads interrupt the processor producing variances in the execution time. You may solve with suggestions 2(a,b) and 3(a,b). The best approach, however, is to install a hard real-time system. Aloe supports xenomai, which is reasonably easy to install. With xenomai, you can get up to 95% of CPU usage and still get end-to-end deterministic latency. I would suggest you first try my initial suggestions, though. 

please let me know if I made myself clear,

Kind regards,

Ismael

2013/8/16 Kevin McDermott <kevi...@hume.ictas.vt.edu>

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/003501ce9a8f%24d0785170%247168f450%24%40hume.ictas.vt.edu.

[Vuk Marojevic]

Thank you Ismael for the quick and informative response and the numerous suggestions.
Vuk

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/CAAC4g6uVyzxHzgtJYQZ01EfFHrs%3Dz_xFiGY%2B8VEbFXHQJ%2BxbZA%40mail.gmail.com.

[Kevin McDermott]

Guys,

 

First off, Ismael, thank you for getting back so quickly with such a great response too. I didn’t get lost anywhere in there.

 

HOWEVER, new problems have arisen.  I have been alternating the number of cores as well with/without hyperthreading (dynamic scaling is off too); thread_sync_on_finish=true has been set the whole time, I have not switched it back to “false”.  Regardless of the setup ALOE seems to be making Core 4 on my CPU be 100% load consistently.  Which isn’t a bad thing (yet?). 

 

So now instead of resmap and 6x “U”, I get a constant stream of “U”s on my screen.  Then I proceed to hit ‘s’ to stop the program in the terminal, which it does and clears the file.  But, then I will proceed to change the number of cores  in app_dl/config and try to l / i / r again, but this will crash the terminal every time and my Core4 will still be at 100% load.  Do I have to perform a “make” command in build everytime I alter the config file? OR should I close the terminal everytime I stop the transmission? Should I exit ALOE and then run  the compile again  (tx_usrp_app)? 

 

Thank you again for all this help,

Kevin McDermott

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/CANjVH%3DiHCYvPfs_CWsLwGs%2B2fF_0UuyDAgRQaoSu6uV1sFmtMQ%40mail.gmail.com.

[Ismael Gomez]

Hi,

no, you don't need to recompile when you change the config file. 

have you tried to send the samples to a file instead of the usrp? Maybe there are some differences between your UHD driver and mine. 

You can do this loading the waveform osld_tx_file.app (just follow the instructions in the github wiki site: https://github.com/flexnets/aloe/wiki#executing-the-osld-waveform). Also, make sure you use one core only. 

2013/8/16 Kevin McDermott <kevi...@hume.ictas.vt.edu>

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/001301ce9abd%249d14de10%24d73e9a30%24%40hume.ictas.vt.edu.

[Kevin McDermott]

Ismael,

 

When using one core I set the config file back to ‘ cores=”1”;   ? is comma needed in this case still?

 

Also when sending the samples to the file I can run the transmitter, but for some reason the receiver has stopped working for me.  It used to work just fine. But now after I exit ALOE (after running the TX) and then run the RX I get this:

“Error loading waveform. Not Enough resources [_run_main():122:] loading waveform “

 

I am not sure why this is happening now, and the USRP is still outputting all “U”s.

 

Sorry for the hassle here. It would be a lot more streamlined if I could get Vuk to join me in the office, but restricted access is preventing that.

 

Thanks again,
Kevin McDermott

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/CAAC4g6voD5-doDv1Koq2amC3wNvnR3C0H6s32CocRNp43jpsSw%40mail.gmail.com.

[Ismael Gomez]

2013/8/19 Kevin McDermott <kevi...@hume.ictas.vt.edu>

Ismael,

 

When using one core I set the config file back to ‘ cores=”1”;   ? is comma needed in this case still?

"1," (with comma): uses core idx 1

"1" (without comma): uses core idx 0

If you run at 1 ms of timeslot, it is better to use a core idx different than 0. Moreover, it's better if you set it to core idx 2 or 3 (that means "2," or "3," (with comma)) becuase core idx 1 and 0 are probably the same physical core. 

 

 

Also when sending the samples to the file I can run the transmitter, but for some reason the receiver has stopped working for me.  It used to work just fine. But now after I exit ALOE (after running the TX) and then run the RX I get this:

“Error loading waveform. Not Enough resources [_run_main():122:] loading waveform “

Each module in the waveform ".app" file defines a processing requirements, in microseconds. The processing capacity of your platform is the time slot multiplied by the number of cores. This message indicates that the platform has not enough resources (i.e. processing time) for running the waveform in real-time. 

In my processor (2.6 GHz), the receiver needs two cores, because the total execution time is 1.6 ms while the execution period is 1 ms. 

Thus, if you want to run the receiver at 1 ms of time slot, you should either use 2 cores, or update the model for your platform (vuk could explain you more about this), or you could increase the time slot (you can if you read the samples from the file).     

 

 

I am not sure why this is happening now, and the USRP is still outputting all “U”s.

 

Yes, I just thought that the reason for that is that the USRP sampling frequency is not exactly 1.92 MHz (is a little bit higher), and since the waveform sends 1920 samples each time slot, the time slot is slightly shorter than that. 

Try to do the following: 

- When you run the osld_tx_usrp.app, read the sampling rate from the console output and compute the time slot (i.e. 1920/Sr, with Sr the sampling rate). 

- I think it was something like 930 us. Then go to the config file and set the time slot to 930 us. 

You may see that now it works but after a while you see "U"s again. Then, you can also try the following:

- Edit the osld_tx_usrp.app file, module "sink", set "blocking=1"

- In the config file, set the timeslot to a number smaller than the time slot (e.g. if timeslot is 930, set to 870)

- In the config file, make sure the thread_sync_on_finish=true;

(The combination of thread sync and blocking=1 makes the timeslot to be synchronized to the USRP) 

 

Sorry for the hassle here. It would be a lot more streamlined if I could get Vuk to join me in the office, but restricted access is preventing that.

 

Don't worry please. I'm happy to help. 

 

Thanks again,
Kevin McDermott

Kind regards,

Ismael

 

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/004701ce9d0a%24922bc960%24b6835c20%24%40hume.ictas.vt.edu.

[Kevin McDermott]

Ismael,

 

Very helpful feedback, I think, as the U’s have stopped and I assume the transmitter is just running or the blocking=1 has prevented the constant stream of output.  So if the tx_usrp is working, do I have to get another usrp to run the rx_usrp simultaneously in order to see some packets?  Cuz running the rx_usrp just ouputs “running”.

 

Thank you,

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/CAAC4g6vGfHYCc%2Bv5mx19zcm9MYZZ6rrNxy9qE3CBF54oe%2Bz8Pw%40mail.gmail.com.

[Vuk Marojevic]

If you are setting up a downlink transmitter (eNodeB) and receiver (UE) with over-the-air transmission you should use two PCs and two USRPs. One PC-USRP would act as the eNodeB and the other as the user equipment or UE. Each PC runs ALOE and the corresponding waveform: TX or RX.
A single USRP may transmit on the downlink and receive on the uplink, but you'd need a pair of nodes (processor+RF) for establishing a real wireless link, either downlink, uplink, or both.
Does this sound reasonable?
Vuk

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/001c01ce9ddc%241bce6480%24536b2d80%24%40hume.ictas.vt.edu.

[Vuk Marojevic]

Kevin,

following up on our discussion: If you have a powerful PC with multiple cores, you could try running two instances of ALOE, but be careful to assign them to different physical cores, not threads. On one instance you could launch the transmitter, on the other the receiver. Hope that the computing capacity will suffice. 

For setting up the radio link you'd need to check how to operate 2 USRPs with two network cards on the same PC. Does the uhd drive support this? Other fora may provide the answer to that.

Would be useful information, not just for this project, but for testbeds like VT-CORNET, etc. Please let us know if you find some interesting information about this.

Thanks,

Vuk