helloworld udp checksum error & recvFull issues

So, you changed rc=8192 to 32768 in helloworld.c and udphello.c (can you send me this file)? What is the tool to generate UDP broadcast packet? Can you let me know so I can use it to duplicate your issue?

Regards, Eric

yes, i have done that change.

UDP broadcast packet is send through a custom application created in linux.

it uses standard linux socket.

i can share all those codes and if required the udp executable also

Did issue happen for smaller UDP packets? Or unicast packets? Can you share the code and a short description how to build/run the braodcast application in Linux?

hi,

i hve not checked with smaller packets or unicast. i  will try

i'm sending all the files.
the udp sending program is an executable , one can run as $prompt> ./udpsend 300
300 denotes interpacket delay to control the speed. one has to run as root.

our ip adress are 192.232.1.xx
subnet mask = 255.255.255.0

file being big i have shared in google drive

https://docs.google.com/file/d/0ByF49iOapPLRTk5DeHhseFFGbXc/edit?usp=sharing

hi Eric,

i have checked with different packet sizes, check sum error happens when udp data size > 1430 (eth frame > 1472). below this everything seems to be fine.

but i have recvFull even when the size of packet is reduced . i have to reduce the data rate to very low <5Mbps to correct this

Regards

pratheek

I have used the udp flood tool to generate diff packet sizes

http://www.mcafee.com/in/downloads/free-tools/udpflood.aspx

link to the tool.

I downloaded all the files you shared. To test this I need a Linux machine in a private network to broadcast packets, I don't have this setup. The Linux machine I have is in coporate network, one thing I can do is to send unicast packets to 6678 EVM running hello world. Can you help to see if unicast also caused the problem? For the udpflood tool, the link is blocked in my network.

Regards, Eric

i have checked with unicast also , it also has the same problem i mentioned in previous post.

there is some problem with packet size > 1430 bytes.

i also want to know the reason for recvFull.

if required i can share udpflood tool also

Thanks! I can try the unicast with variable packet length and rate then. Can you share the udpfllod tool?

Regards, Eric

hi Eric,

link

https://docs.google.com/file/d/0ByF49iOapPLRLUhEYXZJeWVMVVE/edit?usp=sharing

Hi,

udpflood is considered as a virus here so I used the iperf to do the test from my PC to EVM. https://code.google.com/p/iperf-cygwin/downloads/detail?name=iperf-2.0.5-cygwin.zip&can=2&q=

The command I used is: iperf -u -c 158.218.109.165 -p 55100 -b 50m -t 1200. That is UDP to 158.218.109.165 port 55100 for 1200 seconds, at 50Mbits/s. From wireshark, the UDP payload is 1470 bytes, so total packet is 1512 bytes. I do see Receive full but I didn't checksum error. I will check if anything can be tuned to improve this. I knew there is #define PKT_NUM_FRAMEBUF    192 for the receive buffer in pbm_data.c.

Regards, Eric 

IPERF:
================

C:\TEST\Downloads\iperf-2.0.5-cygwin\iperf-2.0.5-cygwin>iper
f -u -c 158.218.109.165 -p 55100 -b 50m -t 1200
------------------------------------------------------------
Client connecting to 158.218.109.165, UDP port 55100
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 158.218.109.172 port 60410 connected with 158.218.109.165 port 55100

