Forum Discussion
Altera_Forum
Honored Contributor
14 years agoUDP delay to send
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 ?16 Replies
- Altera_Forum
Honored Contributor
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. - Altera_Forum
Honored Contributor
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 - Altera_Forum
Honored Contributor
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. - Altera_Forum
Honored Contributor
--- 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? - Altera_Forum
Honored Contributor
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 - Altera_Forum
Honored Contributor
If a 10ms 'tick' generated a packet every 24ms something is probably wrong with the clock divider somewhere!