w5100 전송속도 관련문의합니다.(소스코드포함)

ftp서버로 작동중 전송속도문제로 문의 했었는데요, 소스코드 올려드릴께요.
검토 부탁드립니다.
참고로 atmega64a-au로 cpu를 바꿨고 clock도 16MHz로 바꾸었습니다.
passive모드를 사용했었고요, aliveftp라는 프로그램을 client로 사용했습니다.
w5100버스모드는 direct모드

문의점

  1. client에서 보드로 파일 전송시 속도저하(1MB전송시간 대략1분)
  2. 데이터소켓이 1번일때와 2번일때 동작이 달라지는 이유

안녕하세요!

올려주신 파일 확인했습니다.
올려주신 파일에 대한 몇가지 질문이 있습니다.

  1. Passive모드를 사용했다고 하셨으나, main함수에는 ftp.mode가 Active모드로 되어있습니다.
  2. 데이터 소켓에 따라 동작이 달라진다고 하셨는데, main함수에 있는 ftp.data는 사용되지 않는것으로 보입니다.

여기서 몇가지 확인해주셨으면 하는 사항!!!

  1. Client에서 Board로 전송할때 재전송 발생여부(wireshark 무료툴로 확인가능)
  2. 컨트롤 소켓이 '0’이 아닌 다른 소켓으로 세팅되어있을 경우(ex. ‘3’)에 데이터소켓에 따른 동작(or 속도)이 달라지는지 여부
  3. 컨트롤 소켓이 '0’일때 데이터소켓이 '3’일 경우 속도가 어떤지
  4. sysinit를 이용하여 Tx/Rx buf size를 결정하는 과정에서 소켓별로 정확히 size가 정해져 있는지 확인.

위의 사항을 확인해 주세요

thanks :slight_smile:

  1. client를 passive모드로 설정하여 client에서 pasv명령을 받아 passive모드로 전환됩니다.
  2. ftp.contrl 소켓은 client에서 명령을 받거나 상태신호를 보낼때 사용합니다.
    ftp.data 소켓은 control소켓으로 전송명령을 받은후 파일리스트나 파일내용을 주고 받을 때 사용합니다.

확인사항

  1. wireshark에서 재전송이 발생하는지 알려면 무엇을 봐야하는지 알려주셨으면 합니다.
  2. 컨트롤 소켓이 1이나 3인 경우는 tcp까지 연결은 되나 client로 응답을 보내면 내용이 바뀌어 전송됩니다.

U0_printf(“(connected:%d)\r\n”, ftp.control); ← 여기까지는 연결됨
fsprintf(ftp.control,banner,HOSTNAME, VERSION); ← 데이터가 client로 제대로 전송되지 못함
’ 0이나2인경우 : 220 W5100 FTP version 1.0 ready.
’ 1이나3인경우 : Ef0핁準6?쾡 "Da굇뗦?洌6
'모니터링은 EthernetHost(cafe.naver.com/elab)라는 프로그램사용
3. 컨트롤 소켓이 '0’이고 데이터소켓이 '3’일 경우도 속도느림
4. NetInin함수 내에서 정의함
’ sysinit(MY_NET_MEMALLOC, MY_NET_MEMALLOC); //MY_NET_MEMALLOC : 0x55

안녕하세요~!

특정한 소켓만 동작을 안한다는 것은 저희 칩의 이상은 아닌것이라 판단됩니다.
해당 코드의 오류로 보는 것이 맞을 것 같습니다.

보내주신 코드로 테스트를 하려고 하니 저희 EVB보드의 MCU과 달라 테스트를 해볼수 없는 실정입니다.
해당소켓의 사이즈가 제대로 들어가지 않을 가능성도 있기 때문에 아래의 부분을 확인부탁드립니다.

sysinit함수내에 시리얼로 확인부탁드립니다.
확인1 : TMSR/RMSR 에 Write한 후 값 확인

	IINCHIP_WRITE(TMSR,tx_size); /* Set Tx memory size for each channel */
	IINCHIP_WRITE(RMSR,rx_size);	 /* Set Rx memory size for each channel */

/*확인1*/	
printf("Channel : TX SIZE :%X, RX SIZE : %X \r\n", IINCHIP_READ(TMSR), IINCHIP_READ(RMSR) ) ;

확인2 : SSIZE/RSIZE설정 다한후 확인

#ifndef __DEF_IINCHIP_DBG__

/*확인2*/		
printf("%d : %.4x : %.4x : %.4x : %.4x\r\n", i, (uint16)SBUFBASEADDRESS[i], (uint16)RBUFBASEADDRESS[i], SSIZE[i], RSIZE[i]);

