주의 컴퓨터가 열심히 일하는 중이라 부정확할 수 있습니다. 전 전문가가 아닙니다.
목적 자체가 grid engine끼리 데이터를 많이 옴기고 있어서 속도를 올리고 싶어서 시도를 하다보니 그렇습니다.
일단 시스템을 설명드립니다.
컴퓨터 1 : B150M-HDV온보드 CPU는 I7-6700 수치해석 프로그램 4프로세스(총 4쓰레드)돌고 있습니다.
허브 : gs324 (v1으로 보이며 최대 9016의 점보프레임 지원)
컴퓨터2 : B550m Phantom Gaming 4 온보드랜 cpu는 5900입니다.
두대사이의 속도는 iperf툴을 사용했습니다.
컴2 > iperf -s [서버모드 실행] 컴1 > for i in `seq 1500 250 9000`; do sudo ip link set enp2s0 mtu $i; sleep 3; echo $i >> result ; timeout 15s iperf -c computer 2 -d |grep Bytes >> result; done
양방향 테스트를(Full duplex test) 처음에 9k 점보로 바꾸고 했다가 결과가 너무 이상해서 시작한거라 단방향 테스트는 없습니다.
양방향에서 빠른 부분을 참조하시면 얼추 맞습니다.
결과는 아래처럼 나옵니다. 순서가 바뀔 수 있으나 보내기 받기 순으로 나온거만 확인해서 그냥 씁니다.
1500
[ 5] 0.0-10.0 sec 1.04 GBytes 892 Mbits/sec [ 4] 0.0-10.0 sec 1019 MBytes 852 Mbits/sec 1750 [ 5] 0.0-10.0 sec 1.06 GBytes 910 Mbits/sec [ 4] 0.0-10.0 sec 1.02 GBytes 871 Mbits/sec 2000 1500 [ 5] 0.0-10.0 sec 1.04 GBytes 891 Mbits/sec [ 4] 0.0-10.0 sec 1023 MBytes 855 Mbits/sec ......
보기 불편해서 표로 정리해봤습니다. 중간에 빈값들은 에러가 났슨데 다시 얻을 필요가 있나 싶어서 그냥 두었습니다.
iperf는 에러가 나면 그냥 멈춰서 Shell script로 처리하기 그렇습니다. 그래서 timeout이라는 명령어가 들어갔습니다.
| MTU | 보내기 | 받기 | 합산 이득 |
단반향 이득 |
MTU | 보내기 | 받기 | 합산 이득 |
단반향 이득 |
MTU | 보내기 | 받기 | 합산 이득 |
단반향 이득 |
| 1500 | 892 | 852 | 1.00 | 1.00 | 3750 | 925 | 899 | 1.05 | 1.06 | 6750 | 955 | 73.8 | 0.59 | 1.07 |
| 1750 | 910 | 871 | 1.02 | 1.02 | 4000 | 918 | 849 | 1.01 | 1.03 | 7250 | 961 | 27.1 | 0.57 | 1.08 |
| 1500 | 891 | 855 | 1.00 | 1.00 | 4250 | 921 | 843 | 1.01 | 1.03 | 7500 | 960 | 7.45 | 0.55 | 1.08 |
| 1750 | 919 | 862 | 1.02 | 1.03 | 4750 | 916 | 791 | 0.98 | 1.03 | 7750 | 972 | 4.27 | 0.56 | 1.09 |
| 2250 | 935 | 874 | 1.04 | 1.05 | 5000 | 882 | 780 | 0.95 | 0.99 | 8000 | 974 | 3.41 | 0.56 | 1.09 |
| 2500 | 932 | 885 | 1.04 | 1.04 | 5250 | 883 | 790 | 0.96 | 0.99 | 8500 | 974 | 3.03 | 0.56 | 1.09 |
| 2750 | 927 | 888 | 1.04 | 1.04 | 6250 | 948 | 187 | 0.65 | 1.06 | 8750 | 978 | 2.26 | 0.56 | 1.10 |
| 3250 | 932 | 892 | 1.05 | 1.05 | 6500 | 950 | 138 | 0.62 | 1.07 | 9000 | 978 | 2.27 | 0.56 | 1.10 |
결과를 해석해보자면, 좋은 컴퓨터에서는 적당히 mtu값을 올리면, 5%정도의 이득을 볼 수 있습니다.
대략 3500언저리로 보입니다. 마침 그자리 값이 없어서 단독 실행을 해봤더니, 931/898이 나옵니다.
또 재미 있는 부분이 4000을 넘고 5000을 넘는 지점입니다. 고점을 어디선가 찍고 쭉내려오기 시작하다가,
4750부터 한쪽 방향이 mtu1500보다 못하기 시작합니다. 그대신 6000부터 보면, 단방향 속도가 꾸준히 올라갑니다.
결국 80Mbit/s 10%정도의 이득을 얻습니다.
뭔가 허브의 문제인지 컴퓨터 드라이버의 문제인지 무엇의 문제인지 모르겠지만, 점보프레임이 올라감에 따라,
Full-duplex를 포기하고 일시적으로 Half-duplex의 통신형태로 돌아가는 걸로 판단이 됩니다.
받기 속도가 2Mbit는 너무합니다.
여러번은 아니지만 9000에서는 단방향 테스트에서 980정도 나왔어서 이런판단을 하게되었습니다.
사실 grid computing이나 torrent가 아니고서는 업로드 다운로드 속도를 풀로 땡기는 일은 거의 일어나지 않습니다.
그래서 단방향 테스트를 수행하려고 테스트를 했으나, 이 테스트들이 가정용 컴퓨터의 메인보드 온보드 랜에게는 가혹했는지.
계속해서 연결을 잃어버려서 당장은 테스트가 불가능합니다.
갑자기 머리속에서 dhclient라는 명령이 생각이 안나서 폰을 찾아서 겨우 다시 인터넷 연결했습니다.
결론입니다. 점보프레임을 올리면 성능향상은 있다. 양방향 최고 부하테스트에서 단방향 이득을 약 10%까지도 얻을 수 있다.
다만, 어느 순간, 단방향으로만 빨라지며 양방향 전송능력이 약해진다.
부족한 부분은 컴퓨터가 멀쩡할 때, 테스트를 해보겠으며, 다만 예측하기로는, 9000의 점보프레임까지 계속해서 상승할 것으로 보이며 대략 10%의 이득까지 얻을 수 있을 것으로 보인다.
환경에 따라 성능 이득이 있을 수도 있고
환경에 따라 성능 이득이 미미할 수도 있더라구요
특정 구역에 한쪽 성능이 떨어지는 것도 있고
내부에 모든 노드들이 점보 프레임을 지원해야 이득이 있는데
단 하나라도 점보 프레임을 지원 하지 않으면 거기가 병목현상 때문에 이득이 미미할 수도 있더라구요
그런데 점보 프레임을 사용해서 이득을 보려면 아래와 같은 조건이 필요 합니다.
1. 데이터가 지나가는 구간이 모두 점보프레임(9K)을 지원해야 합니다.(클라이언트 - 스위치(라우터)- 서버)
2. 애플리케이션이 점보프레임을 지원해야 합니다.
위 조건을 만족하지 않으면 오히려 데이터를 분할하는 과정이 더해져서 효율이 더 좋지 않게 됩니다.
그래서 점보프레임은 내부구간에서 사용합니다. 집에서 사용한다면 NAS와 PC 간 설정해서 쓸 수 있고 중간 허브나 스위치도 점보프레임 설정을 해줘야 합니다.
외부 인터넷 구간은 대부분의 MTU가 기본 1500 이므로 점보프레임을 설정해도 이득을 보기는 어렵습니다.
해당 구간의 MTU를 확인해 보는 방법은 ping -f 옵션으로 fragment하지 않게 하고 -l 옵션으로 사이즈를 변경하여 ping이 어느 사이즈까지 되는지 보면 됩니다.
보통 28바이트 헤더가 붙기 때문에 MTU 1500 인경우 ping -l 1472 -f x.x.x.x 하면 통신이 되고 사이즈를 그 이상 하면 DF설정 되어 있다면서 안될 것입니다.
ping 테스트 해봤습니다.
9000-28로 해봤습니다.
다른사람은 어떤지 모르겠지만, 일단 저같은 경우야 허브로 다 연결되어 있고 허브는 9k지원을하고
ping테스트도 만족을 합니다.
이더넷이란거 자체가 cpu를 쓰다보니까... 2.5g 5g 10g는 되야 cpu가 패킷나누는 작업에 부담을 느끼려나 봅니다.
블로그에서 점보프레임잔 150정도에서 점보프레임 후 230Mbit 나오는거 보고 한번 해봤는데 cpu가 최대석도도 못낼 정도로 버벅거리는 상황이 되야하는겈지 참