Honored Contributor
Honored ContributorHi Jake
Thank you for your reply. Probably you can give me more help than any other, since I'm using the OpenCores ethernet MAC you ported to Avalon bus. --- Quote Start --- So you believe the delay is occuring between when the app delivers the packet to the Nichestack and when it is finally output on the wire. --- Quote End --- I set PIOs just before and after the send call and probe the wire output: here I see the 100 to 200ms delay. The only non-standard way of operation is that I use the socket in non blocking mode: could this be relevant? --- Quote Start --- The Nichstack will hold onto this packet until the OS signals to the Nichstack that it can run its routines. So if your application is super busy performing higher priority tasks, the Nichestack may not get an opportunity to process the packet. --- Quote End --- That's what I thought at the very beginning. So I added a lot of sleeps to leave Nichestack plenty of time to process packets. Nothing changed. I profiled my app and I verified it correctly releases control to other tasks: after it sends the data is always in a suspended state. --- Quote Start --- Eventually the Nichestack will deliver a packet to the MAC driver's transmit function. It's been a while since I examined that driver but I believe it performs a synchronous send (meaning it will transmit the packet and wait for it to finish transmitting before it moves on). If you want to debug further, you could put some code into the tse_mac_raw_send function of the driver "ins_tse_mac.c" to spit out the time or something. The driver initiates a DMA transfer to move the packet from memory to the MAC. --- Quote End --- As I said before, I don't use tse but the ocm mac. In the eth_ocm driver, as you well know, you can cofigure for sync or async send; I tried both but the delay is always there and always the same. --- Quote Start --- After this it's all hardware. The only other place where delay can occur is in the TX FIFO inside the MAC. It's unlikely that this is occurring. --- Quote End --- I exclude hardware problem and I think is a tcp stack issue, because of two facts: - as I wrote in the original post, it seems to me that the delay occurs only when there is still not acknowledged tcp data. If I transmit a single bunch of data there is no delay at all. - I use the same hw for an EtherCAT master, then without TCP stack: here I get very precise timings, with delays of few us between the application send and the start of frame on the wire. Regards Cris
