Edge-home-orchestration-go: فترة تحديث معلومات المورد

تم إنشاؤها على ١ سبتمبر ٢٠٢٠  ·  7تعليقات  ·  مصدر: lf-edge/edge-home-orchestration-go

هل طلب الميزة الخاص بك متعلق بمشكلة؟
حاليًا ، الفاصل الزمني لتحديث معلومات المورد هو 5 ثوانٍ والدقة منخفضة جدًا.
فيما يلي سجل للوقت الذي تلقت فيه منظمة Edge بشكل متسق طلبات إلغاء تحميل الخدمة. (انظر الوقت واستخدام وحدة المعالجة المركزية)

2020/09/01 08:00:38 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:38 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:39 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:41 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:42 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:43 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:44 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:44 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:45 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:46 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:47 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:47 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:48 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000452635]
2020/09/01 08:00:49 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:49 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:50 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:51 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:52 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:52 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:53 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0]
2020/09/01 08:00:54 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0]
2020/09/01 08:00:54 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0]
2020/09/01 08:00:56 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0]
2020/09/01 08:00:57 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0]
2020/09/01 08:00:58 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:00:59 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:00:59 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:01:00 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:01:01 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]

صِف الحل الذي تريده
ماذا عن تحديث معلومات المورد أثناء تنفيذ الخدمة (الحاوية)؟

enhancement

ال 7 كومينتر

@ t25kim شكرا لك على الاقتراح المثير للاهتمام. (ربما أكون على صواب أو خطأ ، لذا يرجى تصحيح ذلك ^ ^) يبدو دائمًا أن التحديث المستند إلى الأحداث و / أو بعض آلية التحديث الديناميكي (الفاصل الزمني) ذات قيمة. النقطة المهمة هي كيف يمكننا دمج هذه الفكرة في edge-home-orchestration-go . بالإضافة إلى ذلك ، قد يكون من المثير للاهتمام إذا قمنا جميعًا بتقدير أي تأثير لبصمة الذاكرة على طلب تحديثات الموارد هذه مع تبني هذه الفكرة. هل لديك أي فكرة أخرى لتبدأ بها؟

@ Karthikeyan-Samsung @ suresh-lc ما رأيك في هذا الاقتراح؟

سيؤثر تقليل التردد على أداء الجهاز علاوة على ذلك ، يحتاج مدير التسجيل إلى تحسين واستنادًا إلى نهج ML (السلسلة الزمنية ، ARIMA ، إلخ ...)

تعتبر فكرة الاستناد إلى الأحداث فكرة جيدة ، لكننا بحاجة إلى استكشاف التسجيل في الأحداث التي تظهر تغيير وحدة المعالجة المركزية / الذاكرة. ويجب أن نحاول جعلها عامة بدلاً من اعتمادها على الأجهزة. كما ذكر كارثيك ، فإن أساس السلاسل الزمنية هو نهج جيد. نحن بحاجة إلى تبادل الأفكار للحصول على بيانات لمثل هذا التحليل أيضًا. هذه بداية جيدة ويمكننا مناقشة المزيد حول هذا الموضوع.

من منظور بعيد ، من الصواب الذهاب كما قال @ Karthikeyan-Samsung.
على المدى القصير ، بالنظر إلى الوضع الحالي ، أعتقد أنه يجب تحديث معلومات المورد ديناميكيًا عن طريق تغيير الوقت الثابت حاليًا وهو 5 ثوانٍ.
على سبيل المثال ، يعد الفاصل الزمني 5 ثوانٍ جيدًا إذا كان هناك القليل من الموارد المتبقية وكانت المعلومات صحيحة. ومع ذلك ، يجب أن نفكر في الفاصل الزمني بجدية في الحالة المعاكسة (نقص الموارد والمعلومات غير الصحيحة) لأنه من الخطير القول أن هناك العديد من الموارد المتاحة عندما يكون هناك القليل من الموارد المتاحة.

@ suresh-lc @ Karthikeyan -Samsung edge-home-orchestrator-go ؟ ^ ^ آمل في الحصول على أي فكرة جيدة عن هذا. (في النهاية ، يبدو أنه يعتمد على الأحداث المدفوعة)

أعتقد أن StartMonitoringResource () قد يحدد الفاصل الزمني مع معلومات المورد في ديسيبل ويرسل القيمة
ما يهمني هو العتبة والخوارزمية لتحديد الفاصل الزمني.

أعتقد أن StartMonitoringResource () قد يحدد الفاصل الزمني مع معلومات المورد في ديسيبل ويرسل القيمة
ما يهمني هو العتبة والخوارزمية لتحديد الفاصل الزمني.

يبدو أن هذا مرتبط أيضًا بما يسمى AI / ML الذي يعكس نمط المستخدمين. مثل التحديث المتكرر خلال وقت الانشغال ، ونادرًا ما يتم التحديث خلال منتصف الليل أو شيء من هذا القبيل.

لذا ، أود أيضًا ربط هذه المشكلة بالرقم 26.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات