הורדת פרקי טופגיר - בעייה..

[MustardMan32]

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

 

 

עמוס

[Tweet]

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

 

 

מאותגרת טכנולוגית = ADSL או חיבורי כבלים ומינהם....

מי שמע על UPLOAD של 96???? בתקופת המנדט הבריטי היה יותר בחו"ל...

 

 

אלון

(שהאימיול שלו רק מוריד ומוריד ומוריד - ולא מעלה כלום!)

[Igor_STI]

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

 

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

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

(וכמובן שהגלישה לא תעובד)

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

 

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

[NMP]

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

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

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

בכל connection נורמלי (tcp) ולא משנה בכלל מה אתה מוריד, מאיפה וממי, יש Overhead של ניהול גם על הצד השני (אני אתעלם מדברים שלא קשורים כל-כך לפה כמו streaming ודברים כאלה שגם להם יש אבל זניח ביותר).

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

 

עזוב את הויכוחים בשרשור הזה, לך תריץ emule, תוריד קובץ טוב עם הרבה מקורות ותשב עם מוניטור על הכרטיס רשת, לא מוניטור של netlimiter ובטח לא של התוכנה עצמה כי הם יראו לך את הנתונים ברמה של האפליקציה. בעצם, שב עם שניהם וככה תוכל להבין בדיוק את ההבדלים ולראות כמה overhead יש לך ברמה של ה-tcp/ip בשביל X מידע שאתה מוריד. אתה יכול לבודד את זה ולעשות את זה לאורך זמן, נאמר להוריד קובץ של 10M או 100M או משהו כזה ולראות כמה מידע עלה/ירד מהמחשב שלך בשביל להוריד את זה. נראה לי שאתה תופתע מהתוצאות.

 

אל תשכח גם שאנחנו מדברים פה ספציפית על emule ולא על הורדה פשוטה של קובץ עם connection אחד שרץ לכל האורך. אנחנו מדברים פה על תוכנה שפותחת אלפי חיבורים במקביל גם מהרבה מקורות שכרגע אתה לא באמת מוריד מהם ובודקת איתם מה יש להם ומה היא יכולה לקחת במקביל ללהגיד להם מה יש לך וכו'. ובנוסף כל מה שתיארתי הוא מאוד דינמי וכל הזמן סוגרים ופותחים חיבורים חדשים (שזה שוב three-way-handshake לכל פתיחה וסגירה כזאת). זה העומס הכי משמעותי פה.

 

ניר

[Igor_STI]

ניר אני מבין מצויין מה אתה אומר.

 

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

 

אני לא מדבר כרגע על האימיול, אלא בכללי.

ההשפעה היא יחסית מזערית ברוב הקווים (אני מדבר על קווי adsl)

 

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

 

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

(אני לא מדבר על האימיול, אימיול זאת תוכנה עם דרך פעולה מיוחדת)

 

אז בוא נסכים, יש השפעה אבל קטנה

[NMP]

אז בוא נסכים, יש השפעה אבל קטנה

אני חייב

 

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

במקרים הפשוטים יותר יש השפעה קטנה יחסית (ועדיין, תמיד יש קשר בין dl/ul).

 

בקיצור, נראה לי שסגרנו את הנושא

[gibsonlp]

נו, מה נסגר?

 

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

בגדול - עזוב emule עזוב נעלים - תוריד מFTP פשוט ותראה שהupload שלך בשימוש.

לצורך העניין הורדה של 1.5 מגהביט לשניה תגרור ackים בגודל של בערך 12 קילוביט לשניה (1.5 קילובייט).

מה שקורה ברגע שמורידים ממך באמצעות תוכנות peer to peer זה שהקו העולה חנוק. כ"כ חנוק שאותן חבילות ackים תקועות להן אי שם בתור להשלח ומעקבות את שליחת שאר החבילות מהצד השני (השולח לא ישלח יותר מחלון השליחה, זוכר?). ברשתות peer to peer הclients מאוד בררניים ובעלי timeout קצר מאוד, בד"כ עיקוב קטן לא רק יפגע לך במהירות אלא יגרום לניתוק שלך ואיבוד המקום בתור.

 

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

 

