[srslte-users] pdsch_enodeb example and different traffic patterns

[Ismael Gomez]

Hi andres,

That is a cpu issue. Please make sure that:
- cmake detected volk and simd/avx
- the cpu is clocked to the maximum and energy control, or clock governor
is disabled and fixed to max
- you dont have any other background process running
- usrp detected usb3

On Wed, 11 May 2016, 09:46 Andrés García Saavedra, <
andres.garcia.saavedra at gmail.com> wrote:

> Hi SRSers,
>
> I am trying to modify the pdsch_enodeb example to generate different
> traffic patterns (rather than 100% data or getting that data from a socket).
>
> The modification seemed pretty trivial: essentially tuning the bool
> send_data variable at pdsch_enodeb.c true/false for every subframe
> according to a pattern. However I am having performance issues at the
> receiver's side.
>
> As a use case, I am testing the following simple pattern based on a
> variable int duty_cycle = {0,100}:
> - I send data (send_data=true) for a number of subframes = duty_cycle;
> - then, I do not send data (send_data=false) for a number of subframes =
> 100-duty_cycle.
>
> For small MCS idx, everything works as expected, e.g. for MCS idx = 0 at
> the UE I receive TBS*duty_cycle/100 kbps throughput (using iperf's TCP
> server) -- and I see ~ (100-duty_cycle) PDCCH-Miss and low PDSCH-BLER.
>
> However, for larger MCS idx (e.g. 17), the UE pops out many "*No space
> for SSS/CP detection. Realigning frame*" messages and much lower
> throughput than expected (and overly large PDCCH-Misses) when duty_cycle is
> < 100 (everything goes great when send_data is always true at the eNB).
>
> I've checked that all reference signals are properly sent regardless if
> send_data is false or true, so I am not sure what the problem may be. Any
> pointer?
>
> Thanks,
> Andres
>
>
>
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20160511/0ea776e2/attachment.htm>