שלום לכולם , נתקלתי בסרטון הזה :

מה אתם אומרים זה אפשרי בכלל ?

זה פשוט משנה את הצורה שזה סופר (בערך, סוג של...) זה לא באמת גורם למידע לעבור יותר מהר..

זה אפילו עלול לגרום למידע לעבור יותר לאט.

וד"א זה שינוי שאתה תראה רק בתוך המשחק, ולא באמת בלתת ping בcmd.. וזו ההוכחה הכי טובה שזה לא באמת משנה משהו.

שמע, הבחור טיפש ברמות של אלפקות.

טוב שהוא לא שם את המחשב בדירה שכורה בחוף המערבי, התחבר למחשב ב-Remote Desktop מהחוף המזרחי ואז צילם פינגים נמוכים . . .

פינג, בין היתר (עומס וכדומה), הוא תוצאה של המרחק ליעד.

שום טריק לא ישנה את זה

אין שום בעיה שנבעה מהמחשב שלו, ואין שום קשר לבליזארד.

מה שקורה הוא שכל כמות מידע מסויימת שהשרת שולח למחשב שלו, המחשב שלו מחזיר לשרת תשובה שהוא קיבל את המידע.

השרת מחשב את הפינג כזמן שעבר משהוא שלח את המידע, עד שהוא קיבל את התגובה שהצד השני קיבל את המידע.

מה שהוא שינה שם ברג'יסטרי זה שזה יחזיר תשובה אחרי פחות מידע, ולכן התגובה הגיע יותר מהר.

אבל לא בגלל שהמידע עבר יותר מהר, אלא כי עבר פחות מידע.

העניין הוא שעכשיו המחשב יחזיר תשובה בתדירות הרבה יותר גבוהה, וזה סתם יפריע לזירמת המידע.

(זה כל הרעיון של flow control וsliding window בTCP למי שרוצה לחפש קצת יותר לעומק)

ברגע שאתה שולח פינג רגיל (לא דרך המשחק, ולא דרך tcping) המידע עובר בפרוטוקול אחר (ICMP)

ולכן גם התשובה של הצד השני מגיע ללא קשר להגדרה הזאת שהוא שינה. ולכן זה לא ישפיע.

מה שאתה עשית עם הtcping הזה, זה בדיוק מה שהוא עשה במשחק - זה לא מצביע על כלום.

הdelay ליעד קשור למרחק. יש אפילו נוסחה לחישוב:

מרחק ליעד במטרים חלקי (2.1x10^8)

יש גם גורמים נוספים

http://www.ciscopress.com/articles/article.asp?p=606583

רק משהו קטן מטריד אותי, אמרת שאין שום בעיה שנבעה מהמחשב שלו.. אך מה קורה כאשר התוכנה\משחק\מחשב לא מצליח לעבד את המידע מהר מספיק ולכן השליחה המחודשת של הרשת "מתעכבת" ומחכה לאישור ?

במקרה כזה לא תקבל פינג גבוה?

בעקרון זה נמדד לפי ממוצע בדרך כלל. זה דברים שהם מאוד דינאמיים, ולא נמדדים במס' של 1-2 בדרך כלל.

זה נספר לפי ביטים, כל כמה ביטים של מידע צריך לשלוח ACK (אישור שהמידע הגיע).

במידה והמחשב לא עומד בעומס, הוא מבקש להוריד את הזמן הזה, וכך אם יש חבילות שלא מגיעות, לא יצטרכו לשלוח יותר מידי מידע שוב.

אבל בגדול כן, אם יש עומס על המחשב, אז מן הסתם הפינג יעלה, כמו שאם יש עומס על כל רכיב רשת אחר בדרך הפינג יעלה.

המחשב הוא עוד תחנה בדרך, וגם הוא משפיע.

קראתי על זה קצת, והרבה אנשים טוענים שזה כן עוזר להם במשחקי רשת.

יכול להיות פה קטע של שכנוע עצמי, וזה אפילו די סביר, אבל יש עוד אפשרות שחשבתי עליה.

ברור שזה לא משפיע על מהירות הרשת. צריך להיות אידיוט כדי לחשוב שאפשר לשנות הגדרה לוקאלית במחשב שתשפיע על מהירות התקשורת.

אבל כשמשנים את ההגדרה הזו בעצם מקטינים את מספר הפאקטים שצריכים לעבור עד שנשלח ACK. נגיד, במקום לחכות לשני פאקטים או ל-timeout, שולחים מיד אחרי כל פאקט.

עכשיו, נניח שה-sliding window של השרת בצד השני קטן מאוד, והוא שולח פאקט-פאקט, ומחכה ל-ack אחרי כל פאקט. במצב הנורמלי, הוא לא יקבל ack על הפאקט הראשון ששלח, אלא רק אחרי שיעבור timeout (נגיד 200ms, שזה נדמה לי ה-default). אז בלי קשר למהירות החיבור, אתה בצד המקבל תחכה 200ms (פלוס השהיית הרשת) בין פאקט לפאקט.

לעומת זאת, אם המחשב שלך מוגדר לשלוח ack מיד, השרת יקבל אותו מהר יותר, וישלח לך את המידע הבא מהר יותר, מה שכן יגרום לירידה בהשהייה.

