בעיות במשחקים ברשת עם מתאמי GoFiber GF10SK ו-GF10C רק בתשתית בזק

ufffnick · שליחה #61 29/04/2026 18:42

תנסה מהקוד שאני הרצתי, זה שרת בפרנקפורט.

$ iperf3 -c fra.speedtest.clouvider.net -u -p 5200 -b 2500M -t 30 -i 1
Connecting to host fra.speedtest.clouvider.net, port 5200
[  5] local 10.0.0.110 port 39705 connected to 91.199.118.184 port 5200
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   114 MBytes   956 Mbits/sec  83098  
[  5]   1.00-2.00   sec   114 MBytes   956 Mbits/sec  83019  
[  5]   2.00-3.00   sec   114 MBytes   956 Mbits/sec  83019  
[  5]   3.00-4.00   sec   114 MBytes   956 Mbits/sec  82981  
[  5]   4.00-5.00   sec   114 MBytes   956 Mbits/sec  83004  
[  5]   5.00-6.00   sec   114 MBytes   956 Mbits/sec  82971  
[  5]   6.00-7.00   sec   114 MBytes   956 Mbits/sec  83009  
[  5]   7.00-8.00   sec   114 MBytes   955 Mbits/sec  82943  
[  5]   8.00-9.00   sec   114 MBytes   957 Mbits/sec  83039  
[  5]   9.00-10.00  sec   114 MBytes   956 Mbits/sec  82914  
[  5]  10.00-11.00  sec   114 MBytes   956 Mbits/sec  83046  
[  5]  11.00-12.00  sec   113 MBytes   949 Mbits/sec  82410  
[  5]  12.00-13.00  sec   113 MBytes   944 Mbits/sec  82103  
[  5]  13.00-14.00  sec   109 MBytes   913 Mbits/sec  79133  
[  5]  14.00-15.00  sec   112 MBytes   942 Mbits/sec  81805  
[  5]  15.00-16.00  sec   114 MBytes   956 Mbits/sec  82902  
[  5]  16.00-17.00  sec   114 MBytes   956 Mbits/sec  83076  
[  5]  17.00-18.00  sec   114 MBytes   956 Mbits/sec  83024  
[  5]  18.00-19.00  sec   114 MBytes   956 Mbits/sec  82967  
[  5]  19.00-20.00  sec   114 MBytes   956 Mbits/sec  82996  
[  5]  20.00-21.00  sec   114 MBytes   956 Mbits/sec  82915  
[  5]  21.00-22.00  sec   114 MBytes   953 Mbits/sec  82811  
[  5]  22.00-23.00  sec   114 MBytes   954 Mbits/sec  82838  
[  5]  23.00-24.00  sec   111 MBytes   933 Mbits/sec  81001  
[  5]  24.00-25.00  sec   113 MBytes   945 Mbits/sec  82027  
[  5]  25.00-26.00  sec   114 MBytes   953 Mbits/sec  82769  
[  5]  26.00-27.00  sec   114 MBytes   956 Mbits/sec  82986  
[  5]  27.00-28.00  sec   114 MBytes   956 Mbits/sec  82989  
[  5]  28.00-29.00  sec   114 MBytes   956 Mbits/sec  82993  
[  5]  29.00-30.00  sec   114 MBytes   956 Mbits/sec  83023  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-30.00  sec  3.33 GBytes   952 Mbits/sec  0.000 ms  0/2479811 (0%)  sender
[  5]   0.00-30.39  sec   899 MBytes   248 Mbits/sec  0.078 ms  0/2479799 (0%)  receiver

iperf Done.

DanielGR · שליחה #62 29/04/2026 19:58

תודה. אין צורך למיטב הבנתי בפורט ספציפי 5200 (פרמטר -p 5200) ואצלי - אם משתמשים בו הוא לא נותן את נתוני ה- Loss משום מה. השרת הזה זמין יותר שזה עוזר לבדיקות. התוצאה - 0% loss

הבדיקה הזו מבטאת את מה שרואה השרת המרוחק כתוצאה מ-Upload. אפשר לבדוק בכיוון השני עם פרמטר -R - Reverse mode ואז התוצאה תשקף את מה שרואה המחשב המקומי כתוצאה מ- Download. בבדיקה שערכתי קצבים נמוכים יותר - פחות מ-500mbps יצרו 0% Loss ואילו העלאה של הקצב גרמה ל- Loss משמעותי.

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

Jabberwock · שליחה #63 29/04/2026 20:21

זאת התוצאה שלי:

קוד: בחירת הכל

iperf3 -c fra.speedtest.clouvider.net -u -b 900M -t 30 -i 1
Connecting to host fra.speedtest.clouvider.net, port 5201
[  5] local 192.168.1.53 port 53820 connected to 91.199.118.184 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   106 MBytes   890 Mbits/sec  87133
[  5]   1.00-2.00   sec   107 MBytes   900 Mbits/sec  87958
[  5]   2.00-3.00   sec   107 MBytes   901 Mbits/sec  88041
[  5]   3.00-4.01   sec   107 MBytes   899 Mbits/sec  87914
[  5]   4.01-5.00   sec   107 MBytes   900 Mbits/sec  87837
[  5]   5.00-6.01   sec   107 MBytes   900 Mbits/sec  87992
[  5]   6.01-7.00   sec   107 MBytes   900 Mbits/sec  87795
[  5]   7.00-8.01   sec   107 MBytes   900 Mbits/sec  87907
[  5]   8.01-9.01   sec   108 MBytes   900 Mbits/sec  88130
[  5]   9.01-10.01  sec   107 MBytes   900 Mbits/sec  87846
[  5]  10.01-11.01  sec   107 MBytes   901 Mbits/sec  88046
[  5]  11.01-12.01  sec   107 MBytes   899 Mbits/sec  87774
[  5]  12.01-13.01  sec   108 MBytes   901 Mbits/sec  88115
[  5]  13.01-14.01  sec   107 MBytes   900 Mbits/sec  87723
[  5]  14.01-15.01  sec   107 MBytes   899 Mbits/sec  87948
[  5]  15.01-16.01  sec   107 MBytes   900 Mbits/sec  87867
[  5]  16.01-17.01  sec   107 MBytes   900 Mbits/sec  87831
[  5]  17.01-18.01  sec   108 MBytes   901 Mbits/sec  88166
[  5]  18.01-19.01  sec   107 MBytes   899 Mbits/sec  87870
[  5]  19.01-20.01  sec   107 MBytes   900 Mbits/sec  87950
[  5]  20.01-21.01  sec   107 MBytes   899 Mbits/sec  87631
[  5]  21.01-22.01  sec   107 MBytes   901 Mbits/sec  88017
[  5]  22.01-23.01  sec   107 MBytes   900 Mbits/sec  87935
[  5]  23.01-24.01  sec   107 MBytes   901 Mbits/sec  88039
[  5]  24.01-25.01  sec   107 MBytes   899 Mbits/sec  87807
[  5]  25.01-26.01  sec   107 MBytes   901 Mbits/sec  87972
[  5]  26.01-27.01  sec   107 MBytes   900 Mbits/sec  87905
[  5]  27.01-28.01  sec   107 MBytes   900 Mbits/sec  87820
[  5]  28.01-29.01  sec   107 MBytes   900 Mbits/sec  87830
[  5]  29.01-30.01  sec   107 MBytes   901 Mbits/sec  87935
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-30.01  sec  3.14 GBytes   900 Mbits/sec  0.000 ms  0/2636734 (0%)  sender
[  5]   0.00-30.12  sec  3.03 GBytes   865 Mbits/sec  0.027 ms  93603/2636734 (3.5%)  receiver

iperf Done.

