რას ნიშნავს tick rate სინამდვილეში და რატომ ნელია შენი სერვერი

როცა ვინმე ამბობს, რომ სერვერი იჭედება, ის ოთხი ურთიერთდაუკავშირებელი რამიდან ერთს გულისხმობს და მათგან სამი სერვერი არ არის. Tick rate არის, რამდენად ხშირად ავითარებს სერვერი სამყაროს. Ping არის, რამდენ ხანს მიდის პაკეტი მასთან. Frame rate მოთამაშის საკუთარი გრაფიკული ბარათია. პერიოდული ჩაკიდება ჩვეულებრივ დისკია. თითოეულს საკუთარი რიცხვი აქვს, თითოეულს - განსხვავებული გამოსწორება, და lag-ის გამოკვლევის მთელი საქმე იმის გადაწყვეტაა, რომელ რიცხვს შეხედო, სანამ ფულს დახარჯავ. ეს პოსტი ოთხივეს წაკითხვას აღწერს, თითო თამაშზე ნამდვილი ბრძანებებით.

რა არის tick#

გეიმ სერვერი ფიქსირებული დროის ბიჯის ციკლს უშვებს. ის იღვიძებს, კითხულობს ყველაფერს, რაც კლიენტებისგან ბოლოს შემდეგ მოვიდა, სიმულაციას ერთი ბიჯით წინ სწევს, თითოეულ კლიენტს უგზავნის, რა შეიცვალა მათ სიახლოვეს, შემდეგ კი იძინებს, სანამ შემდეგი ბიჯის დრო არ მოვა. ერთი გავლა ერთი tick-ია. Rate არის, წამში რამდენი უნდა გააკეთოს, ხოლო ბიუჯეტი - რეალური დრო, რომელიც მას ეძლევა.

budget per tick = 1000 ms / target tick rate20 ticks/s  -> 50.0 ms per tick   (Minecraft)50 ticks/s  -> 20.0 ms per tick   (many Unreal servers)64 ticks/s  -> 15.6 ms per tick   (Counter-Strike 2)128 ticks/s ->  7.8 ms per tick   (competitive Source servers)

თუ tick ბიუჯეტზე ადრე მთავრდება, სერვერი იძინებს და არავინ ამჩნევს. თუ უფრო დიდხანს გრძელდება, შემდეგი tick გვიან იწყება და ყოველი მომდევნო ვალს მემკვიდრეობით იღებს. რას ხედავენ მოთამაშეები, ძრავზეა დამოკიდებული. Minecraft სამყაროს ანელებს: დღე უფრო გრძელი ხდება, ღუმელები უფრო ნელა ადნობენ, mob-ები ნელი კადრებით მოძრაობენ და ყველაფერი შიგნიდან თანმიმდევრული რჩება, რადგან მთელი სიმულაცია გაწელილია. Shooter-ები ჩვეულებრივ რეალურ დროს ინარჩუნებენ და ინფორმაციას აგდებენ, ამიტომ სამყარო სწორი სიჩქარით მიდის, მაგრამ განახლებები უფრო იშვიათად მოდის და hit registration ბუნდოვანი ხდება.

ორი შედეგი გასახსენებელია. პირველი: ეფექტი გლობალური და თანაბარია - როცა tick rate ეცემა, ყველასთვის ერთდროულად და ერთი და იმავე ოდენობით ეცემა. ერთი მოთამაშის საჩივარი, როცა სხვას არაფერი ეტყობა, არასოდეს არის tick rate-ის პრობლემა. მეორე: ბიუჯეტი რეალური დროის რიცხვია, ამიტომ ყველაფერი, რაც მთავარ ნაკადს ბლოკავს, მას ხარჯავს: garbage collection-ის პაუზა, სინქრონული დისკზე ჩაწერა, plugin, რომელიც მონაცემთა ბაზის მოთხოვნას ადგილზე ასრულებს. ეს CPU-ს ნაკლებობა არ არის და უფრო სწრაფი CPU მათ არ გამოასწორებს.

Tick rate-ები თამაშების მიხედვით#

