הליבה של בדיקה אם סנכרון PTP כפול-עם חיישן תקין הוא אימות אם היסט הזמן יציב בטווח המיקרו-שניות והאם סטטוס העבד הראשי- תואם את הציפיות. להלן שלבים ספציפיים ומעשיים לבדיקה:
א. צפייה-בזמן אמת של היסט סנכרון (השיטה האינטואיטיבית ביותר)
הפעל את שירות PTP על חיישן שעון העבד וצפה ביומנים. זהו תקן הזהב לשיפוט דיוק הסנכרון.
בצע את הפקודה:
bash sudo ptp4l -i eth0 -m -q
הערה: יש להחליף את eth0 בשם ממשק הרשת האמיתי המחובר לרשת PTP; -m מציין הדפסת יומנים מפורטים, ו--q מפחית מידע מיותר.
קריטריונים לשיפוט
שים לב לשדה ההיסט ביומן הפלט:
סנכרון רגיל: ערך ההיסט יציב בתוך ±1~10 מיקרו-שניות (µs), עם תנודה מינימלית.
חריגות סנכרון: ערכי ההיסט נמצאים בטווח של אלפיות השנייה (מילישניות), או משתנים בצורה דרסטית (למשל, משתנים פתאום מ-+50µs ל-200µs).
לא מסונכרן: מצבי FAULTY תכופים מופיעים ביומנים, או שלא ניתן לבחור את השעון הראשי הטוב ביותר.
II. אמת את סטטוס התפקיד הראשי-
ודא ששני החיישנים יצרו כהלכה מערכת יחסים מאסטר-עבד כדי למנוע התנגשויות "מאסטר כפולות- או החלפות תכופות.
צפה בתוצאות הבחירות של BMCA
חפש את הביטוי "השעון הראשי הטוב ביותר שנבחר" ביומנים.
רגיל: יומן שעון העבד מראה שהוא זיהה את השעון הראשי ונכנס למצב SLAVE.
חריג: שני החיישנים מציגים את עצמם כ-MASTER, מה שמצביע על תצורת עדיפות שגויה או הפרעה בתקשורת.
בדוק את הגדרות עדיפות
ודא שערך העדיפות 1 של החיישן הראשי קטן מזה של חיישן העבד (למשל, מאסטר מוגדר ל-128, עבד מוגדר ל-130), וודא שהתפקיד קבוע ואינו משתנה באופן שרירותי עקב ריצוד רשת.
III. בדוק אם חותמת הזמן של החומרה יעילה
אם ההיסט הוא בטווח של אלפיות השנייה, זה בדרך כלל בגלל שחותמות זמן של חומרה אינן מופעלות, וכתוצאה מכך דיוק לא מספיק.
בצע את הפקודה:
`bash ethtool -T eth0`
קריטריונים לשיפוט: הפלט חייב להכיל 'SOF_TIMESTAMPING_TX_HARDWARE' ו-'SOF_TIMESTAMPING_RX_HARDWARE'.
אם רק 'תוכנה' קיימת, זה מציין כי נעשה שימוש בחותמות זמן של תוכנה, והדיוק אינו יכול לעמוד בדרישות להשוואת חיישן -דיוק גבוה-. יש לבדוק תמיכה במנהלי התקנים או בחומרה.
IV. ניטור יציבות-לטווח ארוך
תקינות-לטווח קצר אינה מבטיחה יציבות-לטווח ארוך. מומלצת-בדיקת מאמץ לטווח קצר.
שיא סחיפה
הפעל את `phc2sys` כדי לסנכרן את שעון חומרת ה-PTP לשעון המערכת ולבחון את ההיסט המקסימלי לאורך 24 שעות.
רגיל: הסחף לטווח ארוך- נשלט תוך מיקרו-שנייה אחת, ללא סטייה מצטברת.
חריג: ההיסט גדל באופן ליניארי לאורך זמן, מה שמצביע על כך שפיצוי תדר מתנד גביש אינו יעיל או שיש חביון רשת א-סימטרי.
שים לב לאובדן מנות. בדוק את יומני ה-PTP עבור פסק זמן של peer_delay או אזעקות פסק זמן סנכרון. מקרים מזדמנים נסבלים, אך מקרים תכופים דורשים בדיקת איכות כבל הרשת, עומס המתגים או הגדרות חומת האש (ודא שיציאות UDP 319/320 פתוחות).
V. טבלת פתרון בעיות נפוצה
|
תוֹפָעָה |
סיבה אפשרית |
הצעת פתרון |
|
קיזוז באלפיות שניות |
חותמת זמן של חומרה לא מופעלת |
בדוק את ettool -T, התקן את מנהל ההתקן הייעודי והפעל חותמת זמן של החומרה. |
|
החלפת עבדים-מאסטר תכופה |
הגדרות העדיפות זהות או דומות |
הגדל את ההבדל ב-Priority1 בין אדון לעבד (למשל, 128 לעומת 130). |
|
אין אפשרות לסנכרן לחלוטין |
חוסר זמינות רשת או חסימת חומת אש |
בדיקת קישוריות פינג, השבת את חומת האש או אפשר יציאות UDP 319/320. |
|
תנודות קיזוז גדולות |
ריצוד רשת או עומס גבוה |
בודדים תעבורת PTP, אפשר QoS במתג כדי לתעדף מנות PTP. |