נראה שיש 3.5% של איבוד נתונים.
שאלתי את סלקום אם אפשר לעבור לסיב של בזק, אמרו שהם לא מאפשרים את זה על פי מדיניות.

DanielGR · שליחה #64 29/04/2026 20:34

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

מתי כן משתמשים ב- UDP שאין לו מנגנון לשליחה מחדש? לדוגמא במדיה זורמת - אודיו / ווידאו, כאשר לתזמון יש משמעות, ואי אפשר לשלוח Packets מחדש. לכן לאובדן Packets יש השפעה מוגבלת, ערכים קיימים ונמוכים זה תקין.

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

Jabberwock · שליחה #65 29/04/2026 20:37

כמה יצא לך ללא R- ?

DanielGR · שליחה #66 29/04/2026 20:56

Jabberwock כתב: כמה יצא לך ללא R- ?
...

0%

whatevernevermind · שליחה #67 29/04/2026 22:16

קצת סדר בדברים..

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

2. אם בכל זאת רוצים לבדוק איבוד, יש לשלוח בקצב גבוה, רוחב פס נמוך, כמו שהמשחק עושה זאת, בלי להתקרב למגבלת רוחב הפס בין הנבדק לבין השרת. כלומר, לשלוח ולקבל ללא הרף חבילות מידע קטנות כך שמכפלת הפאקטות לשניה כפול הגודל הממוצע לא מתקרבת לרוחב הפס המקסימלי בין הנבדק לשרת. בפרט, הרבה מהדוגמאות iperf3 כאן היו בכלל בדיקות העלאה בעומס (2500 ללא -R בעצם גורם לך לשלוח לשרת בקצב של 2500 מגהביט לשניה, שכרגע אין בארץ חבילה כזו ללקוחות פרטיים.. לכן *חייב* להיות איבוד. אם רוחב הפס האפקטיבי בינך לבין השרת הוא 500 ואתה שולח ב2500, תקבל 20% הגעה כלומר 80% איבוד.

3. אם הבנתי נכון, לפותח השרשור יש חבילה של 1 מגה, וגם ברשותו GF25C שאיתו אין בעיות. אז למה לא פשוט להשתמש בו במקום ה-GF10SK?

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

DanielGR · שליחה #68 30/04/2026 8:53

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

במוד רגיל - לא Reverse אין מה להשתמש בקצבים מעל ה-Upload, הכתיבה מתבצעת ל-Buffer ולכן לא נכשלת.

יישומים רבים משתמשים ב-Keepalive לבדוק האם הצד השני מחובר. מימוש Keepalive ב-UDP בשילוב של אובדן Packets עשוי לגרום לניתוק. האם זה המצב? בלי Sniffer קשה לדעת, וזו לא בדיקה שאפשר לבצע בשירשור הזה.

Jabberwock · שליחה #69 30/04/2026 12:47

DanielGR כתב: במוד רגיל - לא Reverse אין מה להשתמש בקצבים מעל ה-Upload, הכתיבה מתבצעת ל-Buffer ולכן לא נכשלת.
...

כנראה שאין אצלי Buffer.
אם אני בוחר לשלוח 2500Mb אני אכן רואה את זה: גם במנהל המשימות וגם בראוטר ב-UI של ה-UCG-Fiber רואים 2.5G של העלאה.
עשיתי בדיקות נוספות ואילו אחוזי איבוד הנתונים במהירויות השונות:
10M - 0%
20M - 0%
40M - 0%
50M - 0.023%
100M - 0.24%
200M - 0.96%
300M - 2.2%

משמע, החיבור שלי לגמרי תקין בשביל גיימינג. כל עוד לא אעבור את ה-40Mbps ב-UDP.

DanielGR · שליחה #70 30/04/2026 20:38

התצוגה של iPerf נראתה לי קצת מטעה בסיטואציה הזו, כיצד נראה 0% כאשר הבדיקה דוחפת Packets בקצב גבוה יותר ממה שהחיבור מסוגל להעביר. אז עברתי שוב על צורת החישוב של iPerf ויש הסבר:

גודל ה-Packet של iPerf ב- UDP הוא 1460 בייט. בכל Packet נרשם מספר סידורי, וחותמת זמן. החישוב של ה- Packet loss מתבצע כך:

lost = (last_seq_received - first_seq+1) - total_received

דוגמא מספרית:
נניח Packets ממוספרות כך: 1,2,3,4,5,6,7,8,9,10
נניח ש-4,5 הלכו לאיבוד, למעשה הגיעו בפועל 8 (על ידי ספירה)
החישוב הוא:

(10-1+1)-8 = 2

זה מחושב כל אינטרוול זמן, ונסכם לסה"כ שהלכו לאיבוד.

זה הגיוני אבל עדיין לא מסביר מדוע נראה "0" כאשר משתמשים בקצבים גבוהים יותר ממה שהחיבור תומך. ההסבר הוא באופן שבו מתנהגת הסביבה: ה-Packets היוצאים מועברים לתור שמתרוקן על פי הסדר. מה שקורה זה שהתור מתמלא, וכל מה שמעבר לכך הולך לאיבוד - עד לסוף הבדיקה. להמחיש מספרית:
נניח שלתור נדחפו Packets 1-10, וכל מה שמעבר לזה הלך לאיבוד בצד השולח. הצד המקבל יראה מספרים סידוריים 1-10, וסה"כ הגיעו 10 כך שהאובדן הוא 0 - אבל כמובן שזה לא נכון.

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

ולחבר זאת לנושא השירשור:
זה לא שירשור על בדיקה של ביצועי חיבורים, בוודאי לא בעומסים. אם כל הפקטורים זהים פרט ל-ONT - דגמים GF25, ו- GF10SK, השאלה היא מה ה- ONT מדגם אחד עושה אחרת מדגם אחר? יש כמה אפשרויות, כאשר הבדיקה אמורה לענות של שאלה אחת: האם יש הבדל ב- Packet loss, ועל הדרך גם Jitter בין שני ה- ONT? זו שאלה מעניינת מעבר לתקלה הספציפית, שיכולה לעזור לדבג תלונות אחרות, וזו המוטיבציה "לחפור" בזה.

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

האם זה המקרה כאן? המימוש בנייד וב-XBOX של אותו משחק כנראה שונה מאד, הנייד כנראה רגיש למשהו שה-XBOX לא.

Jabberwock · שליחה #71 01/05/2026 15:12

DanielGR כתב: נניח שלתור נדחפו Packets 1-10, וכל מה שמעבר לזה הלך לאיבוד בצד השולח.
...

זה הסבר מצוין, אך עדיין לא מסביר איך זה שאצלך זה הולך לאיבוד לפני שהוא נשלח. ואצלי הוא הולך לאיבוד אחרי שהוא נשלח.
אם כך, כיצד אני מפעיל Buffer על ה-UCG-Fiber שלי?

whatevernevermind · שליחה #72 01/05/2026 17:59

DanielGR כתב: ניתן לבדוק packet loss לחיבור באופן הבא:
הערה מקדימה: packet loss קיים רק ב- UDP, ב- TCP קיים מנגנון של retransmission כך ששום אינפורמציה לא הולכת לאיבוד, מקסימום הקצב האפקטיבי יורד. כעת אם הפרוטוקולים של הבקרה של המשחק מיושמים ב- UDP אז יש משמעות או רגישות לאובדן Packets, אחרת - לא.
ניתן לבדוק באמצאות iPerf3 מול שרתי iPerf ציבוריים. יש להוריד את גרסת ה- iPerf3 האחרונה:
https://iperf.fr/iperf-download.php
ולהריץ את שורת הפקודה הבאה:

קוד: בחירת הכל
קוד: בחירת הכל
iperf3 -c iperf.he.net -u -b 2500M -t 30 -i 1
כאשר:
<div style="direction: ltr;">-c server name or IP
-u - UDP mode
-b bandwidth
-t test length in seconds
-i - update interval
ולשים לב לתוצאה, לדוגמא - תוצאה תקינה ללא אובדן Packets:

חשוב! - יש להשוות בדיקה כזו בין שני סוגי ה- ONT GF25C/GF10SK ולא להתייחס רק לערכים האבסולוטיים, וכך ניתן לשלול שוני בין שני ההתקנים המתבטא באובדן Packets
...

ההסבר שכתבת למה עלול להופיע 0% - יכול להיות נכון לפעמים, אבל לא בדרך כלל. השורה התחתונה היא ש-iperf3 משקר ומבצע כל מיני הערכות שאינן מה שקרה בפועל. הנתון היחיד שתמיד נכון הוא "כמות בתים שהתקבלה" ו"משך הבדיקה", מה שאומר שגם המנה שלהם (רוחב פס אפקטיבי) היא תמיד נכונה. כלומר, כל שורת הreceiver מלבד ה-lost/total datagrams.

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

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

whatevernevermind · שליחה #73 01/05/2026 18:05

Jabberwock כתב: זה הסבר מצוין, אך עדיין לא מסביר איך זה שאצלך זה הולך לאיבוד לפני שהוא נשלח. ואצלי הוא הולך לאיבוד אחרי שהוא נשלח.
אם כך, כיצד אני מפעיל Buffer על ה-UCG-Fiber שלי?
...

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

ufffnick · שליחה #74 02/05/2026 1:37

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

Jabberwock · שליחה #75 03/05/2026 11:36

יש לי מעל 1,000Mpbs העלאה...
התוצאות תקינות לגמרי אצלי בשרת פרנקפורט.
מוגבל לקצב העלאה. לכן הפקודה הקודמת עם הפרמטר:

קוד: בחירת הכל

-b 2500M

הייתה שגויה. כי אין לי 2.5G העלאה. לכן היה הרבה איבוד נתונים.
מה שלא הסתדר זה שאצל DanielGR היה 0% איבוד נתונים, אף על פי שקצב העלאה נעצר ב-500Mbps (מגבלת החבילה שלו) הרבה מתחת לניסיון שליחה של 2500Mbps.
לכן חשדנו שיש כאן Buffering.
אצלי כן מדווח נכון אחוזי איבוד נתונים.
מקווה שעכשיו זה מוסבר.

Flash.Fiber · שליחה #76 10/05/2026 16:37

whatevernevermind כתב: קצת סדר בדברים..
1. השרשור עוסק בתופעה דמויית ניתוק-רגעי בזמן משחק. כמויות המידע הנשלחות או יורדות בזמן משחק הן כנראה זניחות ביחס לרוחב הפס. לכן בדיקות ביצועים בעומס, שבעצם בודקות את רוחב הפס האפקטיבי ולא את האיבוד, אינן רלוונטיות.
2. אם בכל זאת רוצים לבדוק איבוד, יש לשלוח בקצב גבוה, רוחב פס נמוך, כמו שהמשחק עושה זאת, בלי להתקרב למגבלת רוחב הפס בין הנבדק לבין השרת. כלומר, לשלוח ולקבל ללא הרף חבילות מידע קטנות כך שמכפלת הפאקטות לשניה כפול הגודל הממוצע לא מתקרבת לרוחב הפס המקסימלי בין הנבדק לשרת. בפרט, הרבה מהדוגמאות iperf3 כאן היו בכלל בדיקות העלאה בעומס (2500 ללא -R בעצם גורם לך לשלוח לשרת בקצב של 2500 מגהביט לשניה, שכרגע אין בארץ חבילה כזו ללקוחות פרטיים.. לכן *חייב* להיות איבוד. אם רוחב הפס האפקטיבי בינך לבין השרת הוא 500 ואתה שולח ב2500, תקבל 20% הגעה כלומר 80% איבוד.
3. אם הבנתי נכון, לפותח השרשור יש חבילה של 1 מגה, וגם ברשותו GF25C שאיתו אין בעיות. אז למה לא פשוט להשתמש בו במקום ה-GF10SK?
עריכה ותוספת:
4. נכתב כאן על בדיקות בעזרת מתאם רשת קווי usb שמחובר לנייד. בגדול זה לרוב רעיון לא טוב - המתאמים מוסיפים עוד שכבת תרגום (של פרוטוקול usb). אבל בהנתן שזה כבר נבדק והתגלה שגם במקרה הזה הנייד חווה את הקפיצות/ניתוקים, המסקנה היא שהבעיה היא בהתנהגות הצולבת בין מימוש שכבת הרשת של ממיר הסיב ובין הנייד עצמו (לפני השליחה למתאם הרשת הקווי או המובנה האלחוטי), ובסבירות נמוכה יותר גם במה שביניהם (הנתב).
...

בהתחלה עברתי חברה לניסיון אז התחברתי לחבילה במהירות 1 ג'יגה עם מתאם GoFiber GF10SK ולאחר שהיו לי בעיות ברשת בעיקר במשחק call of duty בסמארטפון
התחלתי לשנות הגדרות בנתב מה שלא עזר.
אז הבאתי נתב אחר מאחותי כדי לדעת אם הבעיה בציוד שלי, עדיין הייתה בעיה.
מפה כבר התחלתי לחשוד שהגורם לכך הוא המתאם סיב, למרות שהוא היה חדש מהקופסה.
הבאתי מאחי מתאם סיב Gofiber GF25C אקטבתי אותו דרך השירות טכני ואיתו הכל עובד תקין.
כדי לבדוק שהבעיה במתאם GoFiber GF10SK בוודאות התחברתי שוב לבזק לחבילה 5 ג'יגה לצורך בדיקה וגם הייתה בעיה.
כנראה שהמתאם מעבד את החבילות שעוברות ברשת בשיטה או דרך אחרת שגורמת לכך שיהיו ניתוקים (Packet Loss).

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

Flash.Fiber · שליחה #77 10/05/2026 16:54

טוב חברים יקרים, מעריך מאוד את כל העזרה שלכם.
בשעה טובה לאחר עיכוב ארוך מאוד מצד חברת המשלוחים של בזק, הייתי בלי אינטרנט בגלל שהחזרתי את המתאם סיב, הגיע אלי המתאם סיב החדש שהזמנתי מבזק.
לשמחתי קיבלתי את המתאם סיב GoFiber GF10C שלא ניתן לקנותו יותר. ניתן גם להתחבר איתו בתשתית IBC.
לאכזבתי, עדיין יש אותה בעיה.
בהתחלה, מיד אחרי שאקטבתי אותו נכנסתי למשחק ושחקתי 15 דקות ללא שום תקלה ולאחר מכן הבעיה חזרה.
יש עוד דברים שעולים לכם לראש שיכולים לגרום לבעיה?
הדבר היחידי שנשאר לי לבדוק זה הנתב. מחכה בקוצר רוח לנתב BT10 עם פורטים 10 ג'יגה כדי לשלול או לוודא בעיה בקישוריות. אני בספק שזה הגורם אבל אין לדעת.

למי שמחובר עם מתאם GoFiber GF10C או GoFiber GF10SK יכול בבקשה לבדוק בסמארטפון במשחק Call of duty האם יש לו גם את התופעה הזו.
ושוב, תודה רבה לכולם!

Flash.Fiber · שליחה #78 10/05/2026 19:07

ביצעתי גם בדיקות דרך האתר:
https://packetlosstest.com/
לכל המשחקים שמופיעים שם
ואין לי כלל איבוד חבילות.
הבדיקה בוצעה בעיקר לשרת בגרמניה.

Jabberwock · שליחה #79 10/05/2026 19:19

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

ufffnick · שליחה #80 10/05/2026 19:42

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