ამ სიაში რამდენიმეს შენიშვნა სჭირდება. Counter-Strike 2 64 tick სერვერს უშვებს, მაგრამ მოთამაშის input-ს ტოვებს იმ მომენტის დროის ნიშნულით, როცა ის tick-ებს შორის რეალურად მოხდა, სწორედ ეს არის "sub-tick" - ის 128 tick სერვერების უპირატესობის უმეტესობას ხსნის CS:GO-ში, და ამიტომ ძველი კამათი tickrate-ზე CS2-ში ნაკლებ მნიშვნელოვანია, ვიდრე წინა თამაშიდან მოსულები ელიან. Source-ის თამაშები rate-ს გაშვებისას -tickrate-ით აყენებენ და მისი შეცვლა მოძრაობის ფიზიკას ცვლის, ამიტომ 100 tick სერვერი უბრალოდ უფრო გლუვი 66 tick სერვერი არ არის.

Valheim გამონაკლისია და მისი გაგება ღირს, რადგან ის დამაბნეველი ანგარიშების მთელ კლასს განმარტავს. სერვერი სამყაროს ინახავს და მდგომარეობას გადასცემს, მაგრამ თითოეულ ზონას მოთამაშე ასიმულირებს, რომელიც პირველი შევიდა მასში. ერთი სერვერის tick, რომლის წაკითხვაც შეიძლებოდა, არ არსებობს და ცუდ კავშირზე მყოფი ერთი მოთამაშე სამყაროს ყველასთვის არყევს, ვინც მის გვერდით დგას. ეს აღწერილია Valheim-ის dedicated სერვერის გზამკვლევში.

რიცხვის წაკითხვა#

არასოდეს დააყენო დიაგნოზი მოთამაშის აღწერით. რიცხვი მოიპოვე.

Minecraft, Paper ან Spigot. /tps ბეჭდავს ერთი, ხუთი და თხუთმეტი წუთის საშუალოებს, 20-ით შემოსაზღვრულს. ეს მოგვიანებული ინდიკატორია: სერვერი, რომელიც ერთი tick-ისთვის 300 ms-მდე ავიდა, მაინც 20-თან ახლოს კითხულობს. Paper-ის /mspt უკეთესი რიცხვია, რადგან ბოლო ხუთი წამის, ათი წამისა და ერთი წუთის რეალურ tick-ის დროებს აჩვენებს, საშუალოთი და უარესი შემთხვევით.

> /msptServer tick times (avg/max) from last 5s, 10s, 1m:◴ 41.2/188.9, 38.7/188.9, 22.4/241.6

ეს ასე წაიკითხე: ჩვეულებრივ კარგია, მაგრამ რაღაც ხანდახან თითქმის მეოთხედ წამს ხარჯავს. 50-ზე ნაკლები საშუალო უზარმაზარი მაქსიმუმით ნახტომების პრობლემაა - chunk-ი გენერირდება, სამყაროს შენახვა, plugin ტაიმერზე - და მას პროფაილერი სჭირდება და არა უფრო დიდი გეგმა. Vanilla 1.20.3-მა და შემდეგმა დაამატა /tick query, რომელიც იმავეს ბეჭდავს, პლუს /tick freeze, /tick step და /tick sprint გამართვისთვის.

Minecraft, ნებისმიერი ვერსია, როცა მიზეზი გჭირდება. დააყენე spark. /spark tps იძლევა tick rate-ს და CPU-ს გამოყენებას თითო ნაკადზე; /spark profiler start სერვერს გარკვეული პერიოდით ნიმუშავს და აწარმოებს ვებ ბმულს, რომელიც აჩვენებს, რომელი მეთოდი ჭამს tick-ს. სწორედ ეს ბმულია განსხვავება გამოცნობასა და ცოდნას შორის, ხოლო spark-ის პროფილის კითხვა ერთს ხაზ-ხაზ გადის.

Source-ის თამაშები. კონსოლში stats ბეჭდავს ხაზს, რომელიც სერვერის FPS-ს შეიცავს, ანუ მის tick rate-ს, პლუს CPU-ს გამოყენებასა და გამტარუნარიანობას. status ჩამოთვლის მოთამაშეებს მათი ping-ით. ორივე კონსოლის ბრძანებაა, ამიტომ RCON-ითაც მუშაობს.

