cl_cmdrate "128"
cl_updaterate "128"
rate "128000"
cl_interp "0"
cl_interp_ratio "1"
글옵 네트웤 관련 최적 콘솔라고 올라 온 값이다. (최적이라...)
정확한 표현은 최적이 아니라 지원하는 '최고 범위'를 나타내는 값이다. 네트워크 풀옵 정도?
사람들이 PC 사양에 따른 옵션 타협은 당연한 것 처럼 말하면서
네트워크는 모두 동일한 값을 최적이라 말한다.
지역/대륙이 다르고 인터넷 성능이 다른데 어떻게 다 동일한 최고값들을 사용하지.
당연히 의심해야하는 부분인데 인식조차 안한다.
모두 동일 값을 사용할 때의 공정성은 절대 존재하지 않는다.
근처에 서버가 존재하는 유저가 최적화 작업까지 해버리면 핑(ping) 격차는 더욱 커지게 된다.
지리적/환경적인 요소들은 우리가 어찌 개선할 순 없지만,
조금이라도 그 차이를 극복하기 위해서 핑 간격을 줄여나가는 작업은 할 수 있겠다.
딱 잘라서 말해서 대한민국에서, 1대1 Lan이 아닌 인터넷으로, 위의 값은, 절대로, 뽑을 수 없다.
(홍콩이나 텍사스로 이주한 뒤, 서버 있는 건물 찾아가서, 직접 렌 연결 해서, 게임하면,
근사치까지는 갈 수 있겠다. 대회장 네트웤 시스템을 생각하면 쉽고.)
저 최고값의 이점은 있는데,
최고값을 잡아 놓으면 그 이하 값으로는 자동으로 서버 tick에 맞추어 date 전송값을 잡는다는 것.
편리할 뿐 아니라 지연률(ping)도 꽤 안정적이긴 하다.
개인적으론 최고값으로 설정시 개인 서버에서 게임하게 되면 5ms 정도 안정된 지연률을 출력한다.
이제 지연률을 0ms로 맞추려한다.
Fake Ping이는 말을 들었는데, 그것의 응용인지는 모르겠다.
난 익히 알고 있던 방식으로 최적화 작업을 하는데, 일련의 작업이 fake ping이라 말하는 것과 동일한 듯.
예전 cs 1.6 당시에도 이미 나 돈 팁인데, 최근 들어서는 이와 관련된 글을 구경해 본 적이 없다.
한번 작성해야지 하면서도 이 글을 이제서야 작성하는 이유를 간단히 든다.
1. 지연률 관측과 설정을 위해서 개인 서버가 필요하다.
(cmd 도스창 열고 서버 아이피 들어가서 핑 관측하는 방법이 있던 것 같은데, 난 방법 모른다.)
아마 이 탓에 대다수의 일반 유저가 접근하기 어려운 듯하다.
2. 초기에 글옵들어와서 fake ping 설정을 하게 되면 interp 0.00.1 설정한 것과 같은 버그가 있었다.
글옵 들어와서 fake ping 설정이 꼭 버그를 사용하는 것 같은 인식이 생긴 것 같아서 작성이 꺼려졌다.
3. 글옵 들어오면서 포럼부터 시작해서 지연을 줄이는 글이 많이 부실하고 양도 적다.
자료가 너무 적다보니까 '이거 내가 뭐 잘못 알고 있는 것인가' 소심해진다.
(지금도 살짝 불안하다.) 오히려 L4D 쪽에서 fake ping에 대한 글들이 많다.
[Ping : 0ms]
1. 일단 autoexec.cfg에 네트워크 설정을 잡아준다.
cl_cmdrate "+128"
cl_updaterate "+128"
rate "128000"
cl_interp "0"
cl_interp_ratio "1"
지연 줄이는 방법을 간단하게 설명하면,
update/cmdrate를 서버에서 지원하는 이하로 포기하면서 대신 지연을 줄이는 방법이 되겠다.
rate 수정은 스크립트를 만들어 서버 상황에 맞추어 설정할껀데,
그 전에는 위와 같이 지원하는 최대치로 자동 잡는 값을 autoexec.cfg에 추가한다.
숫자 앞에 +가 뭔지 정확하게는 설명을 못하겠다. fake ping이라고 검색해서 보면
죄다 저렇게 하길래 따라하고는 있는데, + 하고 안하고 차이를 모르겠다.
참고로 숫자 없이 'cl_cmdrate -/cl_updaterate -'를 입력하면 서버 지원 최소 rate값을 찾아간다.
(서버 최소값은 server.cfg에 mincmd/minupdaterate로 결정된다. 최소는 update/cmd 10부터)
2. 자신의 서버에 들어간다.
motd 화면이 나오면 'GO'를 누르지말고, 그 화면 띄워 둔 상태에서 cl_updaterate값을 조정한다.
motd, 팀 선택 화면을 패스하고 서버에 접속한 뒤에는 updaterate 값 수정이 불가하다.
motd 화면 띄워둔 상태로 update를 계속 낮춰가면서 지연률 ms가 줄어드는 것과 변화를 관찰한다.
로스/초크 값은 당연히 0 유지해야한다.
cmd/update 값이 동일한 대칭형이 익숙할텐데, 개인적으로는 글옵 들어와서는 대칭 설정이 안된다.
cmd값은 update와 최소 동일해야하고 현재 환경 내에서 ping 0ms를 만드는 가장 높은 값이 좋다.
글옵에서 cmd와 update는 동일하거나 20 이상 차이는 나지않는다. (cmd≥update)
cmd ≥ up이 아닌 cmd < up 비대칭은 핑이 상승하게 된다. (당연히 처리한 것 이상 못 올린다)
개인적으론 억지로 대칭값으로 만드려고 해봤지만 핑이 상승하지 않는 대칭값을 못찾았다.
(인터넷 사양에 따라 다른건지 글옵 네트웤 설정 정책이 그런 건지 모르겠다)
어쨌든 결국 비대칭으로 맞춰 0ms 나오는 수치를 찾았는데,
128tick 서버에서 cl_cmdrate "+50" /cl_updaterate "+30" 값이였다. (pingboost 3 당시의 값.)
(지원은 128까지 하는데, 이상과 현실의 갭을 보소... 지금 글이 흐린건가 내 눈에 눈물이 고인건가)
개인적으로 쩜육에서 50/50이였던 걸 봤을 때 글옵은 착한 값은 아닌 것 같다.
0ms되는 값 근처로 서버 안에서 net_graph ping 변화에 주목하며 찾아간다.
128tick 뿐 아니라 이하 서버 tick에 맞춰서 자신의 서버 tick을 조절하며 작업한다.
개인적으로 64tick은 cl_cmdrate "+40"/ cl_updaterate "+20" 이다.
재미있는 게, 최소 up 10/ cmd 30도 0ms로 되긴하는데, 역핑이라고 해야하나,
0ms 임에도 역으로 딜레이가 생긴다. 그래서 update는 최소 20부터 잡아주고 있다.
(공식 매치 서버 정책은 sv_mincmdrate 30)
자신의 서버 안에서는 1ms도 안되고 반드시 0ms에 고정되게 맞춰야한다.
(아주 가끔 인터넷 컨디션이 나쁘거나 서버 다시 읽는 시점에서 핑이 잠시 튀는 건 괜찮다)
어중간하게 손대면 오히려 128 최고값을 준 것 보다 핑이 솟구치는 걸 볼 수 있다.
이래서 서버 없는 대다수의 유저들에게 128이 최적화된 값이라고 소개하는 것인지도 모르겠다.
128이 5ms에서 고정되는 걸 보면 안정성도 좋다.
그런데, 이 글은 안정성/평균적인 값을 뽑는 게 아닌 최적에 접근하는 글이다.
자신의 서버에서 0ms를 맞췄다면 자신의 네트워크 환경이 허용하는 최적값이다. (절망적이구만...)
이렇게 설정해서 다른 서버 넘어가면 최저 지연률을 얻을 수 있다.
참고1: 간혹 minupdaterate를 걸어서 높은 값으로 잡게 된 서버들이 보인다.
이때는 자기 개인 서버에서 잡은 최소(최적)값이 인식되지 않는데,
자신의 서버를 같은 조건으로 맞췄을 때 0ms 맞추는 게 불가능한 상황이 벌어지고,
현 서버에서 지원하는 최소 update 값에 맞춰서 최소 지연률을 찾는게 최선이다.
(타 서버에서 죽치고 찾으란 게 아니라 같은 조건으로 자기 서버 안에서 맞추라는 말이다.
지연률 변화에 안정적인 본인 서버가 아니면 절대로 최적값을 찾을 수 없다.)
참고2: 서버 pingboost로 인한 최적값이 다르게 나올 수 있다.
잠시 핑 부스트를 설명하면,
사용하게 되면 확실히 핑이 낮아진다. (좀 더 높은 cmd/update 값으로 동일 핑 연출이 가능)
종류는 pingboost 1/2/3이 있고, srcds 파일 속성에 넣어 적용하게 된다.
보통 2와 3을 사용하게 되는데 3이 같은 데이터 값에서 가장 낮은 핑을 보여준다.
그런데 왜 많은 유저들이 2를 사용하는가하면,
3이 프로세서를 미친듯이 사용하기 때문이다. cpu 태울 기세로 돌아가는데 겁이 좀 난다.
물론 아이브릿지 이상급 프로세서로 올라서면 3 구동 자체엔 문제가 없어 보인다.
하지만 사용하다가 혹시 프로세서가 버거워하거나 이상 현상이 생기면 바로 내려줘야한다.
2가 가장 안정적이다. 다만, 0ms를 만들기 위해서 더 낮은 값을 사용해야하지만... (으아아아)
(일반 pc는 2, 서버 컴 정도 되면 3 하면 될 것 같다.)
3. 각 tick별 스크립트 파일을 만든다.
여러 tick 서버에 접속해야하기 때문에 정보를 스크립 파일화 해두면 편하다.
본문 제일 하단에 '추가 내용'을 보면 자동값 적용법이 있어서 이 과정이 필요 없어보이지만,
기능 이해와 연습 샘치고 이 과정을 보는 것도 괜찮다.
스크립트 파일 만드는 건 어려운 게 없다.
메모장을 열고,
cl_cmdrate "+수치"
cl_updaterate "+수치"
기타 네트웤 관련 콘솔 명령어 등등
작성한 뒤에 저장을 '원하는 파일명.cfg', 텍스트가 아닌 모든 파일로 저장해주면 된다.
그리고, valve.rc 파일을 메모장으로 열어서
// load the base configuration
exec default.cfg
// Setup custom controller
exec joystick.cfg
// run a user script file if present
exec autoexec.cfg
// Netsettings
exec 앞서 작성한 파일명.cfg
//
// stuff command line statements
//
stuffcmds
이렇게 추가 설정해주면된다.
서버에 접속하고 motd 화면에서 콘솔창 열고 'exec 파일명' 해주면 스크립트 파일 정보가 읽어진다.
Fake Ping 이라는 말이 타 서버 (공용 서버)에서 1~5 낮은 핑으로 표시되는 걸 보고 나온 말 같다.
과거 과장되어서 낮춰진 ping을 일컫는 말인 줄은 모르겠지만,
최근 업데이트된 글옵 들어와선 그 기능보다 지연률을 낮추는 본연의 기능만 남은 것 같다는 인상이다.
판정 부분은 어느 지연부터는 워낙 찰나의 차이라서 솔직히 판단은 못하겠고,
난 지연이 낮을 때의 모니터나 마우스와 같은 장치의 입출력 지연이 확연히 줄어드는 걸 본다.
다만, 지원해주는 것에 한참 밑도는 데이터를 처리하고 올리게 되어 게임이 매끄럽지는 않다.
가끔 덜덜거리는 느낌도 있고 화면이 튀는 현상도 보이고, 눈이 피곤하다.
(카스가 원래 히트박스와 판정을 일치 시킨 리얼 타임에 근접할 수록 덜덜거린긴 한다)
이상적인 셋팅이라면 tick에 맞춰 cmd/update 그리고 fps 까지 동일하게 설정하는 것일텐데,
지금까지 본 최적 값으로는 글옵 최저 고정 프레임 58에도 미치지 못하는 데이터 양이라 성립이 안된다.
타협점으로 tickrate에 맞춰서 fps는 맞춰봤다.
이러지 안하면 100hz 이상 지원하는 모니터를 사용하는 이유가 없어지니까.
서버 tick 지원하는 만큼 데이터처리하면서 부드러운 게임을 할 것인가 (지연률은 좀 오르더라도),
그 부분은 포기하면서라도 지연을 낮춰보려고 발악을 하거나.
선택해야하는 문제지, 필수 팁이 아니다.
(이미 개인 서버 필요에서부터 7, 8할은 나가 떨어졌을텐데, 필수는 무슨 필수.)
[추가 내용]
일일이 서버 tick 수치에 맞춰 스크립트 파일 만들 필요는 없다.
처음에는 기능을 이해하느라 tick별 스크립트 파일들을 일일이 다 만들었는데,
서버 설정에 맞춰 유저 설정이 자동값을 찾을 수 있게 유도하는 파일 하나만 만들면 된다.
온라인과 오프라인 전용 셋팅, 이 정보를 담은 스크립트 2개만 만들면 된다.
[온라인용, 파일명: 0ms.cfg]
cl_cmdrate +128
cl_updaterate +20
cl_interpolate 1
cl_lagcompensation 1
sv_lan 0
[ 오프라인, 파일명: 128Lan.cfg]
cl_cmdrate +128
cl_updaterate +128
cl_interpolate 0
cl_lagcompensation 0
sv_lan 1
스크립트 파일을 만든 뒤 valve.rc에는 0ms.cfg/ 128Lan.cfg를 인식 시켜주면 된다.
