יצא utorrent 2.0

[RLM]

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

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

הוא מוריד את המהירות.

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

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

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

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

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

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

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

זה פשוט כמה תחנות (hops - לרוב ראוטרים) הפאקט יכול לעבור לפני שהוא "מת".

בכל מקרה, גם אם לא היה TTL זה לא אומר שפאקטים היו מסתובבים כל הזמן בכל המקומות.

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

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

רק במידה ויש איזשהו routing loop אז הTTL ימנע את נדידת הפאקט.

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

בקר לPrivet NGN. זה פשוט עוד תעדוף, בדומה לגיימר.

[Klayhamn]

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

ודאי שהוא יודע. שמעת על IP פעם? על SUBNET?

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

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

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

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

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

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

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

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

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

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

על פי הטענה שלך --- נניח ויש לי קו 2.5 מגה-ביט, ואני מוריד כרגע טורנט ב-200KBPS, (כלומר בבדיקת התעבורה עצמה - ולא רק דרך התוכנה -- אני רואה שאכן עוברים 200KBPS) - אתה טוען ש-100KBPS אחרים הם "חסרים", כלומר הם לא מגיעים אלי בגלל "PACKET LOSS", ואילו רק היה הספק מכבה את המערכת שלו, הייתי נהנה מ-300KBPS. כמובן שזה כלל לא נכון. אם לא היה QOS אז יכול להיות שהייתי נהנה מ-1KBPS בזמן שמישהו אחר היה נהנה מ-900KBPS, ללא שום איזון.

עכשיו, בוא נניח ואכן הספק "מכבה" את מערכת ה-QOS ואני מגביל את עצמי ל-200KBPS... נו, במה שונה הדבר? האם אני משיג עכשיו מהירות גבוהה מ-200KBPS?! לא!! לכן אני לא מבין על מה אתה מדבר...

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

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

כך או כך -- אתה תוגבל לאותה המהירות.

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

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

תראה לי מקור אחד אמין שמדגים כיצד ה-THROTTLING האישי הזה "יעיל" יותר מה-QOS שמפעיל הספק

[RLM]

אתה פשוט לא מנסה להבין!

א', אני לא יודע מתי פעם אחרונה הסתכלת עם פאקט של IP - באף מקום לא מופיע subnet mask - זה נתון לניתוב בלבד.

דבר שני, בשום מקום לא כתבתי שהפטוקול הזה יכול לעקוף את הQOS של הספק!!

כתבתי שהוא יכול תיאורטית להחליף אותו. ולעשות את העבודה בצורה יותר יעילה,

כי הוא יודע למדוד את העומס בsession הקיים ולא בכללי!

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

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

זה כל הרעיון של flow control וTCP Window. כל העולם עובד ככה כבר שנים, ורק אתה בא להמציא את העולם מחדש.

[Klayhamn]

אתה פשוט לא מנסה להבין!

א', אני לא יודע מתי פעם אחרונה הסתכלת עם פאקט של IP - באף מקום לא מופיע subnet mask - זה נתון לניתוב בלבד.

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

דבר שני, בשום מקום לא כתבתי שהפטוקול הזה יכול לעקוף את הQOS של הספק!!

כתבתי שהוא יכול תיאורטית להחליף אותו. ולעשות את העבודה בצורה יותר יעילה,

כי הוא יודע למדוד את העומס בsession הקיים ולא בכללי!

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

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

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