Richard’s Status Report for 4-26

Richard’s Status Report for 4-26

This week, we did our demo to the professor and ta. This went pretty well, and while we were happy that it wasn’t a disaster, we were also aware of what we had left to do. We made a list of the things we still had to complete and got to work.

Since we weren’t planning on changing the webapp from what we showcased in the demo, I didn’t work on it. Instead, I helped Niko on timing the interaction layer stuff, so that we could have solid numbers for the presentation, and so we could back up our answers to the questions our peers and fellow students will probably have.

We discussed how to do this for an hour or two and decided that perhaps the best way would be to ensure the clocks on the nodes were synced, and log everything that happened. I’ll use timing an interaction as an example. We logged the start of the interaction, which is a value on a sensor changing. We also logged the end of the interaction, which is a value on a target device changing. Subtracting the log times of these events gives us a latency figure, which we intend to present tomorrow.

There are some caveats to this method: this latency is much lower on the virtualized aws network than it would be on a home wifi network. The network on aws is state of the art, probably 10 gb/s, while really good wifi networks can reach almost 1 gb/s. AWS machines themselves are also pretty fast, while the devices our system would have run on, raspberry pi’s, are significantly slower.

We feel that even though AWS technology is much better and faster than a home wifi network would be, by our estimates our technology would still fall well under the goal threshold we set at our design presentation.

Leave a Reply

Your email address will not be published. Required fields are marked *