נניח שיש חיבור אינטרנט אחד בבית, ומחוברים אליו 2 מחשבים דרך switch.
כידוע במקרה כזה, אם מישהו משתמש בביטורנט וכד', והאחר משחק במשחק multiplayer, אז ירגיש lags בגלל שהראשון מוריד דברים.
אבל אם יש 2 בתי אב נפרדים שמחוברים לאותה תשתית - והאחד מוריד והשני משחק, אז לא מורגש lags.
מה הסיבה לזה? פשוט switch איכותי יותר? הריבוב הוא על תדר כך שהמשתמשים האחרים לא מרגישים?
בטח בסופו של דבר טווח התדרים נגמר ואז ה-switch פועל בעיקרון כמו ה-"switch הרגיל הביתי"...

1. lag, ולא lags

2. לא הצלחתי להבין למה אתה חושב שה switch הוא הגורם לבעיה. יש סבירות קרובה ל 100% שה switch הוא לא הבעייה.

3. איטיות יכולה לנבוע ממספר דברים:
א. משאבי חומרה לא מספיקים של ה router (מעבד, זיכרון) - בד"כ מהותי כשעובדים עם כמות גדולה של חיבורים, וה router מתקשה לנהל את טבלת ה connection tracking של ה NAT.
ב. מנסים להעביר על קו התקשורת מעבר ליכולת שלו - למשל נדרש 5Mbps אבל רוחב הפס המוקצה שלך הוא 2.5Mbps. התוצאה היא שנוצר "תור" (queue) מהצד השולח. זה כשלעצמו יוצר בהתחלה lag, ובהמשך, כשהתור לא מצליח להתנקות (כי באופן קבוע מנסים לשלוח יותר ממה שניתן), התור מתמלא, ואז ציוד הרשת כבר לא יכול להכניס יותר packet-ים לתור, ולא נשאר לו אלא לעשות להם discard. כשזה קורה, אז: ב UDP פשוט יהיו איבודים (ואז בהזרמה, למשל ב VoIP, פשוט תהיה קטיעה), וב TCP יתחיל לעבוד המנגנון של ה Retransmission, שיתחיל לשלוח מחדש דברים. זה לוקח זמן, והכל מואט בדרך. כמובן ש TCP ינסה להמנע מהתופעה (המכונה Congestion), כשהוא יבין שהקו עמוס, וינסה פשוט לשלוח לאט יותר, עד שהוא יגיע למהירות האופטימלית, שהיא מצד אחד הכי מהירה, ומצד שני לא הולכים לאיבוד packet-ים בדרך.
ג. יש גם אלמנט של סידור ה packet-ים ביציאה מה queue, גודלו של ה queue, ותזמוני תעבורה, המשפיעים כולם על ה responsiveness. ההודעה הזו כבר מסובכת as it is, אז ברשותך לא אכנס לזה...

4. כל זה נובע מרוחב פס מוגבל, משיהוי הרשת, ממודל ה TX Queue של ציוד הרשת, ומה timeslot שיש לך (אם מדובר על מדיום משותף, כגון בכבלים).

5. "על אותה תשתית" - ב DSL אתה מגיע ל"אותה תשתית" רק בנקודת המיזוג הקרובה (ה DSLAM) - וכבלים, זה מתחיל כבר בבית (ולא רק ב CMTS) - ל"אותה התשתית", יש רוחב פס גדול בצורה ניכרת מרוחב הפס שלך יש בבית. תחשוב בכיוון של 10Gbps וצפונה. כל עוד שלקוחות הקצה מוגבלים (and indeed, they are, אפילו במקסימום היכולת של הטכנולוגיה, אתה לא תגיע לרוחב הפס של ה aggregation point), וכל עוד שיש fair queuing בין הלקוחות השונים בכניסה לקו התמסורת המאגד את כולם - אין סיבה שהם ישפיעו אחד על השני.

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

תודה רבה!
חלק הבנתי, חלק לא, ואת ההסבר כולו קשה לי לעכל ולהבין בכלליות איך הכל מסתדר.

אבל - האם אפשר לעשות שלא יהיה lag? אם כן - כמה יקר זה יכול להיות?

אם, לדוגמא:

• אגדיר ללקוח הביטורנט מהירות העלאה של 40kb ומהירות הורדה של 100kb,
  ואגדיר לו כמות חיבורי TCP מקסימאליים
• יש לי אינטרנט 10Mb
• אני משחק ב-multiplayer (אני משער שמשחקים כאלה דורשים יחסית מעט upload/download של מידע)
• לראוטר שלי יש מספיק זיכרון וכוח עיבוד

אז במצב כזה לא אמור להיות lag?

אגב, זה כמובן לא חייב להיות ב-2 מחשבים נפרדים, הרי lag קורה גם אם הביטורנט וה-multiplayer מתבצעים באותו המחשב.

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

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

זה היה בעברית אפילו פשוטה יותר משל שימי שהתחשב בנו וירד אל העם (:

וברשותך אנצל במה זו לשאול מדוע מצב של שימוש ב UPLOAD גבוהה "תוקע" את המחשב בהרבה יותר מאשר DOWNLOAD ?

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

כדי למנוע לאגים - הפתרון הכללי הוא:

1. להקטין את ה TX Queue Length לערך נמוך למדי (סביר להניח שלא נתמך יותר מדי בראוטרים ביתיים, אבל קל למדי אם הראוטר שלך הוא... לינוקס)
2. לוודא שמי שלא יהיה הראוטר שלך שעושה NAT, חומרתו מספיק חזקה כדי לעבד את כמות החיבורים הדרושה
3. ליישם מדיניות QoS, ולהגדיר בה חוקים: minimum-delay/realtime על תעבורת ה multiplayer ו maximum throughput לתעבורת ה BT. רצוי להגביל את רוחב הפס של BT גם במדיניות ה QoS, כי לך תדע כמה טוב הלקוח עושה את זה - ו/או להגדיר bandwidth reservation עבור תעבורת ה multiplayer (כמה? לא יודע, זה תלוי במשחק...)
3. 1. לשים לב שבראוטר שעושה את ה QoS מוגדר רוחב הפס העולה בצורה נכונה, אחרת ה QoS פשוט לא יעשה את העבודה...

ל D-Link, למשל, יש סדרה שלמה של נתבים שנקראת "Gaming", שמתיימרת לעשות את הנ"ל לא רע.

שום דבר לא עובד טוב כמו מערכת הפעלה אמיתית (Linux/BSD), על מחשב אמיתי. יש הפצה ידידותית למשתמשים שטוענת שהיא יודעת לעשות את הנ"ל לא רע, ושמה ZeroShell. צילומסך:


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

נמאס לכם לזכור סיסמאות? לחצו כאן!