עזרה בחישוב ביטרייט

[Batnun]

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

...

חס וחלילה, אתה ממש לא חובבן אלא מומחה אמיתי! אף אחד כאן לא מטיל בזה ספק!

בוא נשתמש בדוגמה המצויינת של @ufffnick, רק לקובץ יותר גדול.

1 מגה לשניה + שניה עיכוב = תפוקה של 0.5 מגה לשניה

במהירות של 1 מגה לשניה, הורדה של קובץ של 3.6 גיגה לוקחת בדיוק שעה. תוסיף דיליי של שניה שלמה (1000ms) ותוריד את אותו קובץ, וקיבלת במקום תפוקה של 1 מגה לשניה בלי דיליי, תפוקה של רק 0.9997222993612885 מגה לשניה עם דיליי של שניה אחת. אכן מזעזע.


Batnun

.

[eizen5]

נמחק.

[eran405]

אני מקווה שזה לא יבלבל עוד יותר את Dor1992 אבל המציאות לא כזו פשוטה:

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

במהירות של 1 מגה לשניה, הורדה של קובץ של 3.6 גיגה לוקחת בדיוק שעה. תוסיף דיליי של שניה שלמה (1000ms) ותוריד את אותו קובץ, וקיבלת במקום תפוקה של 1 מגה לשניה בלי דיליי, תפוקה של רק 0.9997222993612885 מגה לשניה עם דיליי של שניה אחת.

...

(בהתאם לתוצאה לעיל, אני אפרש "דיליי של שניה אחת" כהשהייה רק לכיוון אחד ולכן ה-round trip delay הוא בעצם 2 שניות)

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

בשביל לסבר את האוזן אפשר להסתכל על שכבת ה-TCP. בתקווה ההסבר הבא מספיק ברור ובמדוייק:
https://accedian.com/enterprises/blog/t ... need-know/
גם בלי להכנס לפרטים אפשר בקלות להתרשם שיש חילופי הודעות והמידע לא סתם נשפך ללא בקרה. הפרמטר העיקרי שקובע בשביל הדיון שלנו, הוא ה-TCP Window שבגדול קובע כמה מידע ישלח עד שיתקבל אישור קבלה מהצד השני. הצורך בקבלת ה-ACK לפני שממשיכים לשלוח מידע הוא מה שיכול לגרום ל-latency להגביל את ה-througput במקרים מסויימים.

לדוגמא אם נניח TCP Window של 64K (המקסימום האפשרי ללא window scaling), אז לפי calculator שמצאתי נקבל:

maximum throughput with a TCP window of 64 KByte and RTT of 2000.0 ms <= 0.26 Mbit/sec.

...

כלומר ה-throughput יורד ל-0.0325 מגהבייט בשניה (בלי הקטנוניות של ההשהייה של שהתחלת שליחת המידע וקבלת הפאקטה האחרונה).

למיטב הבנתי במציאות היום משתמשים ב-window scaling וסביר שהחלון יהיה הרבה יותר גדול (גם לזה יש הסבר בלינק שהבאתי לעיל תחת הכותרת TCP Window Scale). בדוגמא שלנו, אם ה-TCP Window הוא לפחות 2 מגה אז אנחנו מקבלים:

maximum throughput with a TCP window of 2048 KByte and RTT of 2000.0 ms <= 8.39 Mbit/sec.

...

כלומר עבור חיבור של 1 מגהבייט ה-TCP Window אף פעם לא יתמלא וההשפעה של ה-latency על throughput תהיה זניחה. אם ממש רוצים להתקטננן ולהוסיף את ההשהייה של ה-handshake, בקשת המידע, קבלת הפאקטה האחרונה וכו', ונגיד שזה מסתכם ב-20 שניות (10 הודעות הלוך ושוב), אז נקבל בדוגמא לעיל throughput של "רק" 0.994475.

כל זאת רק בשכבת ה-TCP והשכבות מעל יכולות להגדיל (ע"י עוד בקרות) או להקטין (לדוגמא ע"י מספר חיבורים במקביל) את התלות ב-latency.

