Latency, jitter და packet loss: როგორ გაარჩიო lag

ყველაფერს, რაც ქსელში ცუდად იგრძნობა, lag ჰქვია, და სწორედ ამიტომ იხარჯება ამდენი დრო არასწორის გამოსწორებაზე. სამი განსხვავებული გაზომვა არსებობს, მათ სხვადასხვა მიზეზი აქვს, და ერთი წუთი ping გეუბნება, რომელი გაქვს.

Latency არის დრო, რომელიც ერთ წრიულ მოგზაურობას სჭირდება, და ის ძირითადად მანძილით განისაზღვრება. Jitter არის ამ დროის ცვალებადობა და ის ჩვეულებრივ ვიღაცის საკუთარი კავშირის ბრალია. Packet loss არის შეტყობინებები, რომლებიც არასოდეს აღწევს დანიშნულებამდე და ჩვეულებრივ ერთი კონკრეტული hop-ის ბრალია. მეოთხე რამეც ხშირად lag-ად იწოდება და საერთოდ ქსელის პრობლემა არ არის: სერვერი, რომელსაც CPU ამოეწურა და საკუთარ tick-ებს ვერ ასწრებს. ამ ოთხის გარჩევა მთელი ხელობაა, და ამ პოსტის დანარჩენი ნაწილი ამას ეძღვნება.

სამი რიცხვი და როგორი შეგრძნებაა თითოეული#

Latency არის ფიზიკით დადგენილი ქვედა ზღვარი და აპარატურით დადგენილი ზედა ზღვარი. სინათლე ბოჭკოში დაახლოებით 200 კმ-ს გადის მილიწამში, პაკეტმა კი ორივე მიმართულებით უნდა გაიაროს, ამიტომ გზის ყოველი 1000 კმ დაახლოებით 10 ms წრიულ დროს ითხოვს, სანამ რამე ხელს მოკიდებს. რეალური მარშრუტები არასოდეს არის სწორი, და ყოველი router, ყოველი ოპტიკური გამაძლიერებელი და ყოველი გადატვირთული ხაზი მას ამატებს.

Jitter ის არის, რაც თამაშებს ნამდვილად ფუჭავს. თამაშის კლიენტი პროგნოზირების მექანიზმია: ის ხვდება, სად იქნება ყველაფერი, და ასწორებს, როცა სერვერი სხვას ეუბნება. მუდმივი დაგვიანების ირგვლივ პროგნოზირება ადვილია. დაგვიანება, რომელიც 30-სა და 140 ms-ს შორის ცვალებადობს, არა, და სწორედ ეს შესწორებები იგრძნობა მოთამაშეებისთვის როგორც rubber-banding და არასწორ დროს მოხვედრილი დარტყმები. 5 ms-ზე ნაკლები შესანიშნავია, 15 ms-ზე ნაკლები კარგია, 30 ms-ზე მეტი გატეხილი გამოცდილებაა, საშუალო რაც არ უნდა ჩანდეს.

Packet loss თითოეული პაკეტისთვის ორობითია და სტატისტიკურია ჯამში. 0.1%-ის ქვემოთ ვერავინ ამჩნევს. 0.5%-სა და 2%-ს შორის shooter არასწორად იგრძნობა და survival თამაში - ძირითადად არა. 2%-ზე მეტზე ყველაფერი არასწორად იგრძნობა. განაწილებას რიცხვზე მეტი მნიშვნელობა აქვს: თანაბრად გაფანტული 2% გადაიტანება, ხოლო 2%, რომელიც წუთში ერთხელ ზედიზედ ორმოცი დაკარგული პაკეტის ტალღად მოდის, გათიშვაა დამატებითი ნაბიჯებით.

მუდმივი 90 ms უკეთ თამაშდება, ვიდრე მერყევი 40. თამაშში წინასწარგანჭვრეტადობა სისწრაფეს სჯობს.

სად მიდის მილიწამები სინამდვილეში#

