Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorUDP 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_ForumThe 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.- Altera_Forum
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. - Altera_Forum
What are you using for the delay between sends?
You might be waiting for a timer interrupt. - Altera_Forum
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 - Altera_Forum
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? - Altera_Forum
The udp_send() allocated packet buffer in memory, so it definitely use the memory for checksum calculation and other processing.
- Altera_Forum
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. - Altera_Forum--- 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.
- Altera_Forum
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 - Altera_Forum
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.