באופן כללי אני חושב שפרוטוקולים כמו SMB שמיועדים להעביר מידע ברשת מקומית עם latency נמוך מושפעים הרבה יותר מ-latency מאשר פרוטוקולים שמיועדים לעבוד מעל האינטרנט כמו FTP או ביטורנט.

[nir11]

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

[Dor1992]

@eran405
·
נניח שאני מחובר לשרת בארה"ב שעובר כמה תחנות וכמה קווי תקשורת בעצם.
המהירות של העברת הנתונים בקווי התקשורת תשתנה נכון? ממני לצומת של הוט ליד מושב יקום המהירות תהיה 200mbps. מהוט לספק המהירות תעלה משמעותית נכון? בוא נדמה את זה למכונית. מחיפה לקיסריה נסעתי במהירות 80 קמש. מקיסריה לנתניה ב120 קמש ומנתניה לתל אביב 140 קמ"ש. סה"כ אם ארצה לדעת מה המהירות הממוצעת שנסעתי בה זה סכום המהירויות חלקי 3.

עד לפה אנחנו מסכימים כן?

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

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

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

[eran405]

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

...

כן ולא. "המתמטיקה" כמו שאתה קורא לה לא כזו פשוטה כמו שפירטתי בפוסט לעיל. בגדול עם ה-TCP Window שלך מספיק גדול ה-throughput לא מוגבל ע"י ה-latency (או יותר מדיוק מגבלות bandwidth יגבילו את ה-throughput לפני שתגיע למגבלה של ה-latency).

במעשי בפרוקטולים שמיועדים לעבוד מעל האינטרנט, ובמיוחד במקרים של הרבה חיבורים במקביל, לא רואים שום תלות בין ה-lantency ל-throughput. קל לראות את זה לדוגמא בביטורנט, שעל טורנט עם מספיק מקורות, שיש להם bandwitdth מספיק גדול, תקבל throughput מלא (כלומר שווה לרוחב פס של התשתית שלך כולל בתשתיות של סיב עם רוחב פס של 1 גיגה). המהירות הכוללת שמקבלים תלויה בעיקר ב-bandwidth הזמין של המקורות שאתה מצליח להתחבר אליהם ואין קשר ל-latency אליהם.

[ufffnick]

@Dor1992
·

