G120E Ethernet - long delays, buffer underrun error

The RS21 should be a good test too, all three interfaces use the same TCP stack.

Just a question

When you connect ethernet to pc (direct)
Did you are used cross over or nothing just usual cable for ethernet

Since autotranslate (or reverse can cause delay if not used cross cable)

@John_Brochue - The WiFi RS21 module was MUCH FASTER. I did not have the delay problems. I did 10,000 trials again. The longest response time was 147 ms. The average was 19 ms.

@valon_hoti_gmail_com - I used a regular patch cable for the direct-to-PC test. The adapter on my PC is auto MDI-X.

@John_Brochue - I emailed the Wireshark capture to support. Let me know if it doesn’t find it’s way to you.

When you look at it, the iterations with the longest delays are:

1.) Request 8954 - 11,871 ms
2.) Request 1 - 8,552 ms
3.) Request 7668 - 7,966 ms
4.) Request 6105 - 7,887 ms
5.) Request 6143 - 7,877 ms

that i asked i have problem similiar to you

when i connect to router-switch there no problem
when i connect to pc directly “as you say with auto MDI-X i faced or non working sometime or big delays tested with Win7 and Win10 Laptop DELL Latitude e6220 i7” and latter i tried with crossover cable(exact adapter)

and it was worked as well as to connect to router-switch response request was well responsive

test done

Arduino - ENC28J60 Arduino UIPethernet library
Nucleo STM32F411RET6 - ENC28J60 Arduino UIPethernet library, mbed test and Library / ,NET Microframework miP library

I’ve received the trace.

The WiFi module working as expected is good news, it narrows the problem down to the Ethernet driver instead of the lwip TCP/IP stack. So that’s a smaller area for us to investigate. One last thing for you to test on your end, if you have a G400D or EMX, can you rerun the test with the physical Ethernet on those two boards?

@John_Brochue - The beta version of our product from early 2015 used the original FEZ Spider, so I was able to test using the EthernetBuiltIn on EMX. Like the WiFi module, it is FASTER (average 20 ms, stdev 4.5 ms, maximum 458 ms). I updated the Spider I to the 2016 R1 SDK (4.3.8.1), so it was the same firmware version as my G120E tests.

I don’t have a G400D.

Thanks for the information. Since we were able to reproduce it, just on a longer time scale, we will take a look into it. Given the infrequent nature of the delays though, it’ll likely prove difficult to track down. We’ll let you know when and if we have any update.

2 Likes

@John_Brochue - I sent you an email last night with a little more information from further testing I did. This time I printed out the contents of the data buffers for the three transmit descriptors before & after sending the response, and during the long delays. The bytes in these buffers can be matched with the bytes of the frames captured in Wireshark.

The LPC1788 can trigger an interrupt when the buffer underrun occurs. I think the IntEnable register is already set to do this. Maybe you can run repeated queries like I have been doing, and debug the device driver when the interrupt is triggered?

There are three reasons the LPC1788 would report an underrun (listed below). I don’t think it is #1, because it looks like the frames are being sent all as a single fragment, and there is no “NoDescriptor” error being shown. You may be able to see whether it is a fatal or non-fatal error, which would tell us if it is #2 or #3. Does the driver have to soft reset the Ethernet hardware by setting the TxReset bit in the command register? It seems most likely to me that it is #2, because the frame is simply re-sent.

Three causes of an underrun are:

(1) The next fragment in a multi-fragment transmission is not available. This is a nonfatal
error. A NoDescriptor status will be returned on the previous fragment and the TxError
bit in IntStatus will be set.

(2) The transmission fragment data is not available when the Ethernet block has already
started sending the frame. This is a nonfatal error. An Underrun status will be returned
on transfer and the TxError bit in IntStatus will be set.

(3) The flow of transmission statuses stalls and a new status has to be written while a
previous status still waits to be transferred across the memory interface. This is a fatal
error which can only be resolved by a soft reset of the hardware.

The first and second situations are nonfatal and the device driver has to re-send the frame
or have upper software layers re-send the frame. In the third case the hardware is in an
undefined state and needs to be soft reset by setting the TxReset bit in the Command
register.

Thanks for the additional information, I did receive the email. So far I’d lean on it being #2, but we’ll get a better idea when we take a deeper look into it.

1 Like

Dear Darren
Could you please advise if you solved this issue somehow? I observe same problem Remove socket's supply with c# code - #13 by przemo

@John_Brochue Have you made any progress on this issue? I am following up for @Darren_SFI.

No update yet unfortunately.

OK, it has been 4 months of radio silence since this issue was raised and confirmed. Does GHI have any plans to address this problem with the G120E EthernetBuiltin function, or should we be implementing a different solution?

Unfortunately, we have to balance between TinyCLR and netmf. It is difficult to put resources into something that is being replaced.