SUSE/phoebe

Towards a proof-of-concept for a wider audience

Opened this issue · 1 comments

I believe this project can gain more traction if we can showcase the project to a wider audience that adding artificial intelligence capabilities to Linux OS works, i.e. auto-tuning does indeed yield better performance. (I'm leaving out the self-healing part for now, as it seems harder than auto-tuning).

What I mean by wider audience is for someone with little knowledge of system and artificial intelligence to be able setup a scenario (or a benchmark), run the project and easily observe that the performance improved when auto-tuning is in action (ideally with all that done by a single script). To achieve that, there are still quite some challenges ahead.

First off, the scenario should be easy to setup. Right now we use TREX in our target scenario, which is not the easiest to setup; while its performance is superior, it support much less network interface cards compared to the Linux kernel. This is easily solvable to switching to other packet generators (e.g. iperf3, sockperf, ab, etc.), and is a minor issue compared to the next one.

Now, addressing the elephant in the room.

The core of Phoeβe lies in its brain, the decision making engine that will take system telemetry as input, and output a set of system-level parameters that improves the system's performance when applied.

But so far we have not been able to prove that this most curcial piece of the project works, that is, show that it can output system settings that does improve the system's performance. This is our second (albeit the major) issue we have that prevented us from showcasing the project to a wider audience.


I hope this proposal make sense, and if so, perhaps we can proceed to a discussion on how can we improve the decision engine (more data points for csv_files/rates.csv? collect more metric for the decision engine?) and have a simpler setup.

Hello @shunghsiyu ,

Yes, you are right, we are not yet able to prove the "improvement in performance" but that is highly dependable on having a setup IMHO. The setup needs to be stable in the sense that we can count on having it available for all the time we are required to run the benchmarks, etc. I think we are missing that for long time now.

Second, yes, eventually the engine will work better if the density of data points is higher then what we currently have. Again, we would need a setup to have different scenarios so to collect more metrics.

HTH.