Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comments on your Plan #2

Open
gparmer opened this issue Feb 15, 2020 · 4 comments
Open

Comments on your Plan #2

gparmer opened this issue Feb 15, 2020 · 4 comments

Comments

@gparmer
Copy link
Contributor

gparmer commented Feb 15, 2020

You don't define what a state is, so quite a bit of this is still meaningless to me. The definition of the scheduler is pretty vague. You say that each task type for a server has separate weights, and that there are priorities. Given the formalism, I don't see priorities. These types of ambiguities make this document very difficult to parse and cause me to feel like I'm guessing and inferring most of your intention.

The way you've formalized this, the weights are part of the system state, and presumably the "controls to tweak" are weights. I am quite skeptical that that RL will do well in this scenario, but I could be wrong. (If the controls to tweak are the weights, say "tweak the weights"; if they aren't be specific. This loose wording means that I'm 100% guessing what you mean for this key aspect.)

This seems to be cool, and might be successful. I'm OK with it as a project. But right now I cannot guarantee it will work, or that you can complete it by the end of the semester. You're adding a huge amount of personal risk here by not conveying what you want to do succinctly. I think that you have work to do on the specificity of the setup and goal. If you think it is fine as is, then we can chat, but I'm not confident that will be more productive than writing this with a focus on removing ambiguity.

@ratnadeepb
Copy link
Collaborator

Thanks for the feedback. I see the problem you are pointing out. I will try and disambiguate the plan ASAP. But for now, the weights are controls to tweak. The priorities come in terms that compose is highest priority, read home timeline is middle priority and read an user's timeline is lowest priority. So, p_{compose} = 3, p_{read_home} = 2 and p_{read_user} = 1

@gparmer
Copy link
Contributor Author

gparmer commented Feb 15, 2020

OK, so the priorities are not part of the training/clustering, they are static. Then you can avoid discussing them for now.

BTW, I hope you like the name I chose as it has a few different meanings that all seem appropriate, but do feel free to change it.

@ratnadeepb
Copy link
Collaborator

I guess you are talking about the project name. I love word puns.

@ericwendt
Copy link

The main inquiry I have is how this will relate to the Internet of Things. Is there a way to use this scheduling approach in an embedded system? Is this the type of system that requires a lot of memory?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants