- This week I first helped make our final presentation slides. I am the one who presented this week and wanted to give the best presentation possible, so I also spent a bunch of time studying the slides and practicing both by myself and in front of others. For project work: I first helped Thomas set up and figure out how to use the new lights we ordered. Once we were confident in our ability to control them I set up the communication between the raspberry Pi and the lights. Since the lights need to operate on a while true, receiving communication from the first pi makes the light commands slower, so we split up the listening ports between the song recommendations and the lights so the lights will only get sent a message about once every three minutes. We will be running these programs concurrently on the second raspberry pi. I next wanted to fix the user keep alive. I am not really sure what I was thinking last week in my solution. Having a user that switches off the screen automatically deemed inactive is not very smart. I scrapped all of my old solutions and made this one: The server will set a time once it starts running and on every user connection they will receive this time. Also the backend will check every 30 minutes (could be changed) for all the users that are inactive. The way to tell the server that you are active is if you have had a screen interaction within the 30 minute server block. I do this by checking (on every user action) if the last action is earlier than the last inactive check by the server. If so then I send a message to the server saying that the user is inactive. Every 30 minutes the server sets everyone to inactive after removing the likes for all the new inactive users from the last 30 minutes. I then ran the concurrent user tests which I will talk about in the testing section
- Testing:
Queue and reccomendation latency. 102 ms (20 trials) for Queue and 6.2 seconds (20 trials) for reccomendation
Queue capactity of 100 songs: Still had memory left over and latency was fine
User stress test: I made a javaScript test to make 200 users (without songs) and it had memory over and latency was fine
Concurrent user stress test: This one was an issue. This is combining a lot of users, song queuing and concurrency. I ran out of memory fairly quickly which was a shock (a little over 20 users). I am still trying to understand exactly what is the big deal with the memory, I think its between the dataStructures kept locally and passing the whole queue into the socket to send to every single user. I plan on now storing the data in a database and retesting.Sunday edit: Concurrent user stress test works.
- I did not anticipate this memory issue (for the Concurrent user stress test) and thought I would be done with this part of the project by now so I am behind schedule. I plan to get back on schedule by finishing the remaining parts of the project as soon as possible.
- Next week I plan on fixing this memory issue as well as any other issue that pops up in our system, do all of the final reports, and then have a great demo and be done with the semester [and cmu 🙂 ].
Carnegie Mellon ECE Capstone, Spring 2024 by Luke Marolda, Thomas Lee and Matt Hegi