Hello,I have done everything I can see to try for over a day now but have been unable to get pause frames to be transmitted on a Gigabit link. Even with XOFF_GEN set in the command register none are sent. We've had to force our products that receive a lot of data to 100MbS. Gigabit does work otherwise, but there are so many TCP NAKs and missed packets that we'd rather run slow reliably than run at a Gig with a ton of errors. Can anyone confirm that pause frames do work in Gigabit mode? If so, can you please suggest what I might have missed or am doing wrong? I am not the "SOPC guy", but I'm told that the TSE is setup right. Interestingly, in 10/100 mode, I actually do occasionally see pause frames when even that's a bit too fast for the Cyclone. Thanks, Bill A
I don't know the answer to your question, but you can avoid TCP naks by carefully configuring your TCP window size. In order to avoid those naks, you need to be sure that the TCP window size is always smaller than your incoming rx fifo. So either increase your rx fifo, or hack into your embedded OS to use a lower TCP window size. (depending on the OS you have, it may be a bit tricky to find out where it is defined).Once I did that on my system I never got any missed TCP packets, even with a very fast PC on the other end.
Changing the advertised TCP window will only help if there is only a single connection.It is also unlikely that you'll even saturate 100M - so you probably aren't getting a lower throughput. Of course, whatever ethernet switch is changing from Ge to 100M might also have limited buffer space. OTOH it might manage to genarate the required pause frames.
Thank you both. I didn't consider that the pause frames I see at 100MbS (in WireShark) are from the switch. Which means the switch could also be stripping out the ones sent from the TSE. I can run direct and prove that out.Then I wonder am I just over-interrupting the Cyclone? Can I have the SGDMA collect up to 8 packets before interrupting? I know the PowerPC can do this to reduce interrupt overhead, but it also generates an interrupt after a very small delay in receiving a packet so a single packet isn't stranded. I tried to manually send a pause frame on the receipt of every packet and it did not work. Bill
--- Quote Start --- Changing the advertised TCP window will only help if there is only a single connection. --- Quote End --- Yes of course. In my use case I had only one TCP connection that required a high bandwidth at any given time so I didn't really bother about that fact. But it can be a problem in other use cases. --- Quote Start --- Can I have the SGDMA collect up to 8 packets before interrupting? --- Quote End --- IIRC if you create a chain with 8 descriptors (plus a 9th with owned_by_hw to stop the transfer) you can configure the SGDMA to generate an interrupt at the end of the chain rather than after each descriptor is processed. Of course it will require to modify the driver a bit.
--- Quote Start --- but it also generates an interrupt after a very small delay in receiving a packet so a single packet isn't stranded. --- Quote End --- This on the other hand, I'm pretty sure the SGDMA isn't capable to do. You could probably do it in software, having an alarm thread that regularly checks the descriptors to see if one has finished, but then it starts to be a bit complicated...