Timo Schüring

We had a similar problem. When the application calls fnet_socket_close, the socket is aborted which leads to sending the rst-packet. So far it is not really a problem but maybe irritating. If you exclude SS_CLOSING from the abort-procedure, an ABORT-Time interval is set and so fare we see the regular connection close procedure. static fnet_return_t _fnet_tcp_close( fnet_socket_if_t *sk ) { fnet_tcp_control_t *cb = (fnet_tcp_control_t *)sk->protocol_control; /* If the connection is closed, free the...

The Motorola dBUG Shell has a lot of commands which are taking user input as long as similar tasks are performed. E.g. SHELL> md.l 0x60080200 60080200: 00000000 00000000 00000000 00000000 ................ 60080210: 00000000 00000000 00000000 00000000 ................ 60080220: 00000000 00000000 00000000 00000000 ................ 60080230: 00000000 00000000 00000000 00000000 ................ 60080240: 00000000 00000000 00000000 00000000 ................ 60080250: 00000000 00000000 00000000 00000000...

First of all, thanks a lot for providing this utility. I used the FNET-Stack version but this code allowed me to add the following small but useful add-ons: -> Added Performed Iterations Textbox so after an overnight run I see how many send-iterations have been performed (when running several thousands then it is useful) -> When Receiving a Single Package, Byte count of first package is omitted. Probably because it is not used for throughput calculation. I added a parameter to the completed events...

First of all, thanks a lot for providing this utility. I used the FNET-Stack version but this code allowed me to add the following small but useful add-ons: -> Added Performed Iterations Textbox so after an overnight run I see how many send-iterations have been performed (when running several thousands then it is useful) -> When Receiving a Single Package, Byte count of first package is omitted. Probably because it is not used for throughput calculation. I added a parameter to the completed events...

Thank you for your hints.... 1) I thought about this as well but it will take a bit. 2) Should be the case but I will check 3) I did this (I wrote a small evaluation report for UDP and TCP, it is attached. So for UDP everything is fine. There is a single packet loss occasionally but that is probably a HW issue as the MCDMA sometime corrupts the data or does not update the descriptors. This is a reported bug on silicon. The packet loss it not indicated in the MIB as it is DMA related.

Thank you for your hints.... 1) I thought about this as well but it will take a bit. 2) Should be the case but I will check 3) I did this (I wrote a small evaluation report for UDP and TCP, it is attached. So for UDP everything is fine. There is a single packet loss occasionally but that is probably a HW issue as the MCDMA sometime corrupts the data or does not update the descriptors. This is a reported bug on silicon. The packet loss it not indicated in the MIB as it is DMA related.

Hi Andrey, meanwhile I have tested quite a lot on the stack and the driver behaves reasonable though some bugfixes had to be made resulting from MCDMA issues. So I use FBENCH and benchrx to test the FNET behaviour. I had to add 11 msecs inter-package delay to make it work (polling every 10 msecs). So I am sending 10k packages of 1272 bytes. So after roughly 7k Packages buffers get full and then I see those retransmits and DUP packages which slows down everything to 10% of the initial data rate. As...