strange behaviour on evmc6678 while receiving UDP packets

Hello,

I have looped in the NDK expert asking for some suggestions.

In the meanwhile, is there any other task running on the DSP ?Also any other network traffic ?

About the dropped packets, there are some network statistics information in the C6678 device(at L2, L3 and L4). They might show any error conditions. Please check :

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/205199/729134.aspx#729134

Hope this help.

Hi Varada,

Thanks for the quick response. There is no ethernet traffic nor another task running (it is the original helloworld_evmc6678l application). As far as I understand, I should append the contents of your gel file (3583.cpsw_stats_print.gel)  into my evmc6678l.gel to see the network statisrtics right? What else should I do because that did not help at all.

thanks in advance

Ozhan

Hi,

Just a suggestion: Is platform_write() sending output to both serial and stdio on CCS console?

Note that, if the output to CCS console is enabled (as it is in the original helloWorld example),the C6678 is suspended on an hidden break point used to manage the I/O to CCS (it is very slow). This could generate strange behaviour. Try to enable output to uart only or remove it completly: for instance you can write a statistic summary every 1000 message.

Hi Alberto,

I have also tried that out. I observed the incoming frame counter (first 4 bytes on the udp payload set by the PC software ) and count the times when a packet has been lost.

Then I only Platform_print when the dropped packet  is 100.

Ozhan,

 When you halt the program on DSP and PC, can you use the gel file to print out the statistics. We are wondering if there were an RX errors, causing packet drop.

 Hope you have tried all the suggestions in the  document spru523h.pdf, section 3.5, sub-section named “UDP application drops packets on recv() calls”

Hi Valada,

I guess I am doing this gel file issue wrong. I appended your gel file content into my gel file for evmc6678, run the program and halted but no data avaible in console?

Can you tell me what exactly I should do?

I did the issues on spru523h.pdf, section 3.5 but no help at all.

regards..

Ozhan

Ozhan,

About the usage of gel file, no need to append to existing gel file. Please load this gel file separately in CCS.

Then the functions (including options to print stats) will be available under the "scripts".

Let us know.

Hi Varada,

I got the network statistics and tries to load the screen snapshot but fail everytime. Anyway here are the numbers:

UDP:

RcvTotal:9972

RcvBadSum: 3

IPS:

Total:10026

BadLen:54

Delivered:9972

Hi Varada,

My plan is to kick the real data into c6678 via UDP/IP weher real data is coming form a distant data source. What do you think, am I on the wrong track? Shoud l I use some other ways to do it (like hyperlink etc )?

best regards

Ozhan

Hi Ozhan,

Looking at the UDP statistics, seems like you only have few packets (54 out of 10026) that have badLen.  Apart from that not much can be derived. Were you able to run the .gel file, which  will print statistics for the Layer 2.

 Have you tried halting your program and printing the statistics using the ‘gel’ file.

 I would suggest to print the statistics using gel, before you start executing the DSP program also, just for reference start values.

 I believe we can resolve the communication issue over the network, before we evaluate other means like Hyperlink.

Hi again

Yes I was able to run the gel file. I will also record the statistics before I run the program and let you know. I tried to append the screen shot of the gel file output but it is nearly impossible with your web page..

best regards

Ozhan

About the statistics, glad you can run the gel file. Hope you can copy-paste the console output, on the forum window.

 One more quick question :  Is there a switch/router between the EVM and the PC, in your set-up ?

Hi Varada,

First of all, there no switch/router or etc between  PC and evmc6678 board. The following is the statistics before I run the program:

