ARM UDP Receive Buffer

[tonykcrane]

Hello all,

I'm seeing some odd behavior that really looks like buffering but I'd like to make sure.

Test Setup:

Origin LM3S8962: Timed Loop (1KHz timer @ 1ms dt) that broadcasts a 1-byte UDP packet and toggles an output line (Monitored by scope)

Destination LM3S8962: While Loop calling UDP Receive with 0ms Timeout, toggles its output line when any packet is received (Also monitored by scope)

What I see:

Origin toggles its output line every 1ms +/- 3uS (as expected)

Destination goes in 2 phaes: A) toggles its output line with a pulse time of 160uS (both positive and negative) for 60 transitions, then sits quiescent for around 58ms.

This looks like buffering to me.  I get 16/17 of such bursts per second, each followed by a spasm of riotous inactivity.

Is there any way to disable the buffering, or at least reduce the duration/size of the buffer?

Thanks,

Tony

[Stephen_S.]

Hi Tony,

Have you tried setting the timeout of the UDP receive to something like 10 ms instead of 0 ms? It could be that the loop is running too fast and starving the network driver thread, which could cause the network driver to get a backlog of packets all at once.

See if adjusting that timeout value helps with the behavior you are seeing.

Regards,

Stephen S.

[tonykcrane]

Stephen,

Thanks for the reply!

I've tried passing a timeout of 0, 1, 10, 50, and 100ms.  None of them seem to make any difference in the behavior.

A longer timeout might have effect, but I've currently got packets being pumped into it every ~1ms, verified by WireShark.  (I can attach that .pcap file if it's really necessary..)

The VI really is quite simple, so unless there's something else going on in LabVIEW Land, I'm not sure how to chase this problem out.

Snippet attached.

Thanks!

Tony

EDIT:  Hmm, was hoping snippet would show in-line, but I must not have done something right.. Would that require some sort of image link? (To the png stored on some image hosting website or such..)

Message Edited by tonykcrane on 11-11-2009 12:38 PM

[tonykcrane]

One week later and still no clues?

Would it assist matters if this were a formal assistance request?

Thanks,

Tony

[Stephen_S.]

Hi Tony,

I am sorry about the delay getting back to you on this issue. I am in the process of looking into this issue.

It could help to have the WireShark log as well, so if you could attach that I would appreciate it.

I will let you know when I have more information on this issue.

Regards,

Stephen S.

[tonykcrane]

As requested, the WireShark capture is attached.

Thanks,

Tony

[Stephen_S.]

Hi Tony,

Sorry to keep you waiting, and I hope you had a good holiday. I am discussing this issue with our R&D department to see if there is something you are missing. I will let you know when I have more information for you, or something else to try.

Regards,

Stephen S.

[tonykcrane]

Stephen,

My Thanksgiving was wonderful.  I had a great time celebrating with friends and family, and I hope yours was just as enjoyable.

Thanks for keeping this moving.  I've tried digging deeper into the source code available under the Keil/LM3S8962 distribution, but am beginning to suspect that the code in question is a part of the RTOS or the LabVIEW scheduler.  I can see where the code has been customized for the LM3S8962 - the intervening layers, etc - but nothing that looks like it might be buffering.

RLARM_CCGTcpUdpSupport.c(631): UDPConnRead()

RLARM_TCPWrapper.c(554): RTX_udp_recv()

RLARM_TCPWrapper.c(601): RTX_udp_rx_bytes()

Either that or there is some sort of configuration that is done during boot or UDP Socket Open that sets the buffering options, etc.  (Wich I have not yet located.)

Thanks again,

Tony K.

[Stephen_S.]

Hi Tony,

I am in and out of the office this week, so I am working with another engineer as well, and we wanted to know if you could post all of your code, in addition to the snippet that you already attached, so that we are sure that we are not missing anything. We will still be investigating the issue on our end as well.

Thanks,

Stephen S.

[tonykcrane]

Stephen,

The entire program, ZIPped is around 15MB.  I'll post it in several files.

Since ZIP does not support spanning archives, these are actually RAR files.

Rename them from *.zip to *.rar and then they'll extract with WinRAR from http://www.rarlab.com/download.htm

Thanks,

Tony

Edit: They are not posted as RAR files since the forum rejects that file extension.

Message Edited by tonykcrane on 12-01-2009 03:35 PM