[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-1200.0 sec  6.88 GBytes  49.2 Mbits/sec
[  3] Sent 5023551 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

===================

EVM:

PASS successfully initialized 
Ethernet subsystem successfully initialized 
Ethernet eventId : 48 and vectId (Interrupt) : 7 
Registration of the EMAC Successful, waiting for link up ..
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000
Network Added: If-1:158.218.109.165
Service Status: DHCPC    : Enabled  : Running  : 017
Time Taken = 322267
Packets count = 100000	Total recieved = 100045	Receieve Rcv Full = 0	Check sum error = 0
Data rate = 35636 Kb/s
Time Taken = 236600
Packets count = 200000	Total recieved = 200157	Receieve Rcv Full = 78	Check sum error = 0
Data rate = 48539 Kb/s
Time Taken = 238127
Packets count = 300000	Total recieved = 300270	Receieve Rcv Full = 158	Check sum error = 0
Data rate = 48227 Kb/s
Time Taken = 239750
Packets count = 400000	Total recieved = 400382	Receieve Rcv Full = 239	Check sum error = 0
Data rate = 47901 Kb/s
Time Taken = 238323
Packets count = 500000	Total recieved = 500487	Receieve Rcv Full = 319	Check sum error = 0
Data rate = 48188 Kb/s
Time Taken = 237433
Packets count = 600000	Total recieved = 600599	Receieve Rcv Full = 392	Check sum error = 0
Data rate = 48368 Kb/s
Time Taken = 239120
Packets count = 700000	Total recieved = 700712	Receieve Rcv Full = 463	Check sum error = 0
Data rate = 48027 Kb/s
Time Taken = 241049
Packets count = 800000	Total recieved = 800816	Receieve Rcv Full = 536	Check sum error = 0
Data rate = 47643 Kb/s
Time Taken = 277993
Packets count = 900000	Total recieved = 900924	Receieve Rcv Full = 606	Check sum error = 0
Data rate = 41311 Kb/s
Time Taken = 231658
Packets count = 1000000	Total recieved = 1001024	Receieve Rcv Full = 672	Check sum error = 0
Data rate = 49574 Kb/s
Time Taken = 239143
Packets count = 1100000	Total recieved = 1101053	Receieve Rcv Full = 674	Check sum error = 0
Data rate = 48023 Kb/s
Time Taken = 236508
Packets count = 1200000	Total recieved = 1201083	Receieve Rcv Full = 675	Check sum error = 0
Data rate = 48558 Kb/s
Time Taken = 247841
Packets count = 1300000	Total recieved = 1301120	Receieve Rcv Full = 675	Check sum error = 0
Data rate = 46337 Kb/s
Time Taken = 236762
Packets count = 1400000	Total recieved = 1401173	Receieve Rcv Full = 675	Check sum error = 0
Data rate = 48505 Kb/s
Time Taken = 250354
Packets count = 1500000	Total recieved = 1501213	Receieve Rcv Full = 676	Check sum error = 0
Data rate = 45872 Kb/s
Time Taken = 240524
Packets count = 1600000	Total recieved = 1601244	Receieve Rcv Full = 676	Check sum error = 0
Data rate = 47747 Kb/s
Time Taken = 246614
Packets count = 1700000	Total recieved = 1701286	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 46568 Kb/s
Time Taken = 248463
Packets count = 1800000	Total recieved = 1801313	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 46221 Kb/s
Time Taken = 243669
Packets count = 1900000	Total recieved = 1901343	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 47131 Kb/s
Time Taken = 246530
Packets count = 2000000	Total recieved = 2001379	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 46584 Kb/s
Time Taken = 236729
Packets count = 2100000	Total recieved = 2101412	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48512 Kb/s
Time Taken = 236857
Packets count = 2200000	Total recieved = 2201445	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48486 Kb/s
Time Taken = 237404
Packets count = 2300000	Total recieved = 2301479	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48374 Kb/s
Time Taken = 237727
Packets count = 2400000	Total recieved = 2401511	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48309 Kb/s
Time Taken = 235984
Packets count = 2500000	Total recieved = 2501547	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48665 Kb/s
Time Taken = 236998
Packets count = 2600000	Total recieved = 2601581	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48457 Kb/s
Time Taken = 236540
Packets count = 2700000	Total recieved = 2701615	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48551 Kb/s
Time Taken = 236444
Packets count = 2800000	Total recieved = 2801642	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48571 Kb/s
Time Taken = 236769
Packets count = 2900000	Total recieved = 2901675	Receieve Rcv Full = 681	Check sum error = 0
Data rate = 48504 Kb/s
Time Taken = 236576
Packets count = 3000000	Total recieved = 3001708	Receieve Rcv Full = 682	Check sum error = 0
Data rate = 48544 Kb/s
Time Taken = 236603
Packets count = 3100000	Total recieved = 3101739	Receieve Rcv Full = 682	Check sum error = 0
Data rate = 48538 Kb/s
Time Taken = 236860
Packets count = 3200000	Total recieved = 3201764	Receieve Rcv Full = 682	Check sum error = 0
Data rate = 48485 Kb/s
Time Taken = 236288
Packets count = 3300000	Total recieved = 3301795	Receieve Rcv Full = 682	Check sum error = 0
Data rate = 48603 Kb/s
Time Taken = 236596
Packets count = 3400000	Total recieved = 3401827	Receieve Rcv Full = 682	Check sum error = 0
Data rate = 48540 Kb/s
Time Taken = 235849
Packets count = 3500000	Total recieved = 3501857	Receieve Rcv Full = 682	Check sum error = 0
Data rate = 48693 Kb/s
Time Taken = 236214
Packets count = 3600000	Total recieved = 3601888	Receieve Rcv Full = 683	Check sum error = 0
Data rate = 48618 Kb/s
Time Taken = 237062
Packets count = 3700000	Total recieved = 3701920	Receieve Rcv Full = 686	Check sum error = 0
Data rate = 48444 Kb/s
Time Taken = 236804
Packets count = 3800000	Total recieved = 3801967	Receieve Rcv Full = 692	Check sum error = 0
Data rate = 48497 Kb/s
Time Taken = 236482
Packets count = 3900000	Total recieved = 3902009	Receieve Rcv Full = 698	Check sum error = 0
Data rate = 48563 Kb/s
Time Taken = 236725
Packets count = 4000000	Total recieved = 4002063	Receieve Rcv Full = 704	Check sum error = 0
Data rate = 48513 Kb/s
Time Taken = 237192
Packets count = 4100000	Total recieved = 4102094	Receieve Rcv Full = 709	Check sum error = 0
Data rate = 48418 Kb/s
Time Taken = 237669
Packets count = 4200000	Total recieved = 4202131	Receieve Rcv Full = 714	Check sum error = 0
Data rate = 48320 Kb/s
Time Taken = 236343
Packets count = 4300000	Total recieved = 4302171	Receieve Rcv Full = 718	Check sum error = 0
Data rate = 48591 Kb/s
Time Taken = 235356
Packets count = 4400000	Total recieved = 4402206	Receieve Rcv Full = 721	Check sum error = 0
Data rate = 48795 Kb/s
Time Taken = 237224
Packets count = 4500000	Total recieved = 4502236	Receieve Rcv Full = 726	Check sum error = 0
Data rate = 48411 Kb/s
Time Taken = 236710
Packets count = 4600000	Total recieved = 4602274	Receieve Rcv Full = 731	Check sum error = 0
Data rate = 48516 Kb/s
Time Taken = 237481
Packets count = 4700000	Total recieved = 4702313	Receieve Rcv Full = 735	Check sum error = 0
Data rate = 48359 Kb/s
Time Taken = 237198
Packets count = 4800000	Total recieved = 4802349	Receieve Rcv Full = 737	Check sum error = 0
Data rate = 48416 Kb/s
Time Taken = 236722
Packets count = 4900000	Total recieved = 4902384	Receieve Rcv Full = 742	Check sum error = 0
Data rate = 48514 Kb/s

Hi,

The Rec full was caused by the system_printf() in the code. If you remove the those code (only free the buffer there), then halt DSP and check udps.RecFull in expression window, I don't see the issue at even 100 Mbit/s. So, I can't reproduce the checksum error, for rcv full it seems not a real issue.  

Regards, Eric

hi Eric,

thanks for help. i have understood recvFull is not a real issue its caused by system printf.

i would like to know more why its causing recv full?

my understanding is system printf sends out prints only when system has free time  so it should not effect the reception.

hi,

i have tried our code i'm also geeting similar results as you told.

i have tried something extra with it, which again created the badsum issue.

i shall explain in detail. i found that the iperf tool sends 1470 payload every time. the packet has only a slight change in payload.

my actual requirement will have different data every time.

so i copied nimu_eth.c (or any file) to a text file abcd.txt multiple times till i got a 111MB file.

i send this file with the iperf. iperf -u -c 158.218.109.165 -p 55100 -b 50m -t 1200 -F abcd.txt

this caused the checksum error to occur.

i hope i have made it clear.

In .cfg:

/* Required if using System_printf to output on the console */

SysStd = xdc.useModule('xdc.runtime.SysStd');

System.SupportProxy = SysStd;

In this case of System_printf(), you can choose different output methods depending on your needs/situation. For example, you could switch to SysStd module instead of SysMin. SysStd forces the output across JTAG at runtime so you see the messages as they occur on the target and no buffering is required. However, this mechanism basically stops the processor for the time it takes to send the data across JTAG to CCS/Eclipse - not exactly friendly for real-time - but nice for non-real-time debugging.

For SysMin, this module buffers output in a buffer that "wraps" when it is full. SysMin does not send the buffered output to the CCS console until your program terminates.

Regards, Eric

Hi,

I used a "-F C:\DATA\SOFTWARE\MCSDK_2_1_2_X\bios_mcsdk_02_01_02_06_setupwin32.exe" to send this binary file.

At the beginning, I didn't see checksum error. I noticed from Wireshark that each UDP packets is splited into two: one 1314 bytes (IP fragment) and the other 232 bytes (UDP).

Then, I changed MTU of my PC to 1800 according to http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/how-do-i-change-the-mtu-setting-in-windows-7/ec01f5d0-7082-4a9d-97b5-1d1dccb121d2.

I did the same test and got some chksum errors. However, my wireshark can't capture those big packets, I can't verfiy if the PC send them out with correct UDP chksum or not. How do you capture big packets?

Regards, Eric  

Hi eric,

When I did that my packet size was still 1470, which comes under mtu of 1500.

i guess the problem is with the bigger file 1gb you tried with and the time in seconds you have given. I.e. 50m and 1200

in wireshark fragmented udp packets are combined together and shown just after every associated fragments. The udp checksum should be correct even for fragmented packets.

I'm getting close to 10 % checksum rejection when payload is greater than 1430 and data are totally different.

can you try with some text file of 100MB size.

Hi,

I am not sure. I rebooted my PC, seems the MTU is restored back to 1500. I saw UDP packets are fragmented again in Wireshark, in this case, I never saw UDP chksum error. Can you zip and share your 100MB txt file?

Regards, Eric

hi Eric , 

i have made that file by copy pasting , nimu_eth.c multiple time till i got the size. i will zip and share the exact file also.

i willl also try with mcsdk setup.exe as the file here and see if iperf fragments the packet.

can you try with some other speeds.

as far as i know wireshark shows both the fragments in white or light gray and then the combined one as blue. which will be the total packet. 

whether by default ndk supports fragmented udp packets.

hi Eric,

i have checked in multiple pcs with windows 7 32 & 64 bit, different network device also,

in all setup my iperf is sending 1470 size packet and there is no fragmentation (as seen in wireshark)

i'm attching the file which i used for the test.

can u you send me the wireshark fragmentation capture?

Hi,

I tried your abcd.txt:

iperf -u -c 158.218.109.165 -p 55100 -b 50m -t 1200 -F abcd.txt
------------------------------------------------------------
Client connecting to 158.218.109.165, UDP port 55100
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[  4] local 158.218.109.172 port 57679 connected with 158.218.109.165 port 55100

[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-19.9 sec   114 MBytes  47.9 Mbits/sec
[  4] Sent 81172 datagrams
[  4] WARNING: did not receive ack of last datagram after 10 tries.

From dsp side,

No chksum error. From ips, you can see fragment and re-assmble for all UDP packets. Attached is the Wireshark.3386.1470_frag.rar

Regards, Eric

hi Eric,

i have seen the logs . It seems  all fine @ your end.

i'm not able to get sucess here. the problem is still there.

i'm not able to figure out why its behaving so differently

thanks for your help