/**********************************************************************************************

C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: Ethernet Statistics A.
C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: RX Good Frames ................ 0x0x00000000
C66xx_0: GEL Output: RX Broadcast Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Multicast Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: RX CRC Errors ................. 0x0x00000000
C66xx_0: GEL Output: RX Align/Code Errors .......... 0x0x00000000
C66xx_0: GEL Output: RX Oversized Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Jabber Frames .............. 0x0x00000000
C66xx_0: GEL Output: RX Undersized Frames .......... 0x0x00000000
C66xx_0: GEL Output: RX Fragments .................. 0x0x00000000
C66xx_0: GEL Output: RX Octets ..................... 0x0x00000000
C66xx_0: GEL Output: TX Good Frames ................ 0x0x0000002B
C66xx_0: GEL Output: TX Broadcast Frames ........... 0x0x00000001
C66xx_0: GEL Output: TX Multicast Frames ........... 0x0x0000002A
C66xx_0: GEL Output: TX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: TX Deferred Frames ............ 0x0x00000000
C66xx_0: GEL Output: TX Collision Frames ........... 0x0x00000000
C66xx_0: GEL Output: TX Single Collision Frames .... 0x0x00000000
C66xx_0: GEL Output: TX Multiple Collision Frames .. 0x0x00000000
C66xx_0: GEL Output: TX Excessive Collision Frames . 0x0x00000000
C66xx_0: GEL Output: TX Late Collisions ............ 0x0x00000000
C66xx_0: GEL Output: TX Underrun ................... 0x0x00000000
C66xx_0: GEL Output: TX Carrier Sense Errors ....... 0x0x00000000
C66xx_0: GEL Output: TX Octets ..................... 0x0x00005090
C66xx_0: GEL Output: 64 Byte Octet Frames .......... 0x0x00000000
C66xx_0: GEL Output: 65 to 127 Byte Octet Frames ... 0x0x00000000
C66xx_0: GEL Output: 128 to 255 Byte Octet Frames .. 0x0x00000006
C66xx_0: GEL Output: 256 to 511 Byte Octet Frames .. 0x0x0000000A
C66xx_0: GEL Output: 512 to 1024 Byte Octet Frames . 0x0x0000001B
C66xx_0: GEL Output: Over   1024 Byte Octet Frames . 0x0x00000000
C66xx_0: GEL Output: Net Octets .................... 0x0x00005090
C66xx_0: GEL Output: RX Start of Frame Overruns .... 0x0x00000000
C66xx_0: GEL Output: RX Middle of Frame Overruns ... 0x0x00000000
C66xx_0: GEL Output: RX DMA Overruns ............... 0x0x00000000
C66xx_0: GEL Output: -----------------------------------------------

C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: Ethernet Statistics B.
C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: RX Good Frames ................ 0x0x0000002B
C66xx_0: GEL Output: RX Broadcast Frames ........... 0x0x00000001
C66xx_0: GEL Output: RX Multicast Frames ........... 0x0x0000002A
C66xx_0: GEL Output: RX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: RX CRC Errors ................. 0x0x00000000
C66xx_0: GEL Output: RX Align/Code Errors .......... 0x0x00000000
C66xx_0: GEL Output: RX Oversized Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Jabber Frames .............. 0x0x00000000
C66xx_0: GEL Output: RX Undersized Frames .......... 0x0x00000000
C66xx_0: GEL Output: RX Fragments .................. 0x0x00000000
C66xx_0: GEL Output: RX Octets ..................... 0x0x00005090
C66xx_0: GEL Output: TX Good Frames ................ 0x0x0000002B
C66xx_0: GEL Output: TX Broadcast Frames ........... 0x0x00000001
C66xx_0: GEL Output: TX Multicast Frames ........... 0x0x0000002A
C66xx_0: GEL Output: TX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: TX Deferred Frames ............ 0x0x00000000
C66xx_0: GEL Output: TX Collision Frames ........... 0x0x00000000
C66xx_0: GEL Output: TX Single Collision Frames .... 0x0x00000000
C66xx_0: GEL Output: TX Multiple Collision Frames .. 0x0x00000000
C66xx_0: GEL Output: TX Excessive Collision Frames . 0x0x00000000
C66xx_0: GEL Output: TX Late Collisions ............ 0x0x00000000
C66xx_0: GEL Output: TX Underrun ................... 0x0x00000000
C66xx_0: GEL Output: TX Carrier Sense Errors ....... 0x0x00000000
C66xx_0: GEL Output: TX Octets ..................... 0x0x00005090
C66xx_0: GEL Output: 64 Byte Octet Frames .......... 0x0x00000000
C66xx_0: GEL Output: 65 to 127 Byte Octet Frames ... 0x0x00000000
C66xx_0: GEL Output: 128 to 255 Byte Octet Frames .. 0x0x0000000C
C66xx_0: GEL Output: 256 to 511 Byte Octet Frames .. 0x0x00000014
C66xx_0: GEL Output: 512 to 1024 Byte Octet Frames . 0x0x00000036
C66xx_0: GEL Output: Over   1024 Byte Octet Frames . 0x0x00000000
C66xx_0: GEL Output: Net Octets .................... 0x0x0000A120
C66xx_0: GEL Output: RX Start of Frame Overruns .... 0x0x00000000
C66xx_0: GEL Output: RX Middle of Frame Overruns ... 0x0x00000000
C66xx_0: GEL Output: RX DMA Overruns ............... 0x0x00000000
C66xx_0: GEL Output: -----------------------------------------------

/**********************************************************************************************

The following is the one after I run and halt the system:

C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: Ethernet Statistics A.
C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: RX Good Frames ................ 0x0x00000007
C66xx_0: GEL Output: RX Broadcast Frames ........... 0x0x00000001
C66xx_0: GEL Output: RX Multicast Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: RX CRC Errors ................. 0x0x00000000
C66xx_0: GEL Output: RX Align/Code Errors .......... 0x0x00000000
C66xx_0: GEL Output: RX Oversized Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Jabber Frames .............. 0x0x00000000
C66xx_0: GEL Output: RX Undersized Frames .......... 0x0x00000000
C66xx_0: GEL Output: RX Fragments .................. 0x0x00000000
C66xx_0: GEL Output: RX Octets ..................... 0x0x000001DC
C66xx_0: GEL Output: TX Good Frames ................ 0x0x0000043C
C66xx_0: GEL Output: TX Broadcast Frames ........... 0x0x0000000D
C66xx_0: GEL Output: TX Multicast Frames ........... 0x0x0000002B
C66xx_0: GEL Output: TX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: TX Deferred Frames ............ 0x0x00000000
C66xx_0: GEL Output: TX Collision Frames ........... 0x0x00000000
C66xx_0: GEL Output: TX Single Collision Frames .... 0x0x00000000
C66xx_0: GEL Output: TX Multiple Collision Frames .. 0x0x00000000
C66xx_0: GEL Output: TX Excessive Collision Frames . 0x0x00000000
C66xx_0: GEL Output: TX Late Collisions ............ 0x0x00000000
C66xx_0: GEL Output: TX Underrun ................... 0x0x00000000
C66xx_0: GEL Output: TX Carrier Sense Errors ....... 0x0x00000000
C66xx_0: GEL Output: TX Octets ..................... 0x0x001793DD
C66xx_0: GEL Output: 64 Byte Octet Frames .......... 0x0x00000006
C66xx_0: GEL Output: 65 to 127 Byte Octet Frames ... 0x0x00000010
C66xx_0: GEL Output: 128 to 255 Byte Octet Frames .. 0x0x00000007
C66xx_0: GEL Output: 256 to 511 Byte Octet Frames .. 0x0x0000000A
C66xx_0: GEL Output: 512 to 1024 Byte Octet Frames . 0x0x0000001B
C66xx_0: GEL Output: Over   1024 Byte Octet Frames . 0x0x00000401
C66xx_0: GEL Output: Net Octets .................... 0x0x001795B9
C66xx_0: GEL Output: RX Start of Frame Overruns .... 0x0x00000000
C66xx_0: GEL Output: RX Middle of Frame Overruns ... 0x0x00000000
C66xx_0: GEL Output: RX DMA Overruns ............... 0x0x00000000
C66xx_0: GEL Output: -----------------------------------------------

C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: Ethernet Statistics B.
C66xx_0: GEL Output: -----------------------------------------------
C66xx_0: GEL Output: RX Good Frames ................ 0x0x0000043C
C66xx_0: GEL Output: RX Broadcast Frames ........... 0x0x0000000D
C66xx_0: GEL Output: RX Multicast Frames ........... 0x0x0000002B
C66xx_0: GEL Output: RX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: RX CRC Errors ................. 0x0x00000000
C66xx_0: GEL Output: RX Align/Code Errors .......... 0x0x00000000
C66xx_0: GEL Output: RX Oversized Frames ........... 0x0x00000000
C66xx_0: GEL Output: RX Jabber Frames .............. 0x0x00000000
C66xx_0: GEL Output: RX Undersized Frames .......... 0x0x00000000
C66xx_0: GEL Output: RX Fragments .................. 0x0x00000000
C66xx_0: GEL Output: RX Octets ..................... 0x0x001793DD
C66xx_0: GEL Output: TX Good Frames ................ 0x0x00000033
C66xx_0: GEL Output: TX Broadcast Frames ........... 0x0x00000002
C66xx_0: GEL Output: TX Multicast Frames ........... 0x0x0000002B
C66xx_0: GEL Output: TX Pause Frames ............... 0x0x00000000
C66xx_0: GEL Output: TX Deferred Frames ............ 0x0x00000000
C66xx_0: GEL Output: TX Collision Frames ........... 0x0x00000000
C66xx_0: GEL Output: TX Single Collision Frames .... 0x0x00000000
C66xx_0: GEL Output: TX Multiple Collision Frames .. 0x0x00000000
C66xx_0: GEL Output: TX Excessive Collision Frames . 0x0x00000000
C66xx_0: GEL Output: TX Late Collisions ............ 0x0x00000000
C66xx_0: GEL Output: TX Underrun ................... 0x0x00000000
C66xx_0: GEL Output: TX Carrier Sense Errors ....... 0x0x00000000
C66xx_0: GEL Output: TX Octets ..................... 0x0x0000530B
C66xx_0: GEL Output: 64 Byte Octet Frames .......... 0x0x00000006
C66xx_0: GEL Output: 65 to 127 Byte Octet Frames ... 0x0x00000010
C66xx_0: GEL Output: 128 to 255 Byte Octet Frames .. 0x0x0000000E
C66xx_0: GEL Output: 256 to 511 Byte Octet Frames .. 0x0x00000014
C66xx_0: GEL Output: 512 to 1024 Byte Octet Frames . 0x0x00000036
C66xx_0: GEL Output: Over   1024 Byte Octet Frames . 0x0x00000401
C66xx_0: GEL Output: Net Octets .................... 0x0x0017E6E8
C66xx_0: GEL Output: RX Start of Frame Overruns .... 0x0x00000000
C66xx_0: GEL Output: RX Middle of Frame Overruns ... 0x0x00000000
C66xx_0: GEL Output: RX DMA Overruns ............... 0x0x00000000
C66xx_0: GEL Output: -----------------------------------------------

best regards

Ozhan

Seems like there are no apparent L2 errors that should cause you to drop packets.

Are you still dropping 4% of packets ?

If so – theres one other option is to increase the number of packet buffers in the NDK stack. That may require you to rebuild the stack.

I will get the instructions for the same.

Hi Varada

Yes I still lose %4. Can you also instruct me how to enable jumbo frames? I think this will also add good improvement right along with what you suggest.

I look forward getting the instructions..

best regards

Ozhan

To rebuild NDK : here are the instructions,

http://processors.wiki.ti.com/index.php/Rebuilding_The_NDK_Core_Using_Gmake

 FYI : M3 is the name of a different processor core . For C6678, PKT_NUM_FRAMEBUF, by default is 192. You may try to increase it to 256.

Quoting from the expert :

In order to redefine the sizes of those buffers, he needs to throw some compiler –D options.  There’s an example of how to do this already in the tree in the file “ti/ndk/stack/package.bld” for the M3 core.  The M3 is built with smaller buffer sizes.

See these lines in package.bld for the stack:

/*

*       M3 Library Build Options

*

* NOTE: currently only IPv4 M3 libraries have reduced sizes.

*

* Building for M3 requires reduced values for the following sizes,

* normally defined in pbm.c and mem_bios6.c:

*

*     PKT_NUM_FRAMEBUF

*     PKT_SIZE_FRAMEBUF

*

* By defining _NDK_MIN_PBM_BUFS, this allows

* these sizes to be redefined elsewhere.  For M3, we'll redefine

* them here, in the compiler options variable 'copts', then pass this for all

* IPv4 library versions for M3:

*/

