Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

UDP delay to send

Altera_Forum
Honored Contributor II
1,869 Views

Hi, 

I am using NicheStack with the Altera Cyclone III NiosII Embended Evaluation kit. 

My application principale is to get measurements and send it each 1ms with UDP_send(). 

I have done it. 

For try, i setup each 10ms get/send, for about 20 trame sent. I send a counter to have a date (1MHz). 

With WireShark, i can see that the get measurements is done in good time (counter date), but the effective UDP frame is receive each 24ms.  

Explain : first at  

0.000 count 000376 

0.024 count 001376 

0.048 count 002376 

0.072 count 003376 

... 

Certainly it is buffered somewhere and i think there is a limit. 

 

NIOS Processor i choose is the F at 133MHz (the most on the right) 

I started from the SampleSocketServer. All the tasks i have written are OSPend() and I use a very short INTerrupt function to give a top each 10ms. The two fonctions INT() and mysendUDP() I've measured 1.5us with oscilloscope. 

 

Is there an equivalent Flush() for UDP or TCP Buffer ?
0 Kudos
16 Replies
Altera_Forum
Honored Contributor II
834 Views

The udp_send() function also forms IP header, calculates it's checksum, plus forms UDP header and calculates all the payload and header checksum. This takes time, so consider that doing measurements. 

 

I would offer to use hardware UDP implementation.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

Thanks Socrates, 

 

I thought my timming measurement includes this. 

In fact I set a pin in entrance in INTerrupt and reset it after the UDP_send(). 

Is the UDS_send() give "eat" to another waiting Task to do what you say or when returne it is done ? 

 

Bvincent1 

Sorry for my poor english.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

What are you using for the delay between sends? 

You might be waiting for a timer interrupt.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

Hello dsl ! 

I am using an external 1MHz Oscillator in FPGA I div 10 000 and set an INT input to the NIOS Processor = 10ms. 

This part is good due to the good counter value received in UDP Trame, mean INT and UDP_send(). But it takes too much time to effectively send the trame in RJ45. I think a buffer is fed, but send only once each 24ms. I would like to flush it. 

 

Bvincent1
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

I don't think there is any buffer storing UDP packets. They are sent as soon as you call the send function, so you won't find any flush function. 

Maybe everything works fine in fact. I don't think that wireshark can do time measurements with a 1ms resolution anyway. If you look farther down, are the timestamps still multiple of 24ms?
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

The udp_send() allocated packet buffer in memory, so it definitely use the memory for checksum calculation and other processing.

0 Kudos
Altera_Forum
Honored Contributor II
834 Views

wireshark can give 1ms timestamps - but possibly not on windows. 

I've also seem windows use a 64Hz system clock (16ms ticks). 

But then wireshark would show bursts of packets with the same timestamp. 

Might be worth adding/checking a sequence number - just in case lots of packets are getting discarded somewhere.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

 

--- Quote Start ---  

The udp_send() allocated packet buffer in memory, so it definitely use the memory for checksum calculation and other processing. 

--- Quote End ---  

 

Yes sorry, I meant buffer in the sense of something that would keep one or several UDP packets and wait for something to happen before sending them (as can be seen on some TCP streams). There are of course memory buffers involved in a UDP packet sending process, but nothing that would cause a delay and packets suddenly sent in bursts.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

Thanks for your posts ! 

I have red in netbuf.h about struct netbuf 

 

/*...PACKETs are pk_alloc()ed by the sending protocol and  

* freed by the lower layer level that dispatches them, usually  

* net link layer driver.  

*/ 

 

In an other way Wireshark on my other netcard can record few events in a ms. 

Is there anybody has done benchmark for TCP or other protocol with the Stack IP INiche ? 

 

bvincent1
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

A lot of ethernet MAC units will periodically poll the next TX descriptor, but the device driver normally forces a 'poll' after finishing the tx setup. 

I don't know how the fpga MAC unit works, but maybe that the driver is failing to tell the MAC unit that it has setup a transmit - leading to packet bursts.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

I never spent the time to get it wo work; but goto the Altera wiki and search for "Nios UDP Offload Example". 

It uses some sort of stat logging built into the niche stack. I could never get the damn thing to compile though, but i was focusing on the bypassing the Nios.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

Hi bvincent, 

I read through the thread and I write here a few thoughts. I hope you'll find something useful. 

The 24ms delay is rather big for UDP. I get better performance with TCP, which is a far more complex transport protocol, with Nios running at 100MHz. Then I think there's an intrinsic flaw you are missing. Offloading UDP may not be the solution. 

I'm concerned about the use of OSPend you mentioned in the original post: are you sure the 24ms delay is not related to OS? maybe because of non optimal thread priorities or any other problem with task switching? 

Another thing to check is the UDP packet you send: is it well formed? do destination MAC and IP match those of your interface? If not, I guess the lower IP layer would try to route the packet to a non existent interface and it would lose time or wait for a timeout. 

About Wireshark I can confirm you it is somewhat accurate down to 1 or 2ms; I obtained this accuracy even with Windows on a 10 years old machine.  

For more help, can you please clarify a point you didn't answer: Does the sequence of 24ms spaced udp packets continue indefinitely or it blocks after a while, possibly with an error message from nios jtag terminal? 

 

Regards
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

Hi Cris72, 

Thanks for your analyse. 

I can confirm that i do an acquisition that I send each 10ms including a 1MHz time counter within the UDP data. 

The real sent through RJ45 is each 24ms. 

I.e. :  

at 0ms the first UDP message including count=000us 

at 24ms the second message including count=1000us 

at 48ms the third message including count=2000us which was acquired at 20ms and so on.
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

 

--- Quote Start ---  

 

at 0ms the first UDP message including count=000us 

at 24ms the second message including count=1000us 

at 48ms the third message including count=2000us which was acquired at 20ms and so on. 

--- Quote End ---  

 

If timer runs @ 1MHz and you send each 10ms, you should rather have: 

count=000us, count=10000us, count=20000us 

Your count values would apply for 1ms send period or a 10us (0.1MHz) timer. 

 

Anyway what I asked is how long this process can go on: does it stop after these 3 sends or you can get at time 24*N ms a Nth message including count=1000*N us for any arbitrary N? Or did you find a value for N when the system eventually stops sending frames?
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

I 've found !! 

When I setup the NIOS in SOPCBuilder, I'have add an Interval Time Core. 

and I setted it with the default values = 10ms. 

Shurely it is the task scheduler base. 

 

Well i have reduce this to 1ms and it works fine, I receive 30 000 UDP data at exactly 1ms each. 

 

Thank you all readers and writers on my topic. 

bvincent1
0 Kudos
Altera_Forum
Honored Contributor II
834 Views

If a 10ms 'tick' generated a packet every 24ms something is probably wrong with the clock divider somewhere!

0 Kudos
Reply