[srslte-users] pdsch_enodeb example and different traffic patterns

[Andrés García Saavedra]

Thanks Ismael,

it was the clock governor indeed.

Andres

On Wed, May 11, 2016 at 12:31 PM, Ismael Gomez <
ismael.gomez at softwareradiosystems.com> wrote:

> 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/16c33886/attachment.htm>