כך שבסופו של דבר זה תלוי במימוש של הTCP בצד השני. מובן, שאם הרשת פועלת באופן מתואם, אז לא יהיה הבדל, אבל לך תדע איך ממומשת התקשורת במשחקי הרשת השונים?

הנה המקור (מדברים שם על ה-tweak של ה-ACK ועל עוד כמה):

http://www.speedguide.net/read_articles.php?id=2574

Gaming Tweak - Disable Nagle's algorithm

The tweak below allows for tweaking or disabling Nagle's alogrithm. Disabling "nagling" allows for very small packets to be transferred immediately without delay. Note that disabling Nagle's algorithm is only recommended for some games, and it may have negative impact on file transfers/throughput. The dafault state (Nagling enabled) improves performance by allowing several small packets to be combined together into a single, larger packet for more efficient transmission. While this improves overall performance and reduces TCP/IP overhead, it may briefly delay transmission of smaller packets. Keep in mind that disabling Nagle's algorithm may have some negative effect on file transfers, and can only help reduce delay in some games.

זה תלוי בעיקר באיכות הקישור בין שני הצדדים. אם נופלים הרבה פאקטים בדרך אז כן, עדיף לשלוח יותר ack.

ואם לא נופלים הרבה פאקטים, אז זה סתם בזבוז זמן ורוחב פס.

כל העניין בsliding window זה שהוא אמור לקחת את ההחלטות האלה לבד.

אני חושב שזה עוזר במקרים של packetloss והretransmission . אם יש packetloss בTCP והוא עונה על packet שהוא קיבל במהירות גבוהה (1 מילישניה) זה כנראה גורם לשרת לשלוח פקט ש"נפל" מחדש.

לדוגמה השרת שלוח את פקט N ואז את פקט M כשהID של M גדול ב 1 מ N. נגיד שN עושה טיול או נופל ו M מגיע ראשון אז הclient עושה ACK ל M . השרת רואה שהוא קיבל ACK לM ולא לN אז הוא חושב שכנראה N נפל אז הוא שולח את N מחדש . בנתיים הפקט N המקורי יכול להגיע ליעד ואז ה client עושה לו ACK . וזה יכול לגרום שהמהירות תגובה ל N תהיה מהירה .

בקיצור זה כנראה סוג של אשליה אבל זה יכול לעזור מאוד להאבק בpacketloss . עדיין במשחקים שעובדים בUDP בעיקר זה לא יעזור כי בUDP אין ACK אלא אם כן אתה כותב מנגנון כזה בעצמך.

כדאי לעשות את זה? אני בספק רב אם זה בכלל באמת גורם למשהו

עריכה: אנשים החרא הזה עובד

השתמשתי בדבר הזה: http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html#info

כדי להכניס את זה לרג'יסטרי בוינדוס 7 והוא עושה את זה אוטומטית יפה מאוד במקום שאני הייתי צריך להסתבך איפה לשים ומה

בעיקרון אין לי כרגע את WOW בשביל לבדוק או איזה MMO כלשהוא אבל אתם לא תאמינו

יוטיוב טס לי עכשיו ואין את הבעיה הזאת של התקיעות, אולי שליחה רבה יותר של הפאקטים או מה שזה לא יהיה דווקא כן תורמת

תנסו ותראו (כל אלה עם הבעיות ביוטיוב)

זה תיקן לי את הבעיה עם הPacketloss עכשיו אין לי שום בעיה עם VoIP אך זה יצר בעיה חדשה; Lag spikes

בנוסף Youtube טוען HD בלי שום בעיה עכשיו.

mishax, כל מה שהדבר הזה עושה הוא להיכנס לרג'יסטרי ללוקל>סיסטם> וכל השאר ולשים שם את הערך tcpackfrequency 1 בכל הערכים של כרטיסי הרשת שרשומים, הפעלת remove VBS תוציא אותם, זה סך הכל סקריפט נחמד שעושה לך את העבודה בקליק במקום שתשבור את הראש ועוד מציע לך ריסטרט, מה רע?

מסה, אני חושב שזה גורם ללאג ספייקס בגלל כל הקטע של העומס שקיים על הכבל לחו"ל ובגלל שפתאום החיבור מוספם בפקטים כל רגע אז זה למה זה נגרם

בכל מקרה אמרתי לחבר שלי שמשחק WOW כרגע להפעיל את זה והתוצאות חיוביות, ירד לו מ200-300 ל170 פינג לסרבר DRAENOR

עריכה: אמאלה, נכנסתי עכשיו לאיזה וידאו של HD שמדגים טקטיקה לאיזה בוס בWOW והאדום של הטעינה פשוט טס לי קדימה!

fighter

אני חושב שזה נתן לי שיפור קל

פינג ל- YOUTUBE.COM ירד טיפה מתחת ל- 200MS, אבל הסירטונים עדיין נטענים לאט.

כן, אם למשל אני עושה פינג ל www.youtube.com זה נותן לי 80 פינג

אבל אם אני עושה ל youtube.com (בלי הWWW) זה נותן לי 170 פינג