#endif

thanks :slight_smile:

확인1
Channel : TX SIZE :55, RX SIZE : 55

확인2
0 : c000 : e000 : 0800 : 0800
1 : c800 : e800 : 0800 : 0800
2 : d000 : f000 : 0800 : 0800
3 : d800 : f800 : 0800 : 0800

감사합니다.

전송속도가 느릴경우와 빠를경우의 패킷을 캡쳐하여 support@wiznet.co.kr 메일로 보내주시면
전송속도 관련 문제에 도움이 되겠습니다.
감사합니다.

와이어샤크로 캡쳐한 데이터를 보내드리니 검토 부탁드립니다.
192.168.10.53 : PC(Client)
192.168.10.54 : Board(Server)

참고로 파형을 출력해 측정해본결과 수신버퍼의 크기가 1이상될때까지 시간이 너무 오래 걸렸습니다.측정파형도 보내드립니다.

수신버퍼가 1이상될때까지의 시간 : 200ms
수신된데이터를 처리하는시간 : 340us
while (1)
{
if (getSn_SR(ftp.data)==SOCK_ESTABLISHED)
{
PORTG&=0xf7; <-----파형 LOW
if((len = getSn_RX_RSR(ftp.data)) > 0) <----len이 1이상이 될때까지 시간이 많이걸림
{
PORTG|=0x08; <-----파형 HIGH
if (len > MAX_BUF_SIZE) len = MAX_BUF_SIZE;
recv(ftp.data, rx_buf, len);
rx_buf[len] = ‘\0’;
//tlen = tlen + len;
}
}
else
{
disconnect(ftp.data);
break;
}
}
ftp-15.zip (130 KB)

아래의 사항을 추가로 변경하시면 전송속도 향상됩니다.
단, Socket Open이전에 설정하셔야 합니다.

  1. Sn_MR의 No Delayed ACK(bit 5) 활성화
  • 만약 이 Bit가 ‘1’로 set되어있다면 peer로부터 데이터 packet을 수신한 다음 곧바로 ACK packet이 전송되어 전송속도가 빨라집니다.
  1. Sn_TX_FSR, Sn_RX_RSR 변경
  • 소켓을 하나만 쓸경우 소켓 버퍼를 2K가 아닌 4K or 8K로 변경하면 전송속도가 빨라집니다.

위의 사항을 적용해서 전송속도를 확인해 주세요.

정말 감사합니다.
ACK 비트를 1로 하니 정상속도로 전송이 됩니다.
수고하십시오

이번 건은 결론적으로 TCP 프로토콜 자체의 flow control
즉, 상대방의 수신 버퍼가 넘치지 않도록 하는 동작 때문에 발생을 한 것으로 보여집니다.

TCP 프로토콜을(FTP는 TCP기반 프로토콜) 사용하는 경우,
데이터 전송을 할 때는 상대의 수신 버퍼 사이즈 만큼 보내고 전송을 대기하게 됩니다.
W5100은 수신 버퍼 사이즈가 2~8KB 정도이므로, 데이터 패킷 2개 정도로도 금방 채워질 수 있습니다.
그래서, W5100에서 수신 버퍼 사이즈의 변경내용을 최대한 빨리 송신쪽에 알려주어야 속도를 유지할 수 있는데
NO Delayed ACK 옵션을 enable 하지 않으면, 내부 타이머에 의해서 일정 시간(초기값은 200ms) 마다 이 정보 패킷을 보내게 됩니다. 따라서 송신쪽에서는 이 정보 패킷을 받은 이후에 전송을 할 수 있게 되어 속도 저하 증상이 발생한 것입니다.
앞서 제시한 바와 같이 NO Delayed ACK 옵션을 enable하면 RECV command에 의해서도 이 정보 패킷이 전송이 되어 속도 향상이 됩니다.

일반적인 Application의 경우, 양쪽이 다 데이터를 송수신하는 경우가 많아서 이런 증상을 보이지 않습니다.
왜냐하면 데이터 송신 패킷에도 수신 버퍼 사이즈에 대한 정보가 포함되어 있으므로, 별도의 정보 패킷을 전송하지 않아도 큰 속도 저하가 발생하거나 하지 않습니다. :slight_smile:

(참고로 NO Delayed ACK 옵션은 네트워크 상의 쓸모없는 패킷의 수(데이터를 포함하지 않은 패킷)를 줄이기 위해 disable 되어 있습니다.)