> statsCPU    NetIn   NetOut  Uptime  Maps   FPS      Players12.40  0.9     4.7     412     3      66.14    18

Unreal სერვერები. Squad თავის tick rate-ს სერვერების browser-ში ბეჭდავს. სხვა Unreal-ზე დაფუძნებული თამაშები კონსოლში ან ადმინისტრაციულ ინსტრუმენტებში სერვერის FPS მნიშვნელობას აჩვენებენ. ყველა მათგანში რიცხვის დაცემა სერვერის შევსებასთან ერთად ნორმალური, მოსალოდნელი ფორმაა და შენ იმას აფასებ, სად დასრულდება პიკზე.

ყველაფერი დანარჩენი. თუ თამაში tick მთვლელს არ აჩვენებს, შემცვლელი CPU-ს გრაფიკია. თავის ლიმიტზე მიჯაჭვული თამაშის ნაკადი ბრტყელი მეხსიერების ფონზე არის სერვერი, რომელსაც tick-ის ბიუჯეტი ამოეწურა, როგორც არ უნდა ერქვას ამას თამაში. სერვერის დატვირთვის გრაფიკის კითხვა ფორმებს აღწერს.

Ping სრულიად სხვა რიცხვია#

Ping არის ერთ მოთამაშესა და სერვერს შორის წრიული გზა. ეს ორ მანქანას შორის გზის თვისებაა - მანძილი, მარშრუტი, თითოეული hop-ის ხარისხი - და სერვერს მასზე თითქმის გავლენა არ აქვს. მეხსიერების, CPU-ს ან NVMe-ის არანაირი რაოდენობა მოთამაშის ping-ს არ ცვლის.

დიაგნოსტიკა ტრივიალურია: ერთდროულად ყველას ping შეხედე. თუ ერთი მოთამაშე 180 ms-ზეა, დანარჩენები 30-ზე, ამ მოთამაშეს ქსელის პრობლემა აქვს და სერვერი კარგადაა. თუ ყველა ერთდროულად ერთი და იმავე ოდენობით გაიზარდა, რაღაც შეიცვალა სერვერის მხარეს ქსელში, რაც სხვა და გაცილებით იშვიათი რამაა.

"Ping"-ში სამი რიცხვი იმალება და ისინი ურთიერთშემცვლელი არ არის:

• Latency არის საშუალო წრიული გზა. მაღალი, მაგრამ სტაბილური latency სათამაშოა; თამაშები მუდმივი დაყოვნების დასამალად არის აგებული.
• Jitter არის ვარიაცია. 60 ms latency, რომელიც 40-სა და 200-ს შორის ირხევა, გაცილებით უარესად იგრძნობა, ვიდრე ბრტყელი 120, რადგან კლიენტის პროგნოზი ყოველ კადრზე სხვადასხვა ოდენობით ცდება.
• Packet loss არის განახლებები, რომლებიც არასოდეს მოდის. 1%-ც კი ჩანს, როგორც rubber-banding, რადგან კლიენტმა უნდა გამოიცნოს და შემდეგ გაასწოროს.

Latency, jitter და packet loss განმარტავს, როგორ გაარჩიო ისინი, ხოლო traceroute-სა და mtr-ის კითხვა გიჩვენებს, რომელი hop არის პასუხისმგებელი. მოკლედ: გაუშვი MTR მოთამაშისგან, რომელიც ჩივის, სერვერამდე რამდენიმე წუთის განმავლობაში და მოძებნე პირველი hop, სადაც დანაკარგი იწყება და რჩება.

ინტერპოლაცია, პროგნოზი და lag compensation#

ამ სამის გაგება tick rate-ზე კამათების უმეტესობას ხსნის და განმარტავს, რატომ იძლევა უფრო მაღალი რიცხვი იმაზე ნაკლებს, ვიდრე ჟღერს.