რიცხვი ეკრანის კუთხეში არ არის მთელი დაგვიანება ღილაკზე დაჭერასა და შედეგის დანახვას შორის. ბიუჯეტის დანარჩენის ცოდნა გიშლის ხელს, რომ 10 ms ქსელს დაედევნო, სანამ 80 ms სადღაც სხვაგან ზის.

ამ ეტაპებიდან ორს სათანადოდ გაგება უღირს.

Tick. სერვერი სამყაროს დისკრეტული ნაბიჯებით ამუშავებს. შენი input რომელიმე ნაბიჯის განმავლობაში ჩამოდის და შემდეგამდე არ მუშავდება, ამიტომ წამში 20 tick-ზე მომუშავე სერვერი 50 ms-მდე ამატებს და საშუალოდ 25-ს. წამში 64 tick-ზე ეს 15.6 ms-მდეა. სწორედ ამიტომ ასახელებენ tick rate-ს საერთოდ, და სწორედ ამიტომ ჯდება მისი გაზრდა CPU-ში და არა bandwidth-ში - რას ნიშნავს tick rate სინამდვილეში გაცვლას სრულად აღწერს.

Interpolation buffer. კლიენტები სამყაროს განზრახ ოდნავ წარსულში ხატავენ, რომ დაგვიანებულმა პაკეტმა ხილული ხვრელი არ გამოიწვიოს. უფრო ძველ Source ძრავის თამაშებში ეს აშკარა და მორგებადი იყო: cl_interp_ratio 2 cl_updaterate 66-ზე ორ განახლებას ბუფერავს, რაც დაახლოებით 30 ms განზრახ დაგვიანებაა. უფრო ახალი თამაშები მას შენთვის აყენებს და ძირითადად ღილაკებს არ აჩვენებს. ბუფერის გამო შეიძლება თამაში 100 ms-ზე გლუვად იგრძნობოდეს და მერყევ 40-ზე საშინლად: ბუფერი მუდმივ დაგვიანებას შთანთქავს და ვარიაციას ვერა.

სამოცი წამში გარჩევა#

ერთი ბრძანება. გაუშვი ასი პაკეტისთვის და არა ხუთისთვის.

$ ping -c 100 -i 0.2 play.example.com--- play.example.com ping statistics ---100 packets transmitted, 100 received, 0% packet loss, time 19871msrtt min/avg/max/mdev = 41.2/43.8/58.1/2.4 ms

შემაჯამებელი ხაზი სამივე კითხვას პასუხობს:

• 0% packet loss და დაბალი mdev მაღალ avg-თან ერთად: წმინდა latency. სერვერი შორსაა ან მარშრუტი ცუდია. სერვერზე ამას ვერაფერი შეასწორებს.
• დაბალი avg და max, რომელიც min-ზე რამდენჯერმე მეტია, mdev-ით დაახლოებით 10-ზე მეტით: jitter. ჯერ კლიენტის საკუთარი კავშირი შეამოწმე.
• ნებისმიერი დანაკარგი 0%-ზე მეტი, მუდმივი: packet loss. იპოვე hop.
• სამივე კარგია, თამაში კი მაინც ცუდად გრძნობა: ეს ქსელი არ არის. გადადი სერვერის განყოფილებაზე.

mdev არის საშუალო გადახრა, რაც jitter-ის საკმარისად კარგი შემცვლელია. Windows მას არ ბეჭდავს, ამიტომ ამის ნაცვლად გამოიყენე სხვაობა Minimum-სა და Maximum-ს შორის:

ping -n 100 play.example.com

ping-ის შესახებ ორი გაფრთხილება, რომელსაც მნიშვნელობა აქვს. ის ICMP-ს იყენებს, თამაში კი TCP-ს ან UDP-ს კონკრეტულ პორტზე, ამიტომ firewall-ს ან rate limiter-ს მათ სხვადასხვანაირად შეუძლია მოექცეს - mtr --tcp --port 25565 ან --udp რეალურს ამოწმებს. და სერვერის მისამართზე ping გზას ამოწმებს და არა თამაშს: სერვერი, რომელიც 100% CPU-ზეა გაჭედილი, ping-ებს მყისიერად პასუხობს, მისი სამყარო კი ნახევარი სისწრაფით მუშაობს.

