PACKET LOSS רציני בבזק בינלאומי!!

שלום.. אני מנוי לספקית בזק בינאומי 014 1.5MB בלי ראוטר עם מודם 600E ADSL

לפני כחצי שנה התחלתי להרגיש לאגים מטורפים במשחקי און ליין FPS שונים אפילו בשרתים מקומיים ועל אף שהיה לי פינג 20 לשרת בו שיחקתי

(צילום של הלאגים תוך כדי משחק באמצעות FRAPS בפינג 70-80, אותם הפרעות יש לי גם בפינג 20.... http://www.gametrailers.com/player/usermovies/92957.html)

בנוסף.. להעלות קבצים מעל 50MB הפך לבלתי אפשרי, אפילו UTUBE ואתרים כמו FILEFRONT או RAPIDSHARE לא נותנים לי להעלות.. וסוגרים לי את הדף אינטרנט כתוצאה מהבעיות תקשורת

בפניה לתמיכה של בזק בינלאומי היו עושים איתי דרך CMD בדיקת TRACERT לשרתים בהם היו לי בעיות, והפינגים (MS) היה מראה פינגים נמוכים, ומשם טענתם היתה שמקור הבעיה לא מאצלהם (הם טענו שזה אולי התשתית.. הפיירוול\אנטיוירוס... חומרה.. רק לא הם).. האמנם?!

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

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

הרצתי את התוכנה לשרת ישראלי של המשחק BATTLEFIELD2 שיש לי בו פינג 20!! ונדהמתי לגלות שמתוך 100 פאקטים.. 73% הולכים לאיבוד

תמונה: (הרצתי את התוכנה ב04:30, לא בשעות העומס באינרנט)

לינק לתוכנה למי שמעונין להריץ בדיקה:

1) Visit ftp://ftp.ea.com/pub/origin/patches/uo/uotrace.exe and download the UOTrace program.

2) After installing this, open the program. If a pop up box appears telling you UO Server List not found, click "No".

3) Click the "Options" menu at the top of the window, and select "Advanced".

4) Next, in the rectangular window where the server is listed, type in master.gamespy.com and peerchat.gamespy.com to check the connection to the servers.

5) Click the button labeled "Trace route", which is the fourth button from the left.

6) After the trace route has completed, click the "Poll" button, which is two buttons to the right of the trace route button. This tells your computer to send data packets to the host server.

7) Let it send around 100 or so packets then select "Stop Poll".

תגובה של בזק בילאומי:

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

שהתחלתי להתשולל, נציגה של קשרי לקוחות הסבירה לי: "שהם מספקים אינטרנט לאימיילים ולפתיחת דפי אינטרנט"

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

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

ואני חייב עזרה של מישהו שמבין שיסביר לי..

האם חברת האינטרנט שלי הם נוכלים ?!

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

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

כי אני מרגיש שסובנתי טוב טוב על ידם ואני כבר לא יודע מי נגד מי..

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

CHEERS

המשפט הזה מאוד מוכר לי (הייתי בעבר ב-012 ו-ברק)

נציגה של קשרי לקוחות הסבירה לי: "שהם מספקים אינטרנט לאימיילים ולפתיחת דפי אינטרנט"

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

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

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

יגמר\ירד.

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

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

זהו! שום דבר לא יעזור לך גם אם תתנתק(במידה ותצליח)

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

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

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

משתמשי ספקית בזק בינלאומי תריצו בידקת PING מ-CMD לכתובת הזאת..

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

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

בפאקינג עזה יש להם אינטרנט יותר טוב

39 packets transmitted, 10 received, 74% packet loss, time 38000ms

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

הצטרפתי אליהם ללא מחוייבות, ולא יתכן שיגרם Packet loss במכוון

בשביל "להאיט" אותנו. נראה מה יהיה להם להגיד.

akma יש לך בעיה בדיוק כמו שלי.

הספקית שלי גם בזק בינלואמי ותשתית בזק.

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

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

הנה אפילו פרסמתי על זה פוסט כאן - http://hwzone.co.il/community/index.php?topic=335875.0

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

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

גם אני איבדתי הרבה פוקטים בבדקיה ב CMD.

אני כבר התיאשתי, אני נראה לי מחליף ומנסה את הכבלים בהוט. , או שיש פה מישהו שיהיה המושיע וידע איפה באמת הבעיה!!?

