Jump to content

Search the Community

Showing results for tags 'lag ping latency fix!'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • აპარატურული განყოფილება
    • Die-hard Overclocking
    • Overclockers GE-ს გუნდი
    • ბენჩმარკები
    • Versus ფორუმი
    • მოდინგი, შეკეთება & ინსტრუქციები
    • ყველაფერი PC-სა და ლეპტოპებზე
    • ქსელები
    • Hi-tech & General Technology
    • სერვერული ტექნოლოგიები
    • Internet of Things (IoT)
  • PC კომპონენტები
    • Intel & დედა დაფები
    • AMD & დედა დაფები
    • NVIDIA (ვიდეო დაფები)
    • AMD (ვიდეო დაფები)
    • Intel (ვიდეო დაფები)
    • RAM / SSD / HDD / Flash
    • გაგრილების სისტემა & კეისები
    • კვების ბლოკები
    • პერიფერია
    • აპარატურული პრობლემები
  • ბლოკჩეინი და კრიპტოვალუტები
    • ბლოკჩეინი და კრიპტოვალუტები
  • პროგრამული და მობილური განყოფილება
    • Microsoft
    • Windows
    • Google
    • Apple
    • მობილური სამყარო
    • Linux სისტემები
    • პროგრამირება
    • ინტერნეტი და სოციალური ქსელები
  • თამაშების განყოფილება
    • PC თამაშები
    • Mobile თამაშები
    • სიახლეები თამაშების ინდუსტრიიდან
    • ყველაფერი კონსოლების შესახებ
    • Sim Racing
    • Retro თამაშები
  • ყიდვა-გაყიდვა
    • ყიდვა-გაყიდვა
    • რჩევა-კონსულტაციები
    • ელექტრონული კომერცია
  • DigiArt
    • ფოტოგრაფია, 3D & მხატვრობა
    • მუსიკა & ფილმები
  • Overclockers GE
    • პორტალი Overclockers.GE
  • სხვა განყოფილებები
    • ზოგადი დისკუსიები
  • ავტომობილისტთა კლუბი's Topics

Calendars

  • Community Calendar
  • ავტომობილისტთა კლუბი's Events

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


MSN


Website URL


ICQ


Yahoo


Skype


Interests


OS


CPU


Cooler


MoBo


GPU


RAM


SSD


HDD


PSU


Case


Monitor


Laptop


Phone