mtr ანგარიშის კითხვა მოტყუების გარეშე#

mtr გზაზე ყოველ hop-ს ping-ავს და აქ ყველაზე სასარგებლო ინსტრუმენტია, ასევე ყველაზე ხშირად არასწორად წაკითხული.

$ mtr -rwzbc 200 play.example.comHOST                                 Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???    192.168.1.1               0.0%  200   0.6   0.7   0.5   2.1   0.2 2. AS12345  10.0.0.1                  0.0%  200   8.1   8.6   7.9  18.4   1.1 3. AS12345  core1.isp.example        14.0%  200  11.2  11.9  10.8  29.1   2.0 4. AS3356   ae-1.fra.example.net       0.0%  200  38.4  38.9  38.1  44.2   0.8 5. AS64500  play.example.com           0.0%  200  41.0  41.6  40.9  48.7   1.2

ეს ანგარიში ჯანსაღ გზას აჩვენებს. 14% მე-3 hop-ზე დანაკარგი არ არის, და მისი დანაკარგად წაკითხვა კლასიკური შეცდომაა.

• დანაკარგი შუალედურ hop-ზე, რომელიც ბოლომდე არ გრძელდება, ნამდვილი არ არის. Router-ები საკუთარ თავზე მიმართულ ICMP-ს დაბალ პრიორიტეტს აძლევენ, ტრაფიკს კი უნაკლოდ გადასცემენ. დანაკარგი, რომლისგანაც შენი ტრაფიკი ნამდვილად იტანჯება, ის არის, რომელიც hop-ზე ჩნდება და ყოველ მომდევნოზე გრძელდება.
• ბოლო ხაზი ითვლება. თუ ბოლო hop-ს 0% დანაკარგი აქვს, შენს გზას დანაკარგი არ აქვს, ანგარიშის შუა რაც არ უნდა გამოიყურებოდეს.
• latency-ს ნახტომი ერთ hop-ზე ნორმალურია - ეს შორი მანძილის ხაზია. ნახტომი, რომელიც ყოველ მომდევნო hop-ზე იზრდება, გადატვირთვაა.
• დასაბრუნებელი გზა უხილავია. mtr მხოლოდ წინა მარშრუტს გაჩვენებს, ინტერნეტ-მარშრუტები კი ხშირად ასიმეტრიულია. თუ ანგარიში სუფთაა და პრობლემა რეალურია, გაუშვი mtr სერვერიდან მოთამაშისკენაც. ხშირად ცუდი hop იქ იმალება.
• გაუშვი პრობლემის დროს. სუფთა ანგარიში 15:00-ზე არაფერს ამტკიცებს საღამოზე, რომელიც 20:00-ზე ინგრევა, და ზუსტად ეს არის გადატვირთული peering ხაზის ნიშანი.

Traceroute-სა და mtr-ის კითხვა ანგარიშის ინტერპრეტაციას უფრო ღრმად განიხილავს, და WinMTR იმავე საქმეს Windows-ზე აკეთებს.

Jitter: bufferbloat, wifi და რიგი შენს საკუთარ სახლში#

jitter-ის უმეტესობა მოთამაშიდან ოცი მეტრის რადიუსში იბადება.

Bufferbloat დიდია და თითქმის არავინ ამოწმებს. სახლის router-ებს გასასვლელად მომლოდინე პაკეტების დიდი რიგი უჭირავთ. როცა ვინმე ვიდეოს ტვირთავს ან თამაში ფონზე განახლდება, ეს რიგი ივსება, და ყოველი მომდევნო პაკეტი რიგს ელოდება, რომელშიც რამდენიმე ასეული მილიწამის ტრაფიკი შეიძლება იყოს. Ping 40 ms-დან 400 ms-მდე იზრდება, სანამ ხაზი დაკავებულია, და ბრუნდება იმ წამს, როცა თავისუფალია.