אני משתתף בצערך akma :-[

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

למשל לYNET אין לי איבוד מידע...

של מי ה IP הזה ? 192.115.186.77 ?

של מי ה IP הזה ? 192.115.186.77 ?

האייפי הזה זאת כתובת לשרת של בזק.. דרכו עובר החיבור לרוב השרתים, בארץ ובעולם

יש עוד כמה שרתים עם אותו שם (STATIC) שעושים את אותה בעיית פאקטים

נראה לי ששרתי הSTATIC מאפשרים להם לשלוט ברוחב הפס ובהגבלה לכל המשתמשים

אם תשתמשו בתוכנה שהבאתי להעלה + מדריך, אתם תראו ותבינו לבד

תשתדלו לקרוא בעיון

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

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

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

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

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

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

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

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

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

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

ידידי היקר...

אנחנו הקליינטים! לנו יש את הכוח! אנחנו אלה שמשלמים את הכסף!

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

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

90% מהמשתמשים של בזק בכלל לא קולטים שעושים עליהם ערימות של $$$

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

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

תביטו שוב בתמונה: לכל נתב בדרך התוכנה שלחה 100-101 פאקטים. כבר בנתב השני אובחן אובדן משמעותי של 63% מהפאקטים ואת הנתב השלישי אף פאקט לא עבר. אלא מה, מהנתב הרביעי והלאה הכל נראה תקין, עם 100% הצלחה. איך זה יתכן? הרי כדי להגיע לנתב הרביעי, הפאקט צריך לעבור קודם דרך השני והשלישי?

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

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

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

רם קיבלתם קפיצה גדולה בזמן החזרה בנתב n ובכל הנתבים שאחריו, סימן שיש איטיות בנתב n או בינו ובין n-1. לו הבעיה היתה רק בזמן שלוקח לתשובות לחזור, היא היתה משפיעה רק על הזמן של נתב n ולא על זה של n+1 והנתבים שאחריו, שהיו עונים בזמן נמוך יותר. אפשר לראות את זה בדוגמה המקורית: שני הנתבים הראשונים שעונים מגיבים מהר יחסית, עד 20ms. הנתב הרביעי, שכבר נמצא בצרפת, עונה ב- 71ms וכך גם החמישי. השישי ומעלה נמצאים בארה"ב וזמן התגובה שלהם עולה בהתאם ליותר מ- 160ms.

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

תוספת: לפני שמנסים traceroute, יש לבצע ping אל השרת אליו מנסים להגיע. תנו מספר גדול מספיק של פאקטים לפינג, נאמר 100. כל עוד קיבלתם זמני תגובה סבירים ואובדן של פחות מאחוזים בודדים, אין טעם לבדוק traceroute - הכל נראה תקין. רק אם הפינג מראה חשד לבעיה, אם בזמני תגובה מאוד גבוהים או ב- packet loss משמעותי, יש טעם לבדוק traceroute כדי לנסות לאתר את המקום בו מתרחשת הבעיה.

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

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

ולמה הבעיה הזאת נוצרת?

יש לי חברים עם upload יותר נמוך משלי ואין להם שום בעיות

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

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

תביטו שוב בתמונה: לכל נתב בדרך התוכנה שלחה 100-101 פאקטים. כבר בנתב השני אובחן אובדן משמעותי של 63% מהפאקטים ואת הנתב השלישי אף פאקט לא עבר. אלא מה, מהנתב הרביעי והלאה הכל נראה תקין, עם 100% הצלחה. איך זה יתכן? הרי כדי להגיע לנתב הרביעי, הפאקט צריך לעבור קודם דרך השני והשלישי?

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

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

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

רם קיבלתם קפיצה גדולה בזמן החזרה בנתב n ובכל הנתבים שאחריו, סימן שיש איטיות בנתב n או בינו ובין n-1. לו הבעיה היתה רק בזמן שלוקח לתשובות לחזור, היא היתה משפיעה רק על הזמן של נתב n ולא על זה של n+1 והנתבים שאחריו, שהיו עונים בזמן נמוך יותר. אפשר לראות את זה בדוגמה המקורית: שני הנתבים הראשונים שעונים מגיבים מהר יחסית, עד 20ms. הנתב הרביעי, שכבר נמצא בצרפת, עונה ב- 71ms וכך גם החמישי. השישי ומעלה נמצאים בארה"ב וזמן התגובה שלהם עולה בהתאם ליותר מ- 160ms.

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

תוספת: לפני שמנסים traceroute, יש לבצע ping אל השרת אליו מנסים להגיע. תנו מספר גדול מספיק של פאקטים לפינג, נאמר 100. כל עוד קיבלתם זמני תגובה סבירים ואובדן של פחות מאחוזים בודדים, אין טעם לבדוק traceroute - הכל נראה תקין. רק אם הפינג מראה חשד לבעיה, אם בזמני תגובה מאוד גבוהים או ב- packet loss משמעותי, יש טעם לבדוק traceroute כדי לנסות לאתר את המקום בו מתרחשת הבעיה.

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

שורה תחתונה..

במי האשמה שהפאקטים לא הגיעו?

תשובה של פוליטיקאי: לא זו השאלה, רפי. 8)

הפאקטים הגיעו. עובדה, מהשרת אליו רציתם להגיע קיבלתם 100% מהם בחזרה.