TFTP client file transfer much slower using MQX 5.0 compared to MQX 4.2

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

TFTP client file transfer much slower using MQX 5.0 compared to MQX 4.2

1,101 Views
larrydemuth
Contributor III

I have taken a project that was running with MQX 4.2 and switched it over to MQX 5.0, but I run into a problem with the TFTP client (could be a UDP issue and not TFTP). When transferring a file, it takes MUCH longer (almost a minute to transfer 1254 blocks) using MQX 5.0. I see about 40mS between receiving the block and sending the acknowledgement on wireshark, and its consistent for all blocks.

When I use MQX 4.2 the same file takes about 5 seconds, and see less than 1 mS between the block and sending the acknowledgement.

What is MQX 5.0 doing different to create such a large delay between receiving the block and sending the Ack?

My user code is identical (with the exception of a slightly different parameter struct for MQX 5.0 to deal with IPv6), so the only difference is in MQX.

0 Kudos
3 Replies

1,097 Views
larrydemuth
Contributor III

UPDATE: I see a similar issue with the HTTP server. With MQX 5.0 it takes about 70mS between the GET request and the response. In MQX 4.2 it takes less than 1mS for the same response.

0 Kudos

1,080 Views
larrydemuth
Contributor III

Never mind. I had a delay for debugging in the tcpip task that never got removed. 

FYI NXP, below is the note I had in the function, and where the delay was. I would guess the original problem is still around...:

 while (1)
{
TCPIP_EVENT_PTR queue = TCPIP_Event_head;

tcpip_msg = (TCPIP_MESSAGE_PTR)RTCS_msgq_receive(tcpip_qid, timeout, RTCS_data_ptr->TCPIP_msg_pool);

if (tcpip_msg)
{
/*the time delay seems to fix an issue with the Ethernet sometimes not responding, or locking up.
* Sometimes the ethernet would just quit responding to anything (ping, arp, etc...).
* Sometimes the macnet_context_ptr->RX_BUFFERS pointer in the would get corrupted for some reason. This would cause a hard fault!!
* The fault location was in macnet_receive.c, MACNET_add_buffers_to_rx_ring function.
* I dont think this is an ideal fix, but it appears to work for now.
*/
// _time_delay(1);
if (NULL != tcpip_msg->COMMAND)
{
tcpip_msg->COMMAND(tcpip_msg->DATA);
}
RTCS_msg_free(tcpip_msg);
}

0 Kudos

1,075 Views
Doug_EmbeddedAc
Senior Contributor I

Thank you for the update. I'll pass on your observation.

Regards,

Doug

0 Kudos