W5100 sendto 관련 문의

#1

w5100 driver 1.8버젼을 이용하여 40M급 ethernet(udp)통신을 구현하려 하고 있읍니다.
기존에 NMS, EMS용으로 w5100제품을 이용하였읍니다. 크게 속도에 관심을 가질이유가 없었읍니다.
현재 프로젝트는 adc data를 w5100을 이용하여 전송하는 제품을 개발중입니다.

  1. cpu는 100M 클럭을 사용하고 있읍니다.
    wiznet관련은 폴링 처리하고 각각의 MTU=1500Byte에 관련된 프로세스 처리 시간만 고려하면 다음과 같읍니다.
    rx 301uSec, tx 420uSec

  2. 문제점은 tx전, 후에 delay각 약 500uSec정도를 주어야 전송이 제대로 되더군요.
    아니면, 얼마간 전송후에 sendto함수의


#ifdef DEF_IINCHIP_INT
while ( (getISR(s) & Sn_IR_SEND_OK) != Sn_IR_SEND_OK )
#else
[color=#FF0000]while ( (IINCHIP_READ(Sn_IR(s)) & Sn_IR_SEND_OK) != Sn_IR_SEND_OK ) [/color]
#endif
{
#ifdef DEF_IINCHIP_INT
if(getISR(s) & Sn_IR_TIMEOUT)
#else
[color=#FF0000] if(IINCHIP_READ(Sn_IR(s)) & Sn_IR_TIMEOUT)[/color]
#endif
{
#ifdef DEF_IINCHIP_DBG
printf(“WiznetSend fail.\r\n”);
#endif
/* +2008.01 [bj]: clear interrupt /
#ifdef DEF_IINCHIP_INT
putISR(s, getISR(s) & ~(Sn_IR_SEND_OK | Sn_IR_TIMEOUT)); /
clear SEND_OK & TIMEOUT /
#else
IINCHIP_WRITE(Sn_IR(s), (Sn_IR_SEND_OK | Sn_IR_TIMEOUT)); /
clear SEND_OK & TIMEOUT */
#endif

#if defined ( ADD_UCOSII_ )
OSSemPost(gWiznetTxSem);
#endif
return 0;
}
}


빨간 부분에서 무한 루프에 빠지더군요.

2.1 Sn_IR에 sendok bit가 셋팅이 안되면 전송이 제대로 이루어지지않은 것으로 보아야 할지요?
2.2 Sn_IR에 Timeout이 발생하지 않는 이유가 무었인지요?
2.3 tx전후에 delay가 반드시 필요한거 같은데 이유가 무었인지요?

==> 각각의 해결 방법은 무었인가요?

  1. 현재 전송이 제대로 되는 상태에서(w5100 500uSec Delay가 포함) 40M 전송시간이 약 3~4초 사이 입니다.
    1초로 줄여야 되는데, udp로 전송하는데 시간을 줄이기 위한 tip같은 것이 있으면 알려주십시요.
#2

tx와 rx를 동시에 처리한다고 가정하고, 이론적 bandwidth를 계산해보면
721us:1500B=1s:x
x = 2083333B = 2083MB 입니다. 그리고 원하는 40Mbps를 바이트로 환산하면 5MBps입니다.
따라서 현재 사용하는 MCU에서 40Mbps를 구현한다는 것은 무리가 따를 것으로 보입니다만…

delay는 필요합니다. 아니 Delay보단 반드시 Send OK를 확인하셔야 합니다. Send OK가 발생하지 않은 패킷은 정상적으로 전송되었다 볼수 없습니다. Send OK의 확인을 위한 Delay는 Data의 크기,이전 Packet 전송여부 및 네트워크 통신량등 많은 변수가 있어 정확히 얼마가 걸린다 확답은 드릴수 없습니다. 이부분은 추후 다시 답변드리겠습니다.

UDP에서 Timeout은 ARP Timeout입니다. 1:1통신을 할 경우 Destination IP에 대해 최초에 한번만 ARP를 수행하므로
그 이후 전송되는 Data들은 Timeout이 발생하지 않습니다.

코드상 semaphore를 사용하시는 것을 보아 OS를 사용하시는 듯 합니다.
Send Ok를 기다리는 동안 (말씀하신 500us Delay동안 Rx와 같은 다른 작업을 수행하여 MCU의 효율을 높이고)
또한 Memory Copy는 DMA engine을 사용하는 것, Code Optimization 등이 있습니다만, 이부분은 잘 하셨을 거라 믿습니다.

#3

tx와 rx를 동시에 처리한다고 가정하고, 이론적 bandwidth를 계산해보면
721us:1500B=1s:x
x = 2083333B = 2083MB 입니다. 그리고 원하는 40Mbps를 바이트로 환산하면 5MBps입니다.
따라서 현재 사용하는 MCU에서 40Mbps를 구현한다는 것은 무리가 따를 것으로 보입니다만…
=> 이부분은 저희 cpu처리 문제입니다. cpu 클락을 높이면서 테스트 중입니다.

delay는 필요합니다. 아니 Delay보단 반드시 Send OK를 확인하셔야 합니다. Send OK가 발생하지 않은 패킷은 정상적으로 전송되었다 볼수 없습니다. Send OK의 확인을 위한 Delay는 Data의 크기,이전 Packet 전송여부 및 네트워크 통신량등 많은 변수가 있어 정확히 얼마가 걸린다 확답은 드릴수 없습니다. 이부분은 추후 다시 답변드리겠습니다.
=> 계산상으로 1500byte는 100Mbps 기준으로 0.00011444…sec(114…usec)가 걸립니다. 114:1500byte=x:40Mbit(5,242,880byte) 이론상 0.398sec가 걸립니다. 즉, 0.602초에 process가 끝나면 되구요. rx고려하면,…약 0.3초 이내에 process가 끝나면 됩니다. process는 4.17*10-5에 끝나면 됩니다.

UDP에서 Timeout은 ARP Timeout입니다. 1:1통신을 할 경우 Destination IP에 대해 최초에 한번만 ARP를 수행하므로
그 이후 전송되는 Data들은 Timeout이 발생하지 않습니다.
=>코드상 sendok만 되면 timeout문제는 해결되겠군요. 아니면 최초 arp에 대한 flag만 두면 되구요. sockclose후 전송하면 다시 최초 한번만 arp를 수행하게 되는지요? 그리고 sendok체크 루틴에 delay를 추가하여 실험해 보겠읍니다.

코드상 semaphore를 사용하시는 것을 보아 OS를 사용하시는 듯 합니다.
Send Ok를 기다리는 동안 (말씀하신 500us Delay동안 Rx와 같은 다른 작업을 수행하여 MCU의 효율을 높이고)
또한 Memory Copy는 DMA engine을 사용하는 것, Code Optimization 등이 있습니다만, 이부분은 잘 하셨을 거라 믿습니다.
=> os define은 사용하지 않고 있읍니다.


질문 요점은 프로세스 시간이 0이 걸리고, sendto에 무한 루프도 무시하더라도 500usec delay가 들어가면, 계산상으로 1초이내에 40Mbps가 나올수 없다는 겁니다. (500usec:1500=x:5,242,880 => 1.747sec가 걸립니다.)

#4

100M Link에서 NIC clock은 40ns입니다. (10M는 400ns)
패킷이 실제 Ethernet으로 나가는 이론적 수치는 다음과 같습니다. 우선 MCU 가 W5300을 Control하는 시간은 MCU 성능에 따라 다르므로 계산하지 않습니다.

  1. Socket Buffer에 1472 Byte UDP 데이타를 저장 (실제 Ethernet으로 전송시 1514Byte가 전송됨)
    소요시간 ?
  2. 데이타전송을 위해서 Send command를 수행합니다.
    소요시간 ?
  3. Send command가 클리어 되었는지 확인합니다.
    Send command는 Write 후 5 NIC clock 후 자동 Clear됩니다
  4. Socket Buffer를 Ethernet으로 전송을 위한 내부 Memory로 자동으로 Copy 됩니다.
    1byte당 1 NIC clock
    내부 전송 Ethernet Memory가 비어있다고 가정함, 그렇지 않을 경우 전송할 1Byte 당 2 NIC clock 필요(6번참조)
  5. Send OK를 기다립니다.
    Memory 자동 copy가 완료되는 시점에 Send OK 가 설정됩니다. (1472 NIC clock)
    Send OK 이후 Socket Buffer는 비워짐.
  6. Ethernet Phy를 통해 데이타가 자동 전송되어집니다.
    Interframe gap(IFG : 인터넷 검색 참조)을 기다림(900ns)
    1 Byte 당 2 NIC clock (1514 * 2 = 3028)
    내부 전송 Ethernet Memory가 비워짐.

6번 데이타 전송 동안 1~5을 계속 반복 수행함.

상기와 같이 계산하면 패킷 전송에 대한 이론적 시간은 (MCU running 시간은 무시)
최소 (내부전송 Ethernet Memory가 비어 있을 경우와 Socket Buffer가 비어 있을 경우)
(5+1472+3028)*40ns + 900ns = 181.1 us
최대 (내부전송 Ethernet Memory가 비어 있지 않을 경우 즉 Socket Buffer가 비어 있지 않을 경우)
(3028+5+1472+3028)*40ns + 900ns = 302.22 us

입니다. 따라서 말씀 하신 Delay 500us까지 필요없습니다. Send command clear와 Send OK 확인하면 되므로 Delay를 강제로 주지 않아도 될 것 같습니다만,

현 증상으로 Send OK가 발생하지 않는다고 하니? 이부분은 Delay의 문제가 아닌 다른 문제 인거 같습니다. 이부분을 먼저 해결해야 할 것 같습니다.

그리고 Socket을 Close한다고 해도 Destination 정보는 그대로 남아 있습니다.따라서 재 Open이후 같은 Destination으로 UDP를 전송할 경우 ARP는 전송되지 않습니다. ARP는 Destination이 변경될 경우만 전송됩니다.

아무튼 왜 Send OK가 발생하지 않고 무한루프에 빠지는지 이 문제 해결이 시급해 보입니다.