Jeremy Quirke

There is also an issue where where the PRACH detector is significantly more sensitive than the PUSCH decoder which results in 3-6 RAR attempts typically before Msg3 is decoded with success. You can deduce it is Msg3 being misdecoded (and not the RAR) due to the timing (100ms - PRACH interval + mac contention timer vs 20ms PRACH interval). To partially compensate for this, will modify the RAR to increase the Msg3 power by the maximum (8dB): modify _mac.cc and change rar.tpc_command = LIBLTE_MAC_R...

There is also an issue where where the PRACH detector is significantly more sensitive than the PUSCH decoder which results in 3-6 RAR attempts typically before Msg3 is decoded with success. You can see it is Msg3 being misdecoded (and not the RAR) due to the timing (100ms - PRACH interval + mac contention timer vs 20ms PRACH interval). To partially compensate for this, will modify the RAR to increase the Msg3 power by the maximum (8dB): modify _mac.cc and change rar.tpc_command = LIBLTE_MAC_RAR_...

There is also an issue where where the PRACH detector is significantly more sensitive than the PUSCH decoder which results in 3-6 RAR attempts typically before Msg3 is decoded with success. You can see it is Msg3 being misdecoded due to the timing (100ms - PRACH interval + mac contention timer vs 20ms PRACH interval). To partially compensate for this, will modify the RAR to increase the Msg3 power by the maximum (8dB): modify _mac.cc and change rar.tpc_command = LIBLTE_MAC_RAR_TPC_COMMAND_8dB;

This is when the RNTI timer expires. You need to give us the trace frm 5 seconds earlier to see exactly what happened. Please provide the full trace from first detection of RACH preamble.

This is when the RNTI timer expires. You need to give us the trace frm 5 seconds earlier to see exactly what happened.

Make the following code change and let know how you go, the idea here is to restrict the non radio threads off the last core. (I'm taking a stab here w.r.t. to how linux numbers logical CPUs, but if the /proc/cpuinfo is anything to go by, this is correct). LTE_fdd_enb_msgq.cc pthread_getaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-1, &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-2, &af_mask); //add this line pthread_setaffinity_np(msgq->rx_thread,...

Make the following code change and let know how you go, the idea here is to restrict the non radio threads off the last core. LTE_fdd_enb_msgq.cc pthread_getaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-1, &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-2, &af_mask); //add this line pthread_setaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask);

Yeah still almost certainly CPU limited mate, what I'm guessing is the single biggest issue is because that CPU is running everything, the L1/L2 caches are getting cleared out between the math-heavy stuff (process_dl) which is hurting performance. Not to mention hardware interrupts and bottom halves (especially USB controller ones that copy buffers around) will have no choice but to be assigned to that single CPU which will also likely cause cache evictions etc. The fact that 1.4MHz is getting somewhere...