Found 1 result

  1. მოგესალმებით. დღეს საკმაოდ საინტერესო რამეზე უნდა გესაუბროთ. ესაა თქვენი ინტერნეტკავშირის ხარვეზები, რომლზეც იდეაში ISP-მ უნდა იზრუნოს მაგრამ ინდივიდუალური მომხმარებლისთვის ამ პრობლემის აღმოფხვრა საკმაოდ შრომატევადია და დიდ ფინანსებთანაა დაკავშირებული ამიტომ გასწავლით როგორ მოაგვაროთ პრობლემა, ოღონდ ჯერ გაგაცნობთ მას. ალბათ ბევრ თქვენგანს შეუნიშნავს ინტერენტის გამოყენების დროს იქნება ეს რამის გადმოწერა, ვიდეოს ყურება თუ სხვა რომ თამაში ან რაიმე სხვა პროცესი ოდნავ ნელდება, ლაგავს და ა.შ. მეც მქონია ასეთი შემთხვევა მაგრამ არ ვიცოდი ეს რისგან იყო გამოწვეული. ამ მოვლენას ეწოდება bufferbloat და ის ძირითადად თქვენს როუტერსა და ISP-ს შორის ხდება რადგან ეს ადგილია ზუსტად bottleneck. მის სანახავად შეგიძლიათ გამოიყენოთ ეს საიტი. http://www.dslreports.com/speedtest ყველაზე ეფექტურად და ზუსტად სწორედ ეს საიტი ზომავს. A+ დან F-მდეა შეფასების სისტემა. სხვა საიტები როგორიც მაგალითად speedtest-ია მხოლოდ პირველი პაკეტის latency-ს ზომავს და წერს მე 1 ms-ს მიწერს მაგრამ როდესაც სიჩქარის გაზომვა იწყება ანუ bandwith-ს მოხმარება წარმოიქმნება დამატებითი latency-რომლის შესახებ ესეთი საიტები არ გვაძლევენ ინფორმაციას და გვგონია რო 1 ms გვაქ სულ. იმ საიტს კიდევ უპირატესობა ის აქვს რომ ისტორიას იმახსოვრებს ინდივიდუალური მომხმარებლისთვის სტატისტიკის სახით და ამ ფიქსის მერე შეგიძლიათ შეადაროთ წინა შედეგებს. ეს ტესტ საიტი ასე გამოიყურება ეხლა პრობლემა, პრობლემა იმაში მდგომარეობს რომ სტანდარტულად დაბალფასიანი როუტერები არც ისე ჭკვიანები არიან და იწვევენ არასაჭირო latency-ს იმაზე მეტი პაკეტების ბუფერიზაციით ვიდრე ეს საჭიროა. ესეთი რამ ნებისმიერ network bottleneck-თან ხდება. ამას bufferbloat ეწოდება. გადმოწერისას ისეთი გვერდის გამოყენებაც კი როგორიცაა gmail ნერვების მოშლელია voip სერვისებიც ლაგავენ, online თამაშებზე რომ არაფერი ვთქვათ. ესეთი რამ თუნდაც არაფერს იწერდეთ მაინც დაეხმარება განსაკუთრებით მათ ვისაც aDSL კავშირი აქვთ. ამ პრობლემის მოსაგვარებლად საჭიროა queue managment სისტემა. ამის მხარდაჭერა უნდა ჰქონდეს როუტერს ან ქსელში უნდა გქონდეთ linux box რომელსაც შეუძლია ეს გააკეთოს. საუკეთესო ვარიანტი კი linux-ს სისტემის როუტერზე დაყენებაა. ასეთი სისტემებია OpenWRT, DD-WRT, Tomato, FreeWRT, Gargoyle და ა.შ. არის კიდევ რამდენიმე. ამ შემთხვევაში განვიხილავ OpenWRT-ს რადგან სწორედ ეს მიყენია ჩემს როუტერზე. OpenWRT DD WRT Gargoyle ამისთვის გამოიყენება საკმაოდ ეფექტური პროგრამა SQM (Smart Queue Management) ახლანდელ OpenWRT-ს ვერსიებს ალგორითმები და სკრიპტები (fq_codel და sqm-scripts) ჩაშენებული აქვთ ისევე როგორც linux-ს kernel-ს და უამრავ კომერციულ ტექნიკას. მის დასაყენებლად საჭიროა წაშალოთ qos-scripts და luci-app-qos თუ ის აყენია და დააყენოთ luci-app-sqm. OpenWRT-ს აქვს შესანიშნავი package managment system მისთვის უამრავი პროგრამა არსებობს სწორედ ამიტომაა OpenWRT ჩემი რჩეული. პროგრამების დასაყენებლად გამოიყენეთ მენიუ System → Software, და დააჭირეთ Update Lists დააჭირეთ Available packages tab-ს, დამოძებნეთ luci-app-sqm. დააჭირეთ Install ან command line-დან აკრიფეთ opkg update და მერე opkg install "პაკეტის სახელი" ჩართეთ SQM System → Startup დააჭირეთ Start SQM-ს სახელთად დააჭირეთ Enable რომ SQM process-ები რესტარტის ან ჩართვის მერე თვითონ გაეშვას. SQM-ს აქვს რამდენიმე სეთინგი 1 Basic Settings აკონტროლებს გადმოწერა/ატვირთვის სიჩქარეებს. 2 Queue Discipline სეთინგი ირჩევს რომელი queueing discipline იქნას გამოყენებული WAN-სთვის. დეფოლტ სეთინგები უკვე კარგია მაგრამ შეგიძლიათ კიდევ უფრო დაანავაროტკოთ. 3 Link Layer Adaptation საშუალებას აძლევს OpenWrt-ს გამოთვალოს overhead-ები WAN link-სთვის როგორიცაა DSL და ADSL. თუ DSL გაქვთ, უნდა წაიკითხოთ ეს სექცია კარგად. SQM: Basic Settings Tab უნდა დააყენოთ Download და Upload სიჩქარეები web GUI-ში WAN პორტისთვი. აიღეთ ნიმუშები ახლანდელი სეთაფის. როდესაც network არ გამოიყენება აქტირუად გამოიყენეთ ეს ტესტი http://www.dslreports.com/speedtest ტესტის გაშვებისას არ მოკიდოთ ხელი მაუსს საერთოდ მოშორდით კომპიუტერს. სასურველია ყველა სახის პროგრამა გათიშოთ, კომპიუტერი იყოს idle რეჟიმში. Example 1: თუ ISP-ს ნათქვამი სიჩქარეებია "7 megabit გადმოწერა/768 kbps ატვირთვა", დააყენეთ Download 5950 kbit/s და Upload 653 kbit/s. ეს რიცხვები არის 85% სრული სიჩქარეებისა. Example 2: თუ speed test -თ გაზომეთ სიჩქარე დააყენეთ Download და Upload სიჩქარეები ამის 95%-თ. მაგალითად გაზმომეთ და იყო 6.2 megabits გადმოწერა და 0.67 megabits ატვირთვა (6200 kbps და 670 kbps, შესაბამისად), დააყენეთ Download და Upload სიჩქარეები ამის 95% ანუ (5890 და 637 kbps, შესაბამისად) SQM: Queue Discipline Tab Queue Discipline tab აკონტროლებს პაკეტების პრიორიტიზაციას გაგზავნისა და მიღებისთვის. დეფოლტ სეთინგებია: fq_codel queueing discipline simple.qos queue setup script ECN for inbound packets NOECN for outbound packets დეფოლტად Advanced Configuration მშვენივრად მუშაობს, ასე რომ თუ არ ჩაუღმავდებით ისედაც კარგ შედეგებს მიიღებთ. Queueing Discipline - the details… The default fq_codel queueing discipline works well in virtually all situations. Feel free to try out other algorithms to see if they work better in your environment. The default simple.qos script has a traffic shaper (the Queueing Discipline you select) and three classes with different priorities for traffic. This provides good defaults. Explicit Congestion Notification (ECN) is a mechanism for notifying a sender that its packets are encountering congestion and that the sender should slow its packet delivery rate. Instead of dropping a packet, fq_codel marks the packet with a congestion notification and passes it along to the receiver. That receiver sends the congestion notification back to the sender, which can adjust its rate. This provides faster feedback than having the router drop the received packet. Note: this technique requires that the TCP stack on both sides enable ECN. At low bandwidth, we recommend that you turn ECN off for the Upload (outbound, egress) direction, because fq_codel handles and drops packets before they reach the bottleneck, leaving room for more important packets to get out. For the Download (inbound, ingress) link, we recommend you turn ECN on so that fq_codel can inform the local receiver (that will in turn notify the remote sender) that it has detected congestion without loss of a packet. "Dangerous Configuration" option-ები გაძლევთ საშუალებას შეცვალოთ სხვა სეთინგები მაგრამ ამის გაკეთება არაა საჭირო რადგან დეფოლტადაც კარგი შედეგები გექნებათ. დეფოლტ სეთინგებია: Hard limit on ingress queues: ეს არის შემომსვლელი პაკეტების (inbound) queue ლიმიტი. ცარიელი დატოვეთ დეფოლტისთვის. Hard limit on egress queues: ეს არის გამავალი პაკეტების (outbound) queue ლიმიტი. ცარიელი დატოვეთ დეფოლტისთვის. Latency target for ingress: codel algorithm აკონკრეტებს სამიზნეს გამოსახულს msec-ბში. გამოიყენეთ "auto" გამოთვლილი კომპენსაციისთვის ნელი სიჩქარეებისთვის (4 mbps-ზე ნაკლებისთვის). ცარიელი დატოვეთ დეფოლტისთვის. Latency target for egress: იგივეს შვება ოღონდ ამ შემთხვევაში ჩვენ მხარეს. ცარიელი დატოვეთ დეფოლტისთვის. Advanced option string for ingress: აქედან შეგიძლიათ დამატებითი პარამეტრები მიაწოდოთ შემომავალ პაკეტების მენეჯერს. ფრთხილად იყავით რადგან ერორ ჩექინგი არ ხდება. ცარიელი დატოვეთ დეფოლტისთვის. Advanced option string for egress: იგივეა გამავალი პაკეტების მენეჯმენტისთვის. ცარიელი დატოვეთ დეფოლტისთვის. SQM: Link Layer Adaptation Tab დააყენეთ Link Layer Adaptation option-ები თქვენი ინტერნეტკავშირის ტიპის მიხედვით. მთავარი rule-ბია: აირჩიეთ ATM: მაგალითად: ADSL1, ADSL2, ADSL2+ და Per-packet Overhead დააყენეთ 44 bytes-ზე თუ იყენებთ რაიმე სახის DSL/ADSL connection-ს (ანუ როცა ინტერნეტი ტელეფონის ხაზით მოგეწოდებათ). აირჩიეთ Ethernet with overhead: მაგალითად: VDSL2 და დააყენეთ Per-packet Overhead 8-ზე თუ იცით რომ გაქვთ VDSL2 connection. აირჩიეთ none (default) თუ იყენებთ Cable modem-ს, Fiber-ს (ბოჭკოვანი), direct Ethernet, ან რაიმე სხვა სახის კავშირს. ყველა სხვა პარამეტრები იქნება იგნორირებული.. თუ არ იცით რა სახის კავშირი გაქვთ თავიდან დააყენეთ "None", გაატარეთ სწრაფი Bufferbloat ტესტი. თუ შედეგები გაუმჯობესდა თავიდან გაკეთებულ ტესტებთან შედარებით კარგია. მერე აირჩიეთ ATM, მერე Ethernet რომ ნახოთ რომელზე გაქვთ უკეთესი შედეგი. Link Layer Adaptation - the details… აუცილებელია და ყველაზე უკეთესი ეგექტი აქვს ამის დაყენებას ATM framing-ს გამომყენებელ კავშირებში (თითქმის ყველა DSL/ADSL იყენებს), რადგან ATM ამატებს overhead-ს 5 byte-ს 48-byte frame-ს. ამიტომ მოკლე პაკეტების გაგზავნას მეტი დრო დაჭირდება. SQM ს შეუძლია მოაგვაროს "Ethernet with overhead" (თითქმის ყველა VDSL) კავშირებში. Cable Modem, Fiber (ბოჭკო), და direct Ethernet connection-ები ძირითადად არ საჭიროებენ link layer adaptation. "Advanced Link Layer" -ს დაყენება საჭიროა თუ აგზავნით packet-ებს რომლებიც 1500 byte-ზე დიდია. თუმცა სახლის შემთხვევაში არაა საჭირო ამის დაყენება რადგან ISP-ები ალიმიტებენ ტრაფიკს 1500 byte-იან პაკეტებზე. ექსპერიმენტის სახით შეგიძლიათ tc_stab (არა htb_private ! ) აირჩიოთ link layer adaptation მექანიზმისთვის და ნახოთ შეიძლება გააუმჯობესოს კიდეც. ეს მათ საიტზევე ჩატარებული ტესტების შედეგებია ცადეთ და დაწერეთ თქვენი შედეგები რომლებსაც ზემოთ დალინკულ ტესტის საიტზე იხილავთ. წარმატებებს გისურვებთ.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.