Edge-home-orchestration-go: Resource Information Update Period
Is your feature request related to a problem? Please describe.
Currently, the resource information update interval is 5 seconds and the accuracy is too low.
The following is the log of when the Edge Orchestration consistently received service offload requests. (see time and cpuUsage)
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]
Describe the solution you'd like
How about updating resource information while the service(container) is executing?
t25kim
All 7 comments
@t25kim Thank you for the interesting suggestion. (Maybe I am correct or wrong, so please correct me ^^) Event-based update and/or some dynamic update (time interval) mechanism always looks valuable. The point is how we could integrate this idea into the existing edge-home-orchestration-go. Plus, it might be interesting if we all together estimate any impact of memory footprint on the requesting those resource updates with the adoption of this idea. Do you have any further idea to start with?
@Karthikeyan-Samsung @suresh-lc What do you think of this proposal?
MoonkiHong
on 1 Sep 2020
Reducing the frequency will impact the device performance Moreover the Scoring Manager algorthim need to be refined and based on ML approach(Time Series, ARIMA etc...)
Karthikeyan-Samsung
on 1 Sep 2020
Event based is good idea, but we need to explore for registering for events which show CPU/Memory change. And we should try to make it generic rather than hardware dependent. As mentioned by Karthik, time series based is good approach. We need to brainstorm for data for such analysis also. This is good start and we can discuss more on this.
suresh-lc
on 1 Sep 2020
In the long view, it's right to go as @Karthikeyan-Samsung said.
In the short term, considering the current situation, I think the resource information should be updated dynamically by changing the currently fixed time of 5 seconds.
For example, 5 seconds interval is fine if there are few resources left and the information is correct. However, we should think of the interval seriously in the opposite case (lack of resource and incorrect information) since it is dangerous to say that there are many resources available when there are few available resources.
t25kim
on 2 Sep 2020
@suresh-lc @Karthikeyan-Samsung @t25kim Thank you for all the productive and inspiring suggestions. If we need both the short and mid-long term approaches to improve the current resource update mechanism, is there any triggering means to modify the time interval to update the available resources from edge-home-orchestrator-go? ^^ Hope to get any of good idea about this. (In the end, it seems to be based on Event-driven)
MoonkiHong
on 2 Sep 2020
I think StartMonitoringResource() may determine the interval with the resource information in the db and send the value as a parameter to update resource information.
My concern is the threshold and the algorithm to determine the interval.
t25kim
on 3 Sep 2020
I think StartMonitoringResource() may determine the interval with the resource information in the db and send the value as a parameter to update resource information.
My concern is the threshold and the algorithm to determine the interval.
Seems this is also related to the so-called AI/ML reflecting users' pattern. Like frequent update during the busy time, and seldom update during midnight or something like that.
So, I would also like to link this issue with #26 .
MoonkiHong
on 17 Sep 2020
Related issues
t25kim
·
3Comments
t25kim
·
4Comments
MoonkiHong
·
4Comments
t25kim
·
3Comments
MoonkiHong
·
5Comments