עד אתמול היתה לי בד"כ מהירות מקס' (5M) ב 720P , אתמול והיום זוועה.

כל השאר הגלישה/הורדות כרגיל.

הוט + אקספון

הבעייה עדיין נמשכת, למעט בשעות הבוקר.

כל השאר הגלישה/הורדות כרגיל, זה יכול להיות בגלל הספקית ?

YouTube הוא אתר עם תשתית מאוד מבוזרת. מהתיאור שלך לא מובן בכלל מה בדקת ומה היו ממצאים?

במשך 3 שבועות (מאז שהגדלתי ל 5M) עד יום רביעי האחרון היתה לי ב YouTube בד"כ מהירות מקס' (5M) ב 720P , כלומר הסרטון נטען בלי הפסקות במהלך הצפייה. וכמובן בלי הפסקות גם ב 480P.

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

זה המצב בכל סרטון שאני מנסה (חדשים וישנים מכל מני ערוצים עם הרבה או מעט צפיות) וכן בזה http://www.youtube.com/my_speed.

תודה.

יכול להיות שיש בעיית עומס זמנית אצל הISP (ראית אם התוכן נטען משרתי ה cache שלהם או CDN מקומי?).

לפי ה resource monitor הכתובת היא

2a00:1450:400d:2::12

מה זה אומר ?

נ.ב.

עכשיו אני מקבל מהירות ממוצעת של 0.2M

אין מצב שאתה מתחבר לYouTube ב IPv6.

תשמשת בכלי נורמלי כמו TCP View.

לי יש 12M והוא מראה לי באתר של יוטיוב רק 8MB , בתכלס אצלי היוטיוב איטי רצח!

ליוטיוב יש בעיות חמורות בשרתים שלהם קפיצות בקצב...

גם כאשר הייתי בארה"ב המצב היה בקרשים

העתק הדבק מ TCP View

firefox.exe  2084  TCPV6  [2a02:ed0:800:0:4cd0:556f:1e77:9128]  55860  [2a00:1450:400d:2:0:0:0:12]  http  ESTABLISHED  1  2,999  583  1,002,960    12,060    9    

טוב

ביטלתי את ה IPv6 בחייגן ועכשיו YOUTUBE חזר למוטב. (:

IPv6 באקספון שעובד (איכשהו)? נשמע מעניין.

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

http://arstechnica.com/web/news/2011/06/world-ipv6-day-went-mostly-smoothly-with-a-few-surprises.ars

Not long after the start of the experiment, someone reported that www.nist.gov didn't work. However, NIST's IPv6 address did appear to be reachable. When I asked for a webpage, it just didn't produce any results. This changed when I set the maximum packet size on my network connection to 1280, which is the "minimum maximum" specified for IPv6—in other words, every IPv6 system must be able to handle packets of at least 1280 bytes. With the new setting, my computer would tell the NIST Web server that I can only handle 1280-byte packets. And then everything worked.

So NIST was suffering from a path MTU discovery problem, probably the result of a filter that filters IPv6 ICMP packets that routers send to make IPv6 systems adjust their packet sizes where necessary. This is a problem that's hard to debug, because it only shows its ugly face when communicating over a path that has a packet size limitation. Most of the Internet uses the standard 1500-byte Ethernet (or larger) packets so the problem doesn't occur.

סתם רעיון הזוי: אולי זה קשור ל World IPv6 Day שהיה בשמיני ליולי (שאז התחילו לך הבעיות).

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

עריכה: multicore הקדים אותי, לא חשוב.

העיקר הכוונה.

ממה שראיתי ב TCP View רק ליוטוב היה IPv6.

לא יודע למה בכלל היה מסומן לי גם IPv6 בחייגן.

מעניין שבבקרים זה כן עבד טוב.