var m3PbmCopts = " -D_NDK_MIN_PBM_BUFS" +

                 " -DPKT_NUM_FRAMEBUF=16" +

                 " -DPKT_SIZE_FRAMEBUF=1552";

He would need to put ‘m3PbmCopts’ into the options for the stack library for his target and change the size values as desired, then rebuild using the steps on the wiki page .

Hi Varada,

As far as I understand I will change the PKT_NUM_FRAMEBUF parameter in file "pbm_data.c" and then recompile the NDK right?

I will also appreciate if you can instruct me how to enable jumbo-frames inC6678

best regards

Ozhan

Hi again,

If what I described in my last post as done is correct then I will report that nothing has changed cause I still lose %4 of UDP packages..

best regards

Ozhan

Hi Ozhan,

Hmmm …. You still seem to have issues. I am getting the NDK expert to help you.

In the meanwhile, on the packet capture tool like ‘wireshark’ do you see any spurious packets generated by PC that may be causing the frames to be dropped. Can you also try to increase the priority of the daemon task, if not already done so.

Jumbo frames are not supported in the lower layer driver of ‘nimu’. There is an existing request and will be supported in future driver releases.

Hi Varada,

I checked out the data transmitted by pc via wireshark. There are two issues:

1. UDP checksum bad

2. Very rarely, PC sends data in RELOAD protocol 