გამოსცადე ოცდაათ წამში: დაიწყე უწყვეტი ping, შემდეგ დიდი upload, და უყურე რიცხვებს. თუ სამჯერ გაიზარდა, ეს bufferbloat-ია. გამოსწორება არის ჭკვიანი რიგის მართვა - fq_codel ან cake - router-ზე, shaper-ით, რომელიც გაზომილი ხაზის სიჩქარის დაახლოებით 85-90%-ზეა დაყენებული, რომ რიგი შენს მიერ კონტროლირებად აპარატურაში ჩამოყალიბდეს და არა პროვაიდერის აპარატურაში. OpenWrt მას SQM-ად აჩვენებს და რამდენიმე სამომხმარებლო router მას Smart Queue-ს უწოდებს.

Wifi მეორე ნახევარია. ხელახლა გადაგზავნილი frame გვიან ჩამოდის და არა არასოდეს, ამიტომ wifi დანაკარგს კი არა, jitter-ს იწვევს. 2.4 GHz თავის სპექტრს ყველა მეზობელთან და უმეტეს მიკროტალღურ ღუმელთან იზიარებს, 5 GHz-ს შეუძლია გაფრთხილების გარეშე არხი შეიცვალოს, როცა radar-ს აღმოაჩენს, და mesh სისტემები, რომლებიც ერთ radio-ს კლიენტებისთვისაც და backhaul-ისთვისაც იყენებენ, ეთერის დროს ორჯერ ამცირებენ. კაბელი ამ ყველაფერს აშორებს და ყველაზე მაღალი ღირებულების რამაა, რასაც მოთამაშეს, რომელიც წუწუნებს, შეუძლია გააკეთოს. Powerline ადაპტერები wifi-ის თანაბრად არაპროგნოზირებადია და იმავენაირად უნდა მოექცე.

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

Packet loss: რას აკეთებს ის TCP-სა და UDP-ზე#

სიმპტომი მთლიანად პროტოკოლზეა დამოკიდებული, სწორედ ამიტომ იგივე 2% დანაკარგი ორ სრულიად განსხვავებულ საჩივარს იწვევს.

TCP თამაშები იყინება და მერე დაეწევა. TCP მიწოდებას და თანმიმდევრობას იძლევა, ამიტომ დაკარგული პაკეტი ყველაფერს აჩერებს მის უკან, სანამ ხელახლა გადაგზავნა არ ჩამოვა, რაც სულ მცირე ერთ წრიულ მოგზაურობას ჯდება. Minecraft Java TCP-ა, სწორედ ამიტომ ჩანს დანაკარგი იქ როგორც ნახევარწამიანი შეფერხება, რასაც ყველაფრის ერთბაშად მოხდენა მოსდევს, და არა როგორც teleport-ი.

UDP თამაშები გამოტოვებენ. UDP ხელახლა არ აგზავნის, ამიტომ თამაში ამ მდგომარეობის განახლებას უბრალოდ არასოდეს იღებს და კლიენტის პროგნოზი მიდის მომდევნომდე, რომელიც მას ასწორებს. ეს არის teleport-ი, გასროლა, რომელიც არ ითვლება, და კარი, რომელიც ორჯერ იღება. TCP თუ UDP გეიმ სერვერებისთვის ხსნის, რატომ აირჩია თითქმის ყველა action თამაშმა UDP და რა ღირს ეს.

საიდან მოდის დანაკარგი სინამდვილეში, დაახლოებით სიხშირის მიხედვით:

