🤍
😀컴덕814
24일 전

🗨️ 펌) 점보 프레임뽕이 와서 과연 유용한가 테스트를 해보았습니다

주의 컴퓨터가 열심히 일하는 중이라 부정확할 수 있습니다.  전 전문가가 아닙니다. 

 목적 자체가 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%의 이득까지 얻을 수 있을 것으로 보인다. 

 

 

✔️ 자세히 알아보기 URL (More information) ↓https://www.clien.net/service/board/lecture/16676008

점보 프레임뽕이 와서 과연 유용한가 테스트를 해보았습니다. : 클리앙 주의 컴퓨터가 열심히 일하는 중이라 부정확할 수 있습니다. 전 전문가가 아닙니다. 목적 자체가 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%의 이득까지 얻을 수 있을 것으로 보인다. by 클리앙 from WWW.CLIEN.NET

 

413
0
댓글
0
덕질 비회원은 댓글을 볼 수 없습니다. 로그인을 해주세요.
Deokjil non-members cannot see comments. Please log in.
1 2 3 4 5 6 7 8 9 10
카테고리 즐겨찾기 알림