any comment?

best regards

Ozhan

Hi Varada

When do you think NDK expert will contact me to resolve my issue? I appreciate if that can be quick cause I need to solve this problem and proceed as I have much to do next.

best regards

Ozhan

Hi Ozhan,

Varada is no longer with TI but I can try to help you.

First off, I wanted to mention that the MCSDK comes with a demo application that contains some benchmark functionality built into it.  Have you tried that?  If not, can you please give it a try and see if you also see similar packet loss with that demo?  You can see info about it in the MCSDK User's Guide section "MCSDK HUA Guide" and then look for "Network Throughput Test/Benchmark".

Next, have you tried the NDK client example application yet?  This application has a UDP echo server running on it that can be used with the NDK windows application "testudp.exe".  It's basically a loopback test that sends data over UDP from the PC to the target board, and then waits for the target to send it back.  It checks the data sent against the data echoed back and fails if there is a mismatch.

Can you please try running that on your set up and see what happens?

Steve

Hi Steven,

I was able to make HUA ndk udp benchmark twice. Then it stopped working. Anyway, as you see below, first data throughout was only 2 Mbit and second was 500Mbit?

I use windows 7 Enterprice X64 build 7601. I suspect that my PC side may have some problem?

Hi Steven,

I figured out that java applet working under internet explorer was causing the problem. Now I am able to make the benchmark demo. Here are the results:

1. Maximum network throughout is 265Mbits/sec.

2. When PC pumps data on maximum rate %50 of the packets lost.

That is why I wrote a simple UDP sender program running on the PC with user selectable load rate. (I placed a Sleep command with variable sleep time between UDP send commands ).I also placed a simple counter in the first 4 bytes of the UDP load to trace the situation on the evmc66678 side. Here are the results:

Pump rate: 20 hz (1440 bytes each)----> Loss=4%

Pump rate: 40 hz (1440 bytes each)----> Loss=9%

pump rate Maximum(1440 bytes each)--->Loss=49%

As I mentioned before, my idea is to pump raw data into C6678 core0 without data loss and do the rest of the DSP on the other cores. If what I encounter is somewhat normal then I may switch to hyperlink to get the data into c6678.

Please advice on how to procees.

best regards

Ozhan

Ozhan,

Were you able to try the NDK client example application with the 'testudp' Windows application?

This application has a UDP echo server running on it that can be used with the NDK windows application "testudp.exe".  It's basically a data echo test that sends data over UDP from the PC to the target board, and then waits for the target to send it back.  It checks the data sent against the data echoed back and fails if there is a mismatch.

You can find the testudp application in the NDK installation, for example it's here on my machine:

C:\ti\ndk_2_21_01_38\packages\ti\ndk\winapps