1. გადავსებული uplink, ჩვეულებრივ მოთამაშის საკუთარი. სავსე upload რიგი პაკეტებს აგდებს, როცა ბუფერი ივსება, რაც ზემოთ აღწერილი bufferbloat-ის დასასრულია.
2. Wifi ან ცუდი კაბელი. დაზიანებული კაბელი ან duplex-ის შეუსაბამობა მცირე, მუდმივ დანაკარგს იძლევა, რომელსაც სხვა არაფერი ხსნის.
3. გადატვირთული ხაზი სადღაც შუაში, რომელიც ყოველდღე ერთსა და იმავე საათებში ჩნდება.
4. სერვერის საკუთარი socket ბუფერების გადავსება, როცა პროცესი საკმარისად სწრაფად ვერ კითხულობს. Linux-ზე netstat -su receive buffer შეცდომებს აჩვენებს, და ეს პაკეტებია, რომლებიც მანქანამ მიიღო და გადააგდო.
5. MTU blackhole, რაც საერთოდ დანაკარგი არ არის, მაგრამ დიდი პაკეტებისთვის იდენტურად გამოიყურება. გამოსცადე პირდაპირ: ping -M do -s 1472 play.example.com Linux-ზე, ან ping -f -l 1472 play.example.com Windows-ზე, აგზავნის 1500-ბაიტიან პაკეტს, რომელიც არ უნდა დაიყოს. თუ მცირე ping-ები მუშაობს და ეს - არა, გზას სრული ზომის პაკეტების გადატანა არ შეუძლია, და მიზეზი ჩვეულებრივ სადღაც ტუნელია.

როცა სერვერია და არა ქსელი#

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

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

გავრცელებული მიზეზები:

• CPU ზღვარზე. ერთი container, მკაცრი შეზღუდვა შეძენილ წილზე, და თამაშის ციკლი, რომელიც დროულად ვერ სრულდება. სერვერი, რომელიც 100%-ზე დგას, ნელია და არა გატეხილი. CPU თუ RAM გეიმ სერვერებისთვის და სერვერის დატვირთვის გრაფიკის კითხვა ამის პატიოსნად წაკითხვას აღწერს.
• ერთი ძვირი tick. Autosave, რომელიც დიდ სამყაროს წერს, chunk-ების გენერაციის ტალღა, პლაგინი, რომელიც მთავარ thread-ზე მონაცემთა ბაზის სამუშაოს აკეთებს. Minecraft-ში ეს ჩანს როგორც MSPT-ის ნახტომები და არა მუდმივი დატვირთვა, და spark მას პოულობს - lag-ის დიაგნოსტიკა spark-ით.
• მეხსიერების წნეხი. Garbage collection-ის პაუზა სამყაროს იმდენ ხანს აჩერებს, რამდენსაც სჭირდება, და სერვერი მეხსიერების ლიმიტზე უარესია, ვიდრე სერვერი მარაგით. რატომ ეცემა TPS Minecraft-ის შემთხვევას ამუშავებს.
• ხმაურიანი მეზობელი გაზიარებულ აპარატურაზე, რაც ჩანს როგორც წყვეტილი შენელება ადგილობრივი ახსნის გარეშე - გაზიარებული CPU და ხმაურიანი მეზობლები.

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

რისი გასწორება შეგიძლია, თანმიმდევრობით#

ყველაზე იაფი და ეფექტური - პირველი. ჯგუფების უმეტესობა მესამე ნაბიჯზე ჩერდება.

