[En-Nut-Discussion] Time needed to get packet from RTL on ATmega128

[Dusan Ferbas]

Hi Harald,

0) How long does it take to process ARP request that is silently discarded 
because it is for different IP address ?
We have a large customer that sometimes produces 20 ARPs/1 ms on his network.

1) lost USART Rx bytes
-----------------------
we are using the usartavr driver (even for RS232, i.e. without half duplex 
feature). We are getting several bytes missing even from an 8 byte string 
sent at 9600 Bd (approx. 1ms between chars). This happens during 100kB sent 
into a board via TCP (FW upgrade). Sometimes only 1st 2 bytes are received, 
sometimes randomly bytes from inside that string.

Tested with Nut/OS 3.9.3.1 pre (latest). There was a circular buffer (to 
eliminate time spent with xmitting) that was filled with received byte from 
an usart AvrUsartRxComplete() interrupt routine. Output from that buffer 
was via a separate thread.

I noticed that you left 3.5.x approach to NicRx thread (limitation to serve 
only 10 packets at once). Now if there is a continuous packet storm (e.g. 
ARPs) this thread will never release CPU to other threads. What was the 
reason to do this ?

Maybe the idea was that NIcRx is running at highest priority so 
NutThreadYield() has no effect because no other thread can "overtake".

2) dev/nicrtl.c:NicGetPacket()
------------------------------
Can I replace Delay16Cycles() with IOCHRDY check ? Such a signal is 
connected to PE7 (INT7) but no piece of SW copes with it.

3) ARP:
--------
I also do not understand following change (if entry is seeded non zero 1st 
block serves this, if it is zero then code proceeds at else where I cannot 
imagine situation under which entry != 0
  * $Log: arpcache.c,v $
  * Revision 1.4  2004/07/27 19:38:30  drsung
  * Under certain circumstances the same ARPENTRY was
  * allocated twice.
  *

I noticed 2 ARP requests generated for a UDP output packet. I think that in 
net/arpcache.c:NutArpCacheQuery() if incomplete ARP entry is found, then 
'else if' is skipped and new ARP request is generated for same entry. This 
can happen e.g. if 2 threads are sending a UDP to a same IP. I think that 
code can follow in a same way but without NutArpAllocNetBuf(), 
NutArpOutput() and NutNetBufFree(). Decision can be made in 1st if block:

...
     u_char      fl_send;

     if ((entry = NutArpCacheLookup(dev->dev_icb, ip)) != 0) {
         if (entry->ae_flags & ATF_COM) {
             memcpy(mac, ((ARPENTRY *) entry)->ae_ha, 6);
             return 0;
         }
         else
             fl_send = FALSE;            //already sent, but still pending
     }
     else {
         if ((entry = NutArpCacheNew(dev->dev_icb, ip, 0, 0)) == 0) {
             return -1;
         else
             fl_send = TRUE;
     }

I did that but I am still getting 2 ARPs for 1st UDP output packet.


At 18:35 8.1.2005, you wrote:
>Hi Dusan,
>
>Not sure, what you are looking for.
>
>The code below may indeed produce '@' on the debug
>output.
>
>(*ifn->if_recv)(dev, nb) is non-deterministic. With UDP
>it ends up at NutEventPost(&sock->so_rx_rdy) in
>udpin.c, where any higher priority thread may take over.
>
>May be you can be more precisely about the actual problem
>you are hunting.
>
>Harald
>
>At 12:22 07.01.2005 +0100, you wrote:
> >Hi,
> >
> >can sb tell me the amount of time (approx. us) CPU spends with reading a
> >packet in dev/nicrtl.c:THREAD(NicRx) with NicGetPacket ? (I would like to
> >know times for ARP /short/, average UDP and full 1514 packet)
> >


Dusan Ferbas
www.dfsoft.cz