האם גם אצלכם ספקיות מגבילות את ה-MTU/MRU בתשתית בזק?

wallalon · שליחה #41 09/02/2015 23:36

בזק+בינ"ל 100

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2015.02.09 16:32
IP address: 109.65.xxx.x
Client OS/browser: Windows 7 (Chrome 40.0.2214.111)

TCP options string: 02040550010303020402080a01cb572a00000000
MSS: 1360
MTU: 1400
TCP Window: 66052 (NOT multiple of MSS)
RWIN Scaling: 2 bits (2^2=4)
Unscaled RWIN : 16513
Recommended RWINs: 65280, 130560, 261120, 522240, 1044480
BDP limit (200ms): 2642kbps (330KBytes/s)
BDP limit (500ms): 1057kbps (132KBytes/s)
MTU Discovery: ON
TTL: 112
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)

iSolt · שליחה #42 10/02/2015 5:19

בזק+נטוויז'ן+IP פרטי לא משתנה (לא דינמי)

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2015.02.09 22:17
IP address: 207.232.x.xx
Client OS/browser: Windows 7 (Chrome 39.0.2171.95)

TCP options string: 020405500103030201010402
MSS: 1360
MTU: 1400
TCP Window: 66792 (NOT multiple of MSS)
RWIN Scaling: 2 bits (2^2=4)
Unscaled RWIN : 16698
Recommended RWINs: 65280, 130560, 261120, 522240, 1044480
BDP limit (200ms): 2672kbps (334KBytes/s)
BDP limit (500ms): 1069kbps (134KBytes/s)
MTU Discovery: ON
TTL: 113
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

nir11 · שליחה #43 10/02/2015 18:30

Class889 כתב:1. הספק לא אמור להוריד את הMTU בלי שום סיבה, אם בא לי להוריד את הMTU זה לשיקולי ולא לשיקולו של הספק.
2. העניין הוא לא שיפור של ביצועים ברמת ההרדה, כי בשביל לקבל מספיק DATA אתה יכול לבקש יותר פאקטות ככה שאתה לא מפסיד בכלל בביצועים, סה"כ כמות הPPS תעלה, העניין הוא בהעלאה, ככל שהפאקטות שלך קטנות יותר, ככה אתה תשלח יותר ack כי היחס בין ACK לDATA הוא נמוך יותר וכאן הבעיה נמצאת. בדיוק מאותה הסיבה שאתה מתחבר בתשתית הוט בL2TP ו99% מהאנשים לא יכולים לקבל 100 או 200 מגה עם חייגן זה בגלל הMTU הנמוך שחונק להם את כל מהירות העלאה.
יותר פאקטות נכנסות בשניה, ככה גם יותר פאקטות יוצאות בשניה אבל כמות הDATA נשאר אותו דבר, מה שגורם לך להפסיד רוחב פס עולה בזמן הורדה.
3. ברגע שיש לך UPLOAD של 2-5 מגה אתה מנסה להתקמצן עד כמה שיותר וברגע שפוגעים לך בזה על ידי הורדת הMSS זה מכעיס.
4. לגבי packet loss אתה צודק אבל באותה מידה אתה גם טועה. ככל שהפאקטות גדולות יותר אז אני אצטרך פחות פאקטות מה שגם מפחית את הסיכוי לpacket loss, אבל אולי זה משתווה בסופו של דבר אז ככה שהטיעון הזה לא חושב שהוא נכון.

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

...

·לגבי 1 - לספק יש שליטה על כל כך הרבה פרמטרים אחרים, שאם שליטה על גודל MTU מספק לך אשליה של שליטה - זו רק אשליה.
לגבי 2 -+ 3 ביחד - אתה טוען שהחשיבות היא בהעלאה. אם כך לדעתי אתה טועה: כל עוד לא הקמת שרת של המחשב בבית, הפקטות שאתה שולח למעלה הן לא בגודל 1460 ולא בגודל 1500, הן ממילא הרבה יותר קטנות (כמו שאמרת 0 מדובר על ACK ברוב המקרים). ברגע שהפקטה קטנה - יש אפס חשיבות ל"כמה גדולה היא הייתה יכולה להיות". הרי גודל ה HEADER זהה בכל המקרים ללא קשר ל MTU. פקטה באורך 100 בתים תהיה תמיד באותו אורך, ללא קשר ל MTU.
במילים אחרות, ה M הוא עבור MAX. אם אתה לא קרוב למקסימום ממילא אין לזה חשיבות.
לגבי 4, אתה צודק במהות אם כי לא באמירה השיפוטית. אני לא צודק וטועה, אלא יש כאן טריידוף. פקטה גדולה תתן יותר יעילות, אבל תגרום לאיבוד יעילות, ככל שהרשת רועשת יותר.

Class889 · שליחה #44 10/02/2015 19:51

לגבי זה שאני צריך שרת, הבעיה כמו שאמרתי בהודעה הראשונה שלי זה שה-MTU וגם MRU מוגבלים, לא רק MTU.
אתה לא מצליח להבין את הנקודה שאני מנסה להעביר, אני אנסה להסביר באופן פשוט יותר.
הACK שאמרתי הוא זה שיגרום לבזבוז רוחב פס לא נחוץ ולא פאקטות השליחה, שכן ACK הוא בגודל 40B בווינדוס ו52B בלינוקס.
תדמיין עכשיו שהMTU הוא 1500, אז בשביל להעביר על 70 מגה, אתה צריך (אני סתם זורק) 5000 פאקטות בשניה, אז אתה תשלח ברוב המקרים 2500 פאקטות של ACK מה שיצרוך X העלאה.
ברגע שהMTU (ה-MRU ביחד איתו) יורד, על מנת להגיע ל70 מגה אתה תצטרך לקבל 6000 פאקאות בשניה על מנת להגיע ל70 מגה, אז במקרה כזה אתה תצטרך לשלוח 3000 פאקטות בשניה של ACK (בלי להחשיב את interrupt coalescing) מה שבאופן ישיר יגדיל את כמות הUP שלך.
עצם זה שזה גורם לבזבוז של UP, אני לא אוהב את הרעיון של הספק להגביל את זה.

אני מתאר לעצמי שהם הגבילו את הMTU/MRU בגלל הרבה נתבים של בזק מאוד חלשים שעם MTU מקסימלי גורם מידי פעם לבעיות שנפתר על ידי הורדת MTU/MRU, בהוט לא ידוע לי על בעיה כזאת עם הציוד שלהם אז אני מניח בגלל זה בתשתית הוט הם לא מגבילים שם או מחוסר יכולת.
גם אם השינוי הזה היה גורם רק להבדל בביצועים של 1% גם את זה לא הייתי רוצה שישנו לי את הMTU/MRU.

MrYair · שליחה #45 10/02/2015 22:10

חחחח אתם בתחרות של להראות למי יש יותר גדול?

nirfun · שליחה #46 10/02/2015 22:56

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

Class889 · שליחה #47 10/02/2015 23:25

האלגוריתם של נייג'ל גורם לכך שאתה שולח ACK על כל 2 פאקטות נכנסות, ז"א שהצד השולח לא יחכה לACK על מנת לשלוח את הפאקטה הבאה על מנת לא להאט את הקצב, בגלל זה ה-window size מחושב בצורה של RTT ולא ONE WAY.
היחס בדר"כ בכל בית יהיה 2:1, כמו שאמרתי בלי interrupt coalescing או offload אחר כמו LRO או GRO.
בשביל להגיע למהירות של 935 מגה בUDP עם פאקטות בגודל של 1500B הMSS הוא 1472 צריך 78K PPS.
על מנת להגיע לאותה מהירות בUDP עם פאקטות בגודל של 1400B שהMSS הוא 1372 צריך 85K PPS.
אז לפי יחס של 2:1 אתה תצטרך בהורדה של פאקטות בגודל 1500, 39KPPS. בגודל פאקטות של 1400 אתה תצטרך לשלוח 42KPPS. היחס הוא של 7.6%, מה שאומר שבגלל זה אתה מספיד 7.6% יותר UPLOAD, שזה מתבטא ב0.23mbit בחיבור עם 3 מגה העלאה.
כמובן שהאשמה הגדולה פה היא על כמות הUP שהם נותנים לנו.

אבל אני חושב שזאת לא המטרה פה להראות מה ההפסד, אלא עצם הרעיון שהספק משנה את , זה לא צודק.
אם הספק רוצה לעשות qos שיהנה לו, אם הוא רוצה להגביל אותי במהירות לפה ולשם הוא מוזמן בכיף, כמובן שאני אבחר את הספק שאני חושב שהכי מתאים לי, אבל להגביל MTU/MRU בגלל אנשים שמתמשים בציוד של בזק בתור נתב(כמובן שזאת רק תאוריה,אולי הסיבה היא אחרת) זה פשוט.. sigh

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

nir11 · שליחה #48 12/02/2015 23:18

Class889 כתב:האלגוריתם של נייג'ל גורם לכך שאתה שולח ACK על כל 2 פאקטות נכנסות, ז"א שהצד השולח לא יחכה לACK על מנת לשלוח את הפאקטה הבאה על מנת לא להאט את הקצב, בגלל זה ה-window size מחושב בצורה של RTT ולא ONE WAY.
היחס בדר"כ בכל בית יהיה 2:1, כמו שאמרתי בלי interrupt coalescing או offload אחר כמו LRO או GRO.
בשביל להגיע למהירות של 935 מגה בUDP עם פאקטות בגודל של 1500B הMSS הוא 1472 צריך 78K PPS.
על מנת להגיע לאותה מהירות בUDP עם פאקטות בגודל של 1400B שהMSS הוא 1372 צריך 85K PPS.
אז לפי יחס של 2:1 אתה תצטרך בהורדה של פאקטות בגודל 1500, 39KPPS. בגודל פאקטות של 1400 אתה תצטרך לשלוח 42KPPS. היחס הוא של 7.6%, מה שאומר שבגלל זה אתה מספיד 7.6% יותר UPLOAD, שזה מתבטא ב0.23mbit בחיבור עם 3 מגה העלאה.
כמובן שהאשמה הגדולה פה היא על כמות הUP שהם נותנים לנו.