1. გაზომე, სანამ რამეს შეცვლი. ასი პაკეტის ping და ერთი mtr თითოეული მოთამაშისგან, ვინც წუწუნებს. ჩაიწერე რიცხვები. დაფიქსირებული lag-ის ნახევარი ერთი ადამიანია wifi-ზე.
2. მიაერთე კაბელით ყველაზე ხმამაღალი მოთამაშე. ეს არაფერი ღირს და jitter-ის საჩივრების გასაკვირად დიდ ნაწილს თავისით წყვეტს.
3. გაასწორე bufferbloat router-ზე. ასევე უფასოა, ასევე ნაკლებად გამოყენებული, და ის ასწორებს საღამოს საჩივრებს, რომლებიც სახლში ვიღაც სხვის აქტივობას უკავშირდება.
4. დაამტკიცე, სად არის დანაკარგი, ორივე მიმართულებით. დანაკარგი დასაბრუნებელ გზაზე მოთამაშის მხრიდან უხილავია. თუ ის ერთი ISP-ის ქსელში ხვდება, ერთადერთი რეალური გამოსწორება ამ ISP-ისთვის ticket-ია, mtr ანგარიშით მიმაგრებული.
5. სერვერი დადე იქ, სადაც შენი მოთამაშეების უმეტესობაა. Latency მანძილია და ამას ვერაფერი ცვლის. RE:NODE ერთ ლოკაციას უშვებს, გერმანიას, რაც გონივრული შუაა ქართველი, თურქი, აღმოსავლეთ და დასავლეთ ევროპელი მოთამაშეებისთვის და ცუდი არჩევანია ავსტრალიელთა ჯგუფისთვის. სად უნდა ცხოვრობდეს შენი სერვერი ამ გადაწყვეტილების პატიოსანი ვერსიაა.
6. გაასწორე სერვერის tick ბიუჯეტი, თუ რიცხვები ამბობს, რომ სერვერია პრობლემა: view distance, entity-ების რაოდენობა, პლაგინი, რომელიც ყოველ tick-ზე მუშაობს.
7. მიიღე ქვედა ზღვარი. როცა ping სტაბილურია და მანძილს შეესაბამება, ეს რიცხვი არის ის, რასაც მარშრუტი გაძლევს, და ვერც გეგმა, ვერც tick rate და ვერც პროტოკოლი მას ვერ შეცვლის.

FAQ#

რა არის კარგი ping გეიმ სერვერისთვის?

30 ms-ზე ნაკლები თითქმის ყველაფრისთვის ლოკალურისგან გარჩევადი არ არის. 30-დან 60 ms-მდე კარგია survival-ის, აშენებისა და roleplay-ისთვის და shooter-ში შესამჩნევია, თუ დააკვირდები. 60-დან 100 ms-მდე თამაშადია და ის წერტილია, სადაც კომპეტიციური მოთამაშეები წუწუნებენ. 120 ms-ზე მეტი სხვა გამოცდილებაა და არა იგივეს უარესი ვერსია.

რამდენი packet loss არის მისაღები?

0.1%-ის ქვემოთ ვერავინ ამჩნევს. დაახლოებით 1%-ზე shooter არასანდოდ გრძნობა. 2%-ზე მეტი გატეხილია. ტალღისებური დანაკარგი იმავე პროცენტზე თანაბრად გაფანტულზე ბევრად უარესია, ამიტომ ვიმსჯელოთ ნიმუშით და არა სათაურის რიცხვით.

რატომ არის ჩემი ping კარგი, მაგრამ თამაში მაინც ჭედავს?

იმიტომ, რომ დაგვიანება ქსელში არ არის. ან სერვერს tick-ები აკლდება, რაც CPU-ს ან პლაგინის პრობლემაა, ან კლიენტი კადრებს კარგავს, რაც ადგილობრივია. ბრტყელი ping ჭედავი თამაშის გვერდით ყველაზე ნათელი ნიშანია, რომ ქსელი დამნაშავე არ არის.

ამცირებს ჰოსტინგის გეგმის გაუმჯობესება ping-ს?

არა. Latency-ს მანძილი განსაზღვრავს, და უფრო დიდი გეგმა მანქანას არ გადაანაცვლებს. მეტი CPU ეხმარება, როცა სერვერი tick-ებს ვერ ასრულებს, რაც განსხვავებული სიმპტომია, მსგავსი საჩივრით.

რომელია უარესი, jitter თუ მაღალი latency?

Jitter, დიდი სხვაობით. თამაშის კლიენტები აგებულია, რომ მუდმივი დაგვიანება დამალონ და ცვალებადი ვერ მალავენ. სტაბილური 90 ms უკეთ თამაშდება, ვიდრე 40 ms კავშირი, რომელიც ყოველ რამდენიმე წამში 200-მდე ხტება.

შეუძლია VPN-ს ჩემი lag-ის შემცირება?

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