אתה פשוט טועה.
מה שאתה רואה זה רוחב הפס האפשרי בינך לבין השרת המרוחק, שמנוקה מכל לטנסי -
תשים לב שבבדיקה אתה מקבל קצב העברה המקסימלי (אחוזון 0.95 בד"כ כדי לנקות ספייקים), ולא קצב העברה הממוצע, ולרוב זה נעשה תוך דימוי העברת קובץ גדול כדי להגיע לנקודת רווייה של רוחב הפס.
כך שבפועל, בדומה למערכת צינורות, הזרם יורד בהתאמה אל הצינור הדק ביותר במערכת ואם בדרך יש לך מקטע קצר בקוטר של קשית, זו התפוקה שתקבל - מה שקשית יכולה לתת, ולכן התפוקה הסופית היא רוחב הפס של הצומת עם רוחב הפס הנמוך ביותר (ולא הממוצע שלהם).
כמו כן, מבחינת לטנסי - אתה מקבל את הסכום של כל הround trip, כלומר סכום של כל הלטנסי של כל הצמתי בדרך, הלוך ושוב (ממוצע על 5-10 הלוך ושובים).

וזה ממש תוך המנעות מלהכנס לפרטים של כל שכבה...

[eran405]

בוא נדמה את זה למכונית. מחיפה לקיסריה נסעתי במהירות 80 קמש. מקיסריה לנתניה ב120 קמש ומנתניה לתל אביב 140 קמ"ש. סה"כ אם ארצה לדעת מה המהירות הממוצעת שנסעתי בה זה סכום המהירויות חלקי 3.

עד לפה אנחנו מסכימים כן?

...

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

נתחיל מהמקרה הפשוט שאתה מחבר נגיד בין המחשב לסוויץ, אחרי זה בין הסוויץ לראוטר, אחרי זה מהראוטר לספק המקומי (נניח למען הפשטות שיש סיב יעודי רק לך בין הראוטר ועד הספק). עכשיו מה ה-throughput שאתה מקבל בין המחשב לספק שלך ללא כל שימוש אחר ברשת:
אתה מקבל את המהירות המנימלית בין כל החיבורים (ולא המומצע כמו שכתבת). לדוגמא אם יש bandwidth של 10 גיגה בין המחשב לסוויץ, ושל 1 גיגה בין הסוויץ לראוטר, ושל 200 מגה בין הראוטר לספק שלך, עדיין תקבל רק 200 מגה מהירות לספק ולא 3.7=3/(10+1+0.2) גיגה לשניה (?!). זה כבר מראה שההקבלה שלך בין throughput למהירות המומצעת שהמכונית נוסעת היא פשוט לא נכונה (אנסה לתקן בהמשך).

שם לב שעד כאן זו אותה דוגמא שכבר הבאנו לך מספר פעמים שמדגימה מקרה פשוט שבו ה-latency לחלוטין אינו משפיע על ה-throughput (בגלל שה-latency יהיה נמוך יחסית ומגבלות ה-bandwidth הם אילו שיגבילו אותך).

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

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

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

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

...

לא.

[Dor1992]

@eran405
·

אוקיי הבנתי את ההיגיון תגיד לי אם אני צודק.

אי אפשר לחשב מהירות ממוצעת כי רוחב פס זה לא מהירות בכלל.

לפי מה שקראתי והבאתי גם ציטוטים פה רוחב פס הוא כמה נתונים יכול הקו להעביר בשניה. זאת אומרת שאם הקו שלי מסוגל להעביר 200mbit לשניה בזה נגמר הסיפור. השרת המרוחק שאמנם יכל להעביר לי הרבה יותר מ200mbit לשניה לא יכול להעביר אליי יותר מזה כי הצינור שלי יותר צר ולא יכולים לעבור בצינור שלי יותר מ200mbit בשניה.

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

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

כל מה שאמרתי בעצם מחזק את אחת הטענות שלי. שlatency ישפיע בסוף על הthroughput. והרוחב פס לפעמים יכול להיות "אחיזת עיניים" כי בתכלס בסןף התפוקה הסופית לא תמיד תהיה 200mbit לשניה. כי אמנם הקו שלי באמת מסוגל להעביר 200mbit לשניה אבל המחשב לא מחשב כמה הקו שלי יכול להכיל בשניה! הוא מחשב כמה הוא הוריד בעצמו לשניה.

אני שוב אומר, בדקתי שוב כמה וכמה פעמים מול ארה"ב. יש הבדלים ואפילו אם הם קטנים מהארץ. אני לא מגיע ל200mbit. אני מצליח להגיע בהורדה למקסימום 180 ולפעמים גם 160.
זה מחזק את זה שהספידטסט לא מודד רוחב פס(הוא בעצם לא מודד כמה הפס רחב והוא לא יכול למדוד את זה). הוא מודד כמה נתונים הצליחו להגיע למחשב בשניה. שזה הthroughput !

[Amir64]

@eran405
אי אפשר לחשב מהירות ממוצעת כי רוחב פס זה לא מהירות בכלל.
לפי מה שקראתי והבאתי גם ציטוטים פה רוחב פס הוא כמה נתונים יכול הקו להעביר בשניה.

...

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

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

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

@eran405
ועוד משהו, זה שהרוחב פס בין הוט לספק למשל גדול מאוד זה גם מקל בסוף על הלקוחות איכשהוא. כי אז נתונים שעומדים בתור להיכנס לקו שלי שהוא 200mbps מגיעים בכמות יותר גדולה לכניסה לקו ואז זה מקצר את זמן השיהוי/זמן הנדידה של החבילות.

...

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

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

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

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

[Dor1992]

@Amir64
·

אני ממש לא רואה פה סתירה. אתה רוצה קישור שמסביר מה ההבדל בין מהירות לרוחב פס? בבקשה:

https://etherealmind.com/basics-differe ... dth-speed/

תשים לב מה כתוב בכותרת של המאמר: basics

אז עם כל הכבוד לידע של כולכם אתם סתם מנסים בכוח לסתור אותי ויוצאים שבורים בסוף כי אני מביא לכם בלי סוף מאמרים שהכותרת שלהם היא ידע בסיסי! ואתם אומרים לי חלקכם שbandwidth וthroughput זה אותו דבר. כל הכבוד באמת לכולם על שנים רבות של ניסיון וידע אבל הנה הגיע בחור צעיר ולימד אתכם משהו חדש שלא התעמקתם בו כד היום.

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


זה רק מחזק את האנלוגיה שהבאתי בתגובה מעל.
@eran405 אמר הרי שבסוף החלש מנצח. אני אומר נכון. אבל, למה? בגלל שהקו שלי מסוגל להכיל בהורדה רק 200mb לשניה. תחשוב שהקו שלי מאוד רזה. אין קשר למהירות! מהירות העברה נקבעת כפי שכתוב במאמר ע"י האות החשמלי / האות האופטי.

כלומר גם אם ישלחו לי חבילות על קווים עם רוחב פס עצום בסוף הם יעמדו בתור ויתקעו בכניסה לקו שלי כי הוא רזה מידי ויכול להכיל 200mb בשניה.ככה שהוא יעביר לי 200mbit, עברה שניה. החבילות הבאות יכנסו לקו ויעביר לי אותם וכך הלאה.

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

וכן גם הlatency משחק תפקיד. כי אם רוחב הפס שלי הוא 200mb אבל יש שיהוי של המידע כי הוא נודד ממקום רחוק. אני באמת עדיין לא מצליח להבין למה יש לי הבדל בין הארץ ולבין ארה"ב למשל בתפוקה הסופית אם 150 ms זה זניח מאוד.. אם למישהו יש הסבר משכנע למה ההבדל הזה הוא משמעותי מול כל שרת בארה"ב אז שיגיד. למרות שההבדל הוא לא עצום אבל זה עדיין הבדל משמעותי של פחות 25mbit לשניה.

[Dor1992]

@amir64

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

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

כאן הם ייתקעו. ייכנסו 200mbit תעבור שניה ואז יכנסו עוד 200mbit.


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

התוצאה בסוף היא הthroughput שזה מה שאני מקבל בspeed test בתוצאת מהירות ההורדה. על התוצאה הזו כל הגורמים האלה משפיעים.

[Dor1992]

@eran405
@batnun

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

הנה התמונה של הטבלה:
http://www.siz.co.il/my.php?i=unmnh2hdzzgd.jpg

בצבא הייתי בחיל תקשוב בבה"ד 7 והיה לי מבחן בכניסה לענף ההדרכה כמדריך. קיבלתי 78 וכדי לעבור צריך 80. התעקשתי שהבוחן טעה בתשובה לשאלה מסויימת ואף אחד לא הקשיב לי ודרשו ממני לעשות מבחן חוזר.

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

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


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

[Amir64]

@Dor1992
אתה לא מצליח להבין שמדובר על אותן יחידות, אבל מדברים על שני דברים?
מהירות תעבורה ורוחב פס הם שניהם "מהירות", כי שניהם מוגדרים באותן יחידות.
אחד מדבר על המהירות המקסימאלית התיאורטית בה מידע יכול לעבור בקו מסויים (המהירות המקסימאלית של רכב, לפי נתוני היצרן)
השני מדבר על כמה מידע בפועל עובר על אותו קו, בזמן נתון, בהתאם להרבה משתנים בדרך, שמשפיעים על המהירות הסופית. (בדיוק כמו מהירות הנסיעה בפועל שנקבעת לפי כמות הרמזורים הקיימים בדרך, הצטברות העמידה שלך באדום באותם רמזורים, כמה מהר אתה נוהג יחסית לנהג אחר...)

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

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

כלומר גם אם ישלחו לי חבילות על קווים עם רוחב פס עצום בסוף הם יעמדו בתור ויתקעו בכניסה לקו שלי כי הוא רזה מידי ויכול להכיל 200mb בשניה.ככה שהוא יעביר לי 200mbit, עברה שניה. החבילות הבאות יכנסו לקו ויעביר לי אותם וכך הלאה.

...

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

מה שאתה מתאר זה כמו סטרימינג ברשת ולא העברה רגילה.
בסטרימינג אין אישור כמו בתעבורה "רגילה".
נניח שנטפליקס משדרים טלויזיה ב- 4K, כל התשתית עד לחיבור שלך תומכת בהעברה כזו,
ולהעברה כזו דרוש קצב נתונים של 15mbps.
לך יש חיבור 10mbps.
מה אתה חושב שיקרה? תוכל לראות את הסרט?

[Dor1992]

@Amir64
·

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

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

ב. לגבי הסטרימינג כן, במצב כזה כנראה שאחווה תקיעות כל כמה שניות בסרט כי הקו שלי מסוגל להכיל רק 10mbps ולסרט יש ביטרייט של 15mbps.

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

ועוד משהו, אם אתה אומר שהשיהוי של החבילות בדרך אליי הוא כל כך זניח מכל מקום בעולם אז למה ea sports תמיד יתנו במשחקים יריבים שהשיהוי של החיבור שלי אליהם נמוך? הרי זה גם ככה כל כך זניח והחבילות עוברות במהירות האור בתווך הפיזי.
בנוסף לזה, כל התקשורת של אונליין בea sports מבוססת על udp בלבד ככה שהשיהוי עוד יותר זניח!

תסתכל על ההסבר שלי שנשמע לי הכי הגיוני:
יכול להיות שבגלל השיהוי היותר גבוה מול מדינה רחוקה, יש יותר אובדן מנות! ואז בעצם הthroughput שאני רואה הוא פחות מהארץ!

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

[ufffnick]

@Dor1992
·

בהחלט לימדת אותנו הרבה תצורות של לעשות סלט.
למהירות האור (שזו מהירות המקסימלית של העברת מידע, נכון להיום) אין שום קשר למה שבעברית קוראים מהירות העברת נתונים (בצורה שגויה) שכן זה אמור להיות קצב העברת נתונים.
המילה קצב יותר מתאימה כי מתארת גודל (כלשהו) ליחידת זמן. כמו קצב הגעת לקוחות לסניף איקאה, בממוצע, כך גם קצב הגעת הנתונים בממוצע.
במקרה הזה, הממוצע מתייחס לממוצע על מקטע זמן, שבו העברתי 60 מגה בחצי דקה יתורגם לקצב העברת נתונים של 2 מגה לשנייה בממוצע.
למה המונח הנכון לומר בסוף המשפט "בממוצע"?
שתי סיבות -
1. חילקתי את סך נפח הנתונים שהגיע לסך הזמן שלקח לו להגיע, ולכן מצעתי על מקטע הזמן.
2. הנתונים מגיעים באופן דיסקרטי, וכדי להשלים נגיד 1 מגה של 0ים ו1ים, תקבל קצבים שונים של העברה כפונקציה של תדירות העברת המידע. ככל שהתדר גבוה יותר, נפח התעבורה גבוה יותר.

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

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

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

[Dor1992]

@ufffnick
·

א. סתם שתדע באונליין לרוב אין שרת משחק אלא חיבור p2p. ככה שאין יתרון לאף אחד ואם יש לאגים יהיו בשני הצדדים.

ב. לגבי מדינות ערב. בדקתי. בכולן פינג של לפחות 120 ותפוקה של מקסימום 130mbps. אין לנו חיבור ישיר מול מדינות ערב לדעתי.. גם לא מול המדינות השכנות.. החיבור שלנו הוא לאיטליה ככה שיש סיבוב גדול.

ג. שוב אנחנו מגיעים לאותה נקודה שהתפוקה יורדת בגלל השיהוי לפי מה שאתה אומר. אבל, @amir64 ו @batnun טוענים שהשיהוי הזה של 120-160 כל כך זניח שאין סיכוי להרגיש שינוי בתפוקה בין ישראל לבין מדינות רחוקות.
אתה טוען אחרת מהם וגם התוצאות שאני מביא טוענות אחרת.

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

בואו נסתנכרן שניה במקום להאשים אותי שאני עושה סלט כי כולם סותרים אחד את השני כאן.

[ufffnick]

@Dor1992
·
הבנת הנקרא -
אני טוען, כמו האחרים, שהשיהוי זניח בהשפעה על התפוקה.

[Scanner]

עברתי עכשיו (כמעט) על כל השרשור - דור, גם למיטב ידיעתי אתה טועה (בתרחיש סביר).
ההשפעה של ה-Latency תהיה זניחה (וכנראה לא קיימת) על ה-throughput שלך. רק בתרחישי TCP מסוימים ובהעברת קובץ קטן מאוד בהשהייה גבוהה במיוחד (מעל מאות ms) תחווה את הפגיעה (לדוגמה, העתקת קבצים קטנים ב-SMB על גבי לינק לווייני בעל השהייה גבוהה).

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

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

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

מקווה שתקבל את ההודעה באופן חיובי.

דניאל - מנהל רשת ו-CCNP R&S & WIFI ובעל הסמכות נוספות מעולם ה-IT והאבטחה.

[Dor1992]

@Scanner
·

תודה אחי. מקווה שתעיין לעומק בהודעה שהבאה כי יש כאן לדעתי טעם במסקנות:

בדקתי עכשיו עם מחשבון throughput ואכן latency של 160 לא משפיע על הthroughput.

התרחיש שאיזשהו שרת בדרך לארה"ב מגביל פתאום את רוחב הפס ל160mbps נשמע לי לא סביר.. כי אם מול כל השרתים בארץ אני מקבל 200-203 mbps אז אני בספק שבמדינות מתקדמות אחרות איזשהו שרת מגביל רוחב פס לבדיקות מהירות דרך speedtest. ואני אומר מדינות מתקדמות כי למיטב ידעתי במסלול בינינו לבין ארה"ב אנחנו עוברים לאירופה ומשם ישירות לארה"'ב דרך הים.

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

אבל מה הבעיה? ניסיתי לעשות לאותם שרתים בדיקות פינג בcmd ואני רואה 0% אובדן מנות. ככה שמכאן אני משער שאולי בחבילה עלובה של פינג אין אובדן מנות אבל כשמדובר במספר חבילות יותר גדול יש אובדן מנות.

אני מנסה פשוט לחשוב ולחשוב איפה הבעיה.

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

מה שאני רואה באופן קבוע שמול מדינות רחוקות כמו ארה"ב מד המהירות מאיץ יותר איטי.
מכאן המסקנה שלי נשנעת על דבריך ש"בחבילה הראשונה מרגישים ירידה בתפוקה בגלל הlatency".
אם אפעיל את ההיגיון, החבילה הראשונה שנשלחת היא בקשת התקשרות. אותה חבילה קטנה כבר נמדדת בתפוקה. עכשיו מה הבעיה בספיד טסט? שהוא לא ממשיך לבקש מהשרת עוד ועוד נתונים. אני בעצם מקבל אותו מספר חבילות כמו שאני מקבל משרת בתוך הארץ.
ומה המסקנה? שבסוף נגמרות החבילות כבר והמד לא יכול להמשיך ולעלות ל203mbps. ככה שהlatency של החבילה הראשונה הוא זה שהשפיע על הthroughput.