Can you please try running that on your set up and see what happens?  Do you see a problem when running that UDP test?

Steve

Steven,

I am able to conduct the echo example. The following is the concole output after test run (I run it triple..)

//**************************************************

C:\>testudp 192.168.2.100

Testing target client at 192.168.2.100:7
Testing UDP packet payloads from 1 to 1468 bytes...
testudp: failed on size 1432

C:\>testudp 192.168.2.100

Testing target client at 192.168.2.100:7
Testing UDP packet payloads from 1 to 1468 bytes...
testudp: failed on size 1432

C:\>testudp 192.168.2.100

Testing target client at 192.168.2.100:7
Testing UDP packet payloads from 1 to 1468 bytes...
testudp: failed on size 1432
//******************************************************

As you see, yes houston we have a problem :) (As I suspected before)

The attached "wireshark.txt" has the wireshark packet data summary. What do you think is causing the problem?

best regards

Ozhan

Steven,

I also attached the wireshark screen snapshot for the first couple of data transfer.

Ozhan

Hi Ozhan,

I'm able to reproduce the problem on a 6678l board here locally.  I see the same failure:

C:\ti\ndk_2_22_00_06\packages\ti\ndk\winapps>testudp.exe 146.252.161.55

Testing target client at 146.252.161.55:7
Testing UDP packet payloads from 1 to 1468 bytes...
testudp.exe: failed on size 1432

C:\ti\ndk_2_22_00_06\packages\ti\ndk\winapps>

However, what's interesting is that I *do not* see this issue when running the client example on another hardware platform (OMAPL138).  On that platform, it succeeds:

C:\ti\ndk_2_22_00_06\packages\ti\ndk\winapps>testudp.exe 146.252.161.157

Testing target client at 146.252.161.157:7
Testing UDP packet payloads from 1 to 1468 bytes...
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
Test loop passed - resetting
^C
C:\ti\ndk_2_22_00_06\packages\ti\ndk\winapps>

This leads me to believe that it is due to a problem in the 6678l Ethernet driver.

I'll continue looking into this and let you know what I find.  But, it sounds to me like it may be a bug present in the driver.

Steve

Hi Ozhan,

I just wanted to update you that I'm still looking into this.  I modified the testudp app to have "UDP_LOW = 1432" and I see that it can do one iteration through the while loop successfully, but on the second iteration it fails.

At this point, my guess is that the driver's packet buffer is filling up and so causing frames to drop.  But I haven't verified yet.

I'd like to try increasing the size of the Ethernet frame buffer in the driver and see if this helps.

Steve

Hi Steven,

Actually, I have already increased the frame buffer in the network driver as described in the NDK user guide with no good outcome at all. (I recompiled the NDK) I dont know maybe I did it wrong. Anyway, I look forward getting update from you.

best regards

Ozhan

Ozhan,

It looks like this issue may be coming out of the Ethernet driver, which is code that I'm not familiar with.  I've contacted the driver author about this issue and asked him to chime in.  I suspect that there is an issue in the driver but let's see what he thinks.

Steve

Steve,

Thanks for the update, I look forward getting the solution.

best regards

Özhan

Hi Steve,

My project time frame regarding c6678 is tight in the company. When do you think my issue will be resolved?

best regards

Ozhan

Hi Ozhan,