אבל אני חושב שזאת לא המטרה פה להראות מה ההפסד, אלא עצם הרעיון שהספק משנה את , זה לא צודק.
אם הספק רוצה לעשות qos שיהנה לו, אם הוא רוצה להגביל אותי במהירות לפה ולשם הוא מוזמן בכיף, כמובן שאני אבחר את הספק שאני חושב שהכי מתאים לי, אבל להגביל MTU/MRU בגלל אנשים שמתמשים בציוד של בזק בתור נתב(כמובן שזאת רק תאוריה,אולי הסיבה היא אחרת) זה פשוט.. sigh

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

על המחשב שלי הורדה במהירות 60 מגה ביט מייצרת העלאה של 1.2 מגה ביט בערך. גם ב 100 ביט אני אהיה רחוק מהאפלואד שלי. זה פשוט לא רלוונטי.
·

Class889 · שליחה #49 13/02/2015 1:03

כמובן, אתה צודק.
בוא כולנו נוריד את הMTU ל1000B וניהיה כולנו שמחים ומאושרים.

MrYair · שליחה #50 13/02/2015 1:56

בדיקה בחיבור L2TP
מוגדר בהוטבוקס 2 ספק 014
120/5 בבדיקת מהירות

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2015.02.12 18:55
IP address: 84.110.xx.xxx
Client OS/browser: Windows 7 (Chrome 40.0.2214.111)

TCP options string: 0204058c0303090402000000
MSS: 1420
MTU: 1460
TCP Window: 133120 (NOT multiple of MSS)
RWIN Scaling: 9 bits (2^9=512)
Unscaled RWIN : 260
Recommended RWINs: 65320, 130640, 261280, 522560, 1045120
BDP limit (200ms): 5325kbps (666KBytes/s)
BDP limit (500ms): 2130kbps (266KBytes/s)
MTU Discovery: ON
TTL: 49
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

ה MTU 1460

מוזר לא?

Class889 · שליחה #51 13/02/2015 2:32

לא, זה אמור להיות 1460 בL2TP.

nir11 · שליחה #52 13/02/2015 8:09

Class889 כתב:כמובן, אתה צודק.
בוא כולנו נוריד את הMTU ל1000B וניהיה כולנו שמחים ומאושרים.
...

בטווחים שה ISP משחקים איתו אין לו חשיבות.

sushay · שליחה #53 13/02/2015 8:33

גם « SpeedGuide.net TCP Analyzer Results »
Tested on: 2015.02.13 01:30
IP address: 2.54.xx.xx
Client OS/browser: Android (Chrome 28.0.1500.94)

TCP options string: 020405500402080a00640d190000000001030305
MSS: 1360
MTU: 1400
TCP Window: 14624 (NOT multiple of MSS)
RWIN Scaling: 5 bits (2^5=32)
Unscaled RWIN : 457
Recommended RWINs: 65280, 130560, 261120, 522240, 1044480
BDP limit (200ms): 585kbps (73KBytes/s)
BDP limit (500ms): 234kbps (29KBytes/s)
MTU Discovery: ON
TTL: 43
Timestamps: ON
SACKs: ON « SpeedGuide.net TCP Analyzer Results »
Tested on: 2015.02.13 01:30
IP address: 2.54.xx.xx
Client OS/browser: Android (Chrome 28.0.1500.94)

TCP options string: 020405500402080a00640d190000000001030305
MSS: 1360
MTU: 1400
TCP Window: 14624 (NOT multiple of MSS)
RWIN Scaling: 5 bits (2^5=32)
Unscaled RWIN : 457
Recommended RWINs: 65280, 130560, 261120, 522240, 1044480
BDP limit (200ms): 585kbps (73KBytes/s)
BDP limit (500ms): 234kbps (29KBytes/s)
MTU Discovery: ON
TTL: 43
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)

IP ToS: 00000000 (0)
לרשת הסלולרית זה ככה

MrYair · שליחה #54 15/02/2015 16:13

Class889 כתב:לא, זה אמור להיות 1460 בL2TP.
...

אם אני אשנה ל 1500 זה יתן משהו?

Class889 · שליחה #55 15/02/2015 17:15

אתה לא ממש יכול

NightbeaT · שליחה #56 04/01/2016 11:15

יש טעם לשנות את הMTU בראוטר ובווינדוס מ1492 ל1400?
גם אני מקבל 1400 ו1360 בבזק+בזב"ל. לפי מה שהבנתי כשהערכים אינם תואמים נוצרות שגיאות.