ინტერპოლაცია. შენი კლიენტი სხვა მოთამაშეებს იქ არ ხატავს, სადაც ბოლო snapshot-მა დააყენა. ის მათ ოდნავ წარსულში ხატავს, მიღებულ ბოლო ორ snapshot-ს შორის, რომ მოძრაობა გლუვი იყოს და ყოველ განახლებაზე არ ტელეპორტირდებოდეს. ფასი ფიქსირებული დაყოვნებაა, ჩვეულებრივ ორი tick-ის ტოლი. 64 tick-ზე ორი tick-ის ინტერპოლაციით ეს დაახლოებით 31 ms ჩაშენებული დაყოვნებაა; 128 tick-ზე - დაახლოებით 16 ms. ეს 15 ms განსხვავება ნამდვილი ჯილდოა 64-ისა და 128-ის კამათში და ის მარკეტინგის მინიშნებაზე ბევრად პატარაა.

პროგნოზი. შენი საკუთარი მოძრაობა ლოკალურად ისიმულირება იმ წამს, როცა კლავიშს აჭერ, და სერვერის უთანხმოების შემთხვევაში სწორდება. სწორედ ამიტომ გრძნობ პერსონაჟს მოქნილად 120 ms ping-ზე, სანამ ყველა დანარჩენი დაგვიანებული ჩანს.

Lag compensation. როცა შენი გასროლა მოდის, სერვერი სხვა მოთამაშეებს იმ პოზიციაზე აბრუნებს, სადაც ისინი გასროლის მომენტში იყვნენ, შენი latency-ის მიხედვით, და დარტყმას მას აფასებს. ამიტომ გარტყამენ საფარის უკან: მსროლელის ეკრანზე შენ ჯერ საფარის უკან არ იყავი. ეს არც შეცდომაა და არც tick rate; ეს შეგნებული გაცვლაა, რომელიც shooter-ებს კონტინენტზე სათამაშოს ხდის.

Source-ის უფრო ძველი თამაშები საშუალებას გაძლევს, ამის შენი მხარე rate-ით, cl_updaterate-ით, cl_cmdrate-ით, cl_interp-ით და cl_interp_ratio-თი მოარგო, სერვერის sv_minrate, sv_maxrate, sv_minupdaterate და sv_maxupdaterate საზღვრებში. Counter-Strike 2-მა ამის უმეტესობა ავტომატური rate-ებისა და sub-tick დროის სასარგებლოდ ამოიღო, ამიტომ 2016 წლის CS:GO-ს გზამკვლევიდან აღებული რჩევა არ გამოგადგება. სანამ ინტერნეტიდან config-ს ჩასვამ, შეამოწმე, რას იღებს შენი კონკრეტული თამაში ჯერ კიდევ.

Frame rate კლიენტია და შენი პრობლემა არ არის#

Frame rate არის მოთამაშის საკუთარი მანქანა, რომელიც სამყაროს ხატავს. მას სერვერთან არაფერი აქვს საერთო, რაც ღირს დადგინდეს, სანამ ვინმე გეგმას ამის გამოსასწორებლად გააუმჯობესებს. მოთამაშე, რომელიც ჩივის, რომ იჭედება, მაშინ როცა სერვერის კონსოლი ჩუმადაა, tick-ის დრო ბიუჯეტზე ნაკლებია და ყველა დანარჩენი კმაყოფილია, საკუთარ გრაფიკულ ბარათს აღწერს.

ორი რამ ამას ბუნდოვანს ხდის. პირველი: მოთამაშეებს შიგნიდან ნამდვილად არ შეუძლიათ 25 fps კლიენტისა და 15 TPS სერვერის გარჩევა; ორივე სამყაროს ჯანჯღარს ჰგავს. მეორე: დაბალი frame rate სერვერზე ოდნავ მაინც მოქმედებს, რადგან კლიენტი, რომელიც 20 fps-ზე ხატავს, საკუთარ input-ს უფრო იშვიათად აგზავნის და მისი მოქმედებები გვიან აღწევს. ეფექტი მცირეა და მხოლოდ ამ მოთამაშეს აზიანებს.