Just to update you I filed a bug for the issue you encountered and the driver team is aware of it and they have assigned it.

SDOCM00097115 unusually high packet loss for UDP on 6678l

I will ping them on their schedule.

Steve

Hi Steve,

Any info from the driver guys?

best regards

Ozhan

Hi Ozhan,

I've been asked to take a look at this issue, and strangely enough I couldn't reproduce the error that you and Steve saw. I have discussed with Steve and we ran the same version of the code with the same hardware setup, but we see different results. (Of course, it doesn't help that I see a passing testudp.exe...)

Attached here is my version of the problem that you first described. I modified testudp (now testudp2) to send udp packets sized at 1440 bytes at a variable usec delay. On the EVM side, I run a modified helloWorld to print to UART whenever there is a receive/send transaction. I still do not see the decay you mention, even when I burst the packets at 0 delay. My setup is relatively simple: laptop and a Rev 0.2 TMDXEVM6678L both connected to a 1Gb switch.

Let me know if my attached programs have any effects on your side. I may have to loop in more experts to look in on this.

-Ivan

7563.c6678_udp.zip

EDIT: to use testudp2.exe: testudp2.exe [ip] [delay]; where delay is in usec.

Hi Ivan,

I noticed that in the "testudp2.c" there is a statement like  "#define WAIT_FOR_RESPONSE 0".  Could you change it to "#define WAIT_FOR_RESPONSE 1" and test the whole scheme again. When I did so, I saw that we have the problem.

best regards

Ozhan

Ozhan,

Changing that define to 1 would ask testudp2 to wait for a response from the EVM (with a timeout of 1 second). In either case, I was not able to see the problem. I have asked Steve to take a look at this also.

Were you able to see the UART messages in-sync with testudp2 when WAIT_FOR_RESPONSE is 0?

-Ivan

Ivan,

Please take a look at the attached zip file where there are two pictures inside. The "without bounce back" picture is the screen shot for "WAIT_FOR_RESPONSE is 0" and the other one is for "WAIT_FOR_RESPONSE is 1". I was able to get the console data via UART and you can see it on the left side box.

any comments?

Ozhan

Ozhan,

I attached some screenshots of what I see on my side. When WAIT_FOR_RESPONSE (WFR) is 0, I can see some packet loss if i send at a delay of 0 or 1ms. I might look into this a bit more, but it seems plausible that the packets were coming in faster than my EVM could handle.

In the case of WFR=1, the test will always pass. My setup works with the original testudp.exe also. In this scenario, since the PC is waiting for the echo back from the EVM, there should be plenty of time for the EVM to send/free its current packet buffer. I am more curious as to see why this is failing for both you and Steve. 

The differences I see between our setups so far is that I am using DHCP and some of my UART messages are incomplete. Neither of this should affect, or be affected by, the throughput.

Let's try looking at WFR=1 first. When the test fails, can you pause your EVM and see where in memory it is? Does it help if you run testudp2.exe with a huge delay, say 1000ms?

I will continue working with Steve to see if there are any other ideas or if we can loop anyone else in to test this. I apologize in the delay for fixing this issue.

-Ivan

7457.results.zip

Hello steven,

I have read all the comments about the topic. After some modifications of your testdpu2.c and helloworld.c for testing,

I find that there is no improvement. The error 1432 is still exist. That is, the driver should be modified.

Please check the attachment. there are test codes generated using Visual studio, the file My_HelloWorld.c is modified version of HelloWorld.c. The string "The declaration of independence" can be printed 1432 bytes, but will fail if we plan to send more.

So can you please update the DSP driver to fix the problem? and I guess that the original driver is uncompatible to hardware, maybe the buffer size, so the error appears when exceeding 1432.

Best regards,

Kunlun7838.1432 fail.zip 

For WFR = 0, the test code do nothing;

For WFR = 1, the test code is similar to testudp.c

Hello Pang,

I do believe that the driver be updated. There is no use changing the test code running in PC only.

Best regards,

Kunlun