איכות השירות

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

עדיפות

ב-Android 11 ואילך, המודלים מוכנים עם תעדוף ב-NN HAL 1.3. העדיפות הזו היא יחסית למודלים מוכנים אחרים שבבעלות אותה אפליקציה. בביצועים עם עדיפות גבוהה יותר יכולים להשתמש במשאבי מחשוב רבים יותר מאשר בביצועים עם עדיפות נמוכה יותר, והם יכולים להקדים או להרעיב ביצועים עם עדיפות נמוכה יותר.

הקריאה ל-NN HAL 1.3 שכוללת את Priority כארגומנט מפורש היא IDevice::prepareModel_1_3. שימו לב ש-IDevice::prepareModelFromCache_1_3 כולל באופן משתמע את Priority בארגומנטים של המטמון.

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

  • לנהגים עם תמיכת תעדוף מובנית, מעבירים ישירות את השדה Priority למאיץ.
  • אפשר להשתמש בתור לפי עדיפות לכל אפליקציה כדי לתמוך בסדרי עדיפויות שונים עוד לפני שהביצוע מגיע להאצה.

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

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

מערכת Android מאפשרת לשירותים להבדיל בין אפליקציות שיחה שונות באמצעות שימוש ב-AID‏ (Android UID). ל-HIDL יש מנגנונים מובנים לאחזור ה-UID של האפליקציה הקוראת באמצעות השיטה ::android::hardware::IPCThreadState::getCallingUid. ב-libcutils/include/cutils/android_filesystem_config.h תוכלו למצוא רשימה של מזהי AID.

מועדים אחרונים

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

הקריאות ל-NN HAL 1.3 שכוללות את OptionalTimePoint כמועדים אחרונים כארגומנטים הן:

  • IDevice::prepareModel_1_3
  • IDevice::prepareModelFromCache_1_3
  • IPreparedModel::execute_1_3
  • IPreparedModel::executeSynchronously_1_3
  • IPreparedModel::executeFenced

כדי לראות הסבר על ההטמעה של מאפיין תאריך היעד בכל אחת מה-methods שלמעלה, תוכלו לעיין במנהל התקן לדוגמה של NNAPI ב-frameworks/ml/nn/driver/sample/SampleDriver.cpp.

קודי שגיאה

Android 11 כולל ארבעה ערכים של קודי שגיאה ב-NN HAL 1.3 כדי לשפר את הדיווח על שגיאות, ולאפשר לנהגים לתקשר טוב יותר על המצב שלהם, ולאפליקציות להתאושש בצורה חלקה יותר. אלו הערכים של קודי השגיאה ב-ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

ב-Android 10 ואילך, מנהל התקן יכול לציין כשל רק באמצעות קוד השגיאה GENERAL_FAILURE. החל מ-Android 11, אפשר להשתמש בשני קודי השגיאה MISSED_DEADLINE כדי לציין שעומס העבודה בוטל כי פג המועד האחרון או כי מנהל ההתקן חזה שעומס העבודה לא יושלם עד למועד האחרון. אפשר להשתמש בשני קודי השגיאה RESOURCE_EXHAUSTED כדי לציין שהמשימה נכשלה בגלל מגבלה של משאבים בתוך הנהג, למשל אם לנהג אין מספיק זיכרון לקריאה.

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

אימות

הפונקציונליות של איכות השירות נבדקת בבדיקות NNAPI VTS‏ (VtsHalNeuralnetworksV1_3Target). הבדיקות האלה כוללות קבוצה של בדיקות לאימות (TestGenerated/ValidationTest#Test/) כדי לוודא שהנהג דוחה תעדוף לא חוקי, וקבוצה של בדיקות שנקראות DeadlineTest‏ (TestGenerated/DeadlineTest#Test/) כדי לוודא שהנהג מטפל בזמנים מוגדרים לתפוגה בצורה נכונה.