The Plan for Benchmarking

Now that I have the benchmarking script written up (using Benchmark.js), I'll be running a series of benchmarks on three of the services the Tactonic Server provides:

• Getting the whole grid in JSON format
• Getting entire group pointsets in JSON format
• Getting group hull pointsets in JSON format

After some deliberation, Dr. Remy and I agreed that these would be ideal to test because they contain no interpretation of the data on the sensor (aside from the definition of adjacency), meaning they return raw point data and let the client do what they like with it. The plan is to run a series of benchmarks on each of these functions consisting of 20 samples each over localhost and over the Clemson University network using the CS linux machines.

Where the Tactonic Project Went

The recent posts have been about Heroku, so it's time for an update on the in-progress project involving the Tactonic sensors. The last thing that I posted on regarding this was the concave hull search and optimizing the whole process. The past three weeks have been (in addition to Heroku work) been spent continuing to optimize the Tactonic server and setting up benchmarks for the client end of this process.
The server has been updated to include mutual exclusion around accesses to the shared force grid, JSON output, and a re-vamped group-grabbing operation that eliminates some redundant/repeated calculations. When last I posted about this system, there was a data freeze that affected the system after running it for a period of time. After these upgrades, I am fairly confident that the freeze is on the hardware end, especially since the copy of the force grid that the server works with does not persist between client requests. Logs show that the group grabbing process still occurs after the freeze, and the force grid continues to be copied to a fresh array for processing after the freeze. This tells me that the device driver stops reading in new values at some point, or else the device stops registering new values. Whatever the case, I can get about 15 minutes of uptime (it varies widely, but on average about 15 minutes) before having to restart the server.
I switched to JSON output from plain text because JavaScript has built in facilities to read JSON, and it allows the server to send named fields to the client. This should hopefully reduce some of the overhead in creating new variables to hold parsed plain text, and in having to do the actual text parsing and transformations. The benchmarks will yield the results of these changes, and as soon as I've analyzed the results they will be posted here. I may also implement the client using Node.js and benchmark on that platform, time permitting.

Server Performance Improvements

Today I did a little experiment by changing every function on the server that takes an object, array, or struct as an argument so that they only accept pointers to those parameters. After going through and making the necessary changes to the objects in question, I found that the running time of THEA before the sensor grid freezes when running the same test as in the previous post is ~8 minutes (compared to the 2.5 minutes when passing static objects). I'll run an officially timed comparison soon and post the results.

In addition, I have an old version by which we can run comparisons to show the drastic difference this change makes. For now, though, I'm enjoying the extended run time (>15 minutes when only receiving pressure centers).