ტესტი, რომელიც ათ წამში წყვეტს: ჰკითხე, მაღალია თუ არა frame counter მის საკუთარ თამაშში, როცა რაღაც არასწორად ჩანს. თუ კადრები 144-ზეა და სამყარო ჯანჯღარობს, ეს სერვერია. თუ კადრები 22-ზეა, არა.

ოთხის გარჩევა#

რეგულარული გაყინვა ხსენებას იმსახურებს, რადგან ის განუწყვეტლივ არასწორად დიაგნოსტირდება. თამაშების უმეტესობა სამყაროს დისკზე ტაიმერით წერს და დიდ სამყაროზე ამ ჩაწერას მთავარი ნაკადის ერთი წამით ან მეტით დაბლოკვა შეუძლია. ის tick-ის პრობლემას ჰგავს და საცავის პრობლემაა. რას ცვლის NVMe სინამდვილეში განმარტავს, რომელ ოპერაციებს ეხმარება და რომლებს - არა.

რა ზრდის tick rate-ს სინამდვილეში#

იმ თანმიმდევრობით, რამდენადაც ისინი ჩვეულებრივ ეხმარებიან და რამდენად ჩვეულებრივ ღირს:

1. გააკეთე ნაკლები სამუშაო ერთ tick-ზე. ნაკლები entity, უფრო მცირე view ან simulation distance, ნაკლები სკრიპტი მოკლე ტაიმერებზე, ნაკლები ჩატვირთული chunk ან ზონა. ეს უფასოა და თითქმის ყოველთვის უდიდესი მოგებაა. Minecraft-ისთვის ეს Paper-ის ოპტიმიზაციის პარამეტრებს ნიშნავს; სხვა თამაშებისთვის - მათი config-ების ეკვივალენტურ პარამეტრებს.
2. იპოვე ერთი ძვირი რამ. Lag-ის უმეტესობას ერთი მიზეზი აქვს: ერთი plugin, ერთი mob farm, ერთი chunk ათი ათასი ნივთით. პროფაილერი წუთებში პოულობს. სერვერის შეცვლა - არა.
3. უფრო სწრაფი ერთბირთვიანი CPU. თითქმის ყველა გეიმ სერვერი ერთ ნაკადზე ისიმულირებს, ამიტომ ტაქტური სიხშირე ჭერს ადგენს. მეტი core სიმულაციის გარშემო ყველაფერს ეხმარება და ამ ჭერს არ ზრდის.
4. მოხსენი ბლოკირების სამუშაო. სინქრონული დისკზე ჩაწერა, მონაცემთა ბაზის მოთხოვნა მთავარ ნაკადზე, garbage collection-ის პაუზა. ისინი უზარმაზარი მაქსიმალური tick-ის დროებით და ნორმალური საშუალოთი ჩანს და კონფიგურაციით მოგვარდება და არა აპარატურით.
5. ნაკლები მოთამაშე. არაპოპულარულია, ეფექტურია და პატიოსანი. 60-ადგილიანი სერვერი, რომელიც rate-ს ინარჩუნებს, უკეთესია 100-ადგილიანზე, რომელიც ვერ ინარჩუნებს - იხილე რამდენი მოთამაშე ეტევა სერვერზე.

რა არ ეხმარება: მეტი მეხსიერება სერვერზე, რომლის მეხსიერების გრაფიკი ბრტყელია, NVMe CPU-ზე დამოკიდებულ სერვერზე და სხვა data center პრობლემისთვის, რომელიც ქსელი არ არის. CPU თუ RAM ამ სორტირების ოცდაათწამიანი ვერსიაა, ხოლო რატომ ეცემა TPS და რა ვქნათ Minecraft-ზე მორგებული ღრმა ჩაძირვაა.

უფრო მაღალი tick rate-ის გამტარუნარიანობის ფასი#

Tick rate ასევე გამტარუნარიანობის პარამეტრია, რაც იშვიათად ახსენებენ. სერვერი ყოველ მოთამაშეს ყოველ tick-ზე snapshot-ს უგზავნის, ამიტომ rate-ის გაორმაგება გამავალ ტრაფიკს დაახლოებით ორმაგდებს.

per-player downstream ~= snapshot size x tick rate200 bytes x 64 ticks/s  = 12.8 kB/s   per player200 bytes x 128 ticks/s = 25.6 kB/s   per player32 players at 128 tick  ~= 820 kB/s out, sustained

ეს საილუსტრაციო რიცხვებია - რეალური snapshot-ის ზომა ხილული entity-ების რაოდენობით იცვლება - მაგრამ ფორმა სწორია და ის განმარტავს, რატომ სჭირდება დიდი მოთამაშეთა რაოდენობის მქონე 128 tick სერვერს uplink, რომელსაც შეუძლია ენდოს და არა გაზიარებული. ისიც განმარტავს, რატომ აუარესებს rate-ის აწევა სერვერზე, რომელიც CPU-ს ლიმიტთან უკვე ახლოსაა, ყველაფერს: გაორმაგებ როგორც გამოთვლას, ისე ქსელის ხარჯს ზუსტად იმისა, რაც უკვე გვიან იყო.

FAQ#

ცუდია 20 TPS?

არა. 20 Minecraft-ის მაქსიმუმია და მისი ნორმალური მდგომარეობა. TPS სამიზნე rate-ით შემოსაზღვრულია, ამიტომ 20.0 ჯანმრთელობას ნიშნავს და ნებისმიერი უფრო დაბალი - ჩამორჩენას. 64 tick shooter-ში ჯანმრთელი მაჩვენებელი 64-ია და არა 20 - რიცხვები თამაშებს შორის არ შედარდება.

ამცირებს უფრო მაღალი tick rate ჩემს ping-ს?

არა. Tick rate ცვლის, რამდენად ხშირად გაახლებს სერვერი შენ; ping არის, რამდენ ხანს მიდის განახლება. 128 tick სერვერი სხვა კონტინენტზე უფრო ცუდად იგრძნობა, ვიდრე 64 tick სერვერი ახლოს. Tick rate მხოლოდ ინტერპოლაციის დაყოვნების რამდენიმე მილიწამს აშორებს.

რატომ ვკვდები საფარის უკან?

Lag compensation. სერვერმა მსროლელის ხედვა იმ მომენტზე დააბრუნა, როცა მან ესროლა, და იმ მომენტში შენ მის ეკრანზე ჩანდი. ეს განზრახ არის: ალტერნატივა ის არის, რომ shooter-ებმა თითოეულ სამიზნეს საკუთარი latency-ით წინ უნდა უსწრონ. უფრო მაღალი tick rate-ები ფანჯარას ოდნავ ავიწროებს, მაგრამ არასოდეს ხურავს.

ჩემი სერვერი 20 TPS-ს აჩვენებს, მაგრამ მოთამაშეები ამბობენ, რომ იჭედება. რა ვქნა?

საშუალოს ნაცვლად მაქსიმალურ tick-ის დროს შეხედე. /mspt Paper-ზე ან პროფაილერი ყველაფერზე სხვაზე. 20 ms საშუალო 400 ms პიკით არის სერვერი, რომელიც მოკლედ და ხშირად იყინება, ხოლო TPS, ერთ წუთზე გასაშუალებული, ამას სრულიად მალავს.

გამოასწორებს გეგმის გაუმჯობესება დაბალ TPS-ს?

მხოლოდ თუ გეგმის CPU წილია ის, რაც გზღუდავს, და მხოლოდ მაშინ, როცა ახალ გეგმას უფრო სწრაფი core-ები აქვს და არა მეტი. ჯერ CPU-ს გრაფიკი ლიმიტს შეადარე. თუ გრაფიკი ლიმიტზე არ არის, მთავარ ნაკადზე რაღაც ბლოკავს და მეტი CPU არაფერს ყიდულობს.

გავლენას ახდენს tick rate იმაზე, რამდენი RAM მჭირდება?

თითქმის არა. მეხსიერებას განაპირობებს, რამდენი სამყარო და entity არის ჩატვირთული და არა ის, რამდენად ხშირად ახლდება. Tick rate CPU-სა და გამტარუნარიანობის პარამეტრია.