אלה היו 60 שניות של Networking 101...

 

גיל, שהיה תומך בStarNet/Artaxia לפני 10 שנים.

[aa123]

נו, מה נסגר?

 

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

בגדול - עזוב emule עזוב נעלים - תוריד מFTP פשוט ותראה שהupload שלך בשימוש.

לצורך העניין הורדה של 1.5 מגהביט לשניה תגרור ackים בגודל של בערך 12 קילוביט לשניה (1.5 קילובייט).

מה שקורה ברגע שמורידים ממך באמצעות תוכנות peer to peer זה שהקו העולה חנוק. כ"כ חנוק שאותן חבילות ackים תקועות להן אי שם בתור להשלח ומעקבות את שליחת שאר החבילות מהצד השני (השולח לא ישלח יותר מחלון השליחה, זוכר?). ברשתות peer to peer הclients מאוד בררניים ובעלי timeout קצר מאוד, בד"כ עיקוב קטן לא רק יפגע לך במהירות אלא יגרום לניתוק שלך ואיבוד המקום בתור.

 

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

 

אלה היו 60 שניות של Networking 101...

 

גיל, שהיה תומך בStarNet/Artaxia לפני 10 שנים.

גיל, אני מסכים איתך למעט משהו קטן...

 

ה-basic configuration של האפליקציה ברמת ה-IMGT לא תאפשר APB ברשתות P2P.

לכן, עבודה עם פרוטוקול SMGB תגרור NACKים ולא תאפשר WRT על ה-PQS.

 

ואם אין לאוטו שלך נהג, כנראה שהוא לא נוסע...

 

 

 

 

 

 

 

 

 

 

 

 

 

[explotion]

גיל, אני מסכים איתך למעט משהו קטן...

 

ה-basic configuration של האפליקציה ברמת ה-IMGT לא תאפשר APB ברשתות P2P.

לכן, עבודה עם פרוטוקול SMGB תגרור NACKים ולא תאפשר WRT על ה-PQS.

 

ואם אין לאוטו שלך נהג, כנראה שהוא לא נוסע...

 

 

 

מישהו מוכן לתרגם?

זה בערך נשמע ככה:

ערכתי ניסוי בהתכת Ag+ בMg-- ויצא תרכובת הומגונית שבתגובה עם קרני אלפא נוצר משקע

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

 

דברו ברור אנשים!

[NMP]

אביעד, הצלחת להפיל מישהו, אני מקווה שאתה מרוצה

[DaviX]

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

אם אתה רוצה לקחת את המתחים בנינו לקווים פרטיים,

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

[aa123]

אביעד, הצלחת להפיל מישהו, אני מקווה שאתה מרוצה

לפחות יש כאלה שחושבים שאני באמת חכם

[wil]

בד"כ מספיק להגביל את ההעלאה ל-80% מרוחב הפס הזמין, ואז הכל בסדר.

דוגמא: קו ADSL 1.5 מגהביט על 96 קילוביט - קצב העלאה זמין 96 קילוביט שהם 12 קילובייט בשניה.

80 אחוז מזה הם 9.6 קילובייט בשניה, כך שלהגביל באימיול ל9 או 10 ק"ב בשניה בד"כ יעשה את העבודה.

 

בחיבור כבלים 1.5/128 אפשר להיות יותר לארג'ים ולתת 12 ק"ב בשניה.

 

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

 

מי שיש לו כבלים יכול כיום לשדרג בעלות נמוכה למדי לחיבור עם 256 קילוביט העלאה או אפילו 1.5/512 כלומר חצי מגהביט העלאה - ואז המצב טוב בהרבה.

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

[NMP]

שים לב בהודעה שלי לגבי ההבדל בין התעבורה בכרטיס הרשת (שזה מה שמעניין וזה מה שמוגבל באמת ב-12kb שתיארת) לבין התעבורה של האפליקציה (כשאתה מגביל ב-emule או אפילו ב-netlimiter).

 

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

 

ניר