CPSC 483 – Computer System Design

Coff-e-mail Biweekly Report 4

April 26, 2004

Don McGeeEric Peden

Payton QuackenbushZack Roman

Page 2 of 7

Software - PerformanceAs in previous weeks, the functionality of the system is sufficiently far along that we can affordto tweak and optimize slower pieces of code. Over the past fortnight, primary optimizationsmade were

• the finished implementation of inline dynamic page generation• spawning of threads for various tasks• implementation of a custom default servlet, whose operation will be described below

Inline Dynamic Page Generation

As described in previous status reports, we discovered a significant improvement inperformance when our dynamic pages are generated “inline” rather than through tedioussearch-and-replace of a template file. This work was completed about a week and a half ago, andthe results have been good. Response time is consistent with the preliminary benchmarks,reported in our previous report, and the system feels faster—a subjective observation, butarguably the most important criteria in an end-user’s evaluation of the system.

Thread Spawning

An early concern with the Coff-E-Mail system was how well it would handle high-loadconditions. Our near-optimal raw image data transmission takes approximately 1.5 seconds,compression takes upwards of 10 additional seconds, and the Tynamo web server consumes agood bit of processor time to serve its pages (see Custom Default Servlet below). During testing,it quickly became apparent that this competition for the SNAP’s limited computationalresources was going to need some sort of mediation.

Our camera’s most valuable feature has proved to be something of a double-edged sword: it’soutput is controlled by an external clock. This makes it easy for us to read data from it at a speedthat is convenient for us, but because the camera lacks a framebuffer, if the data is not readquickly enough over-exposure occurs in the resulting image. Thanks to our new image transferprotocol (each row of pixels must be acknowledged by the SNAP before the PIC sends the nextrow; this as opposed to the all-at-once transfer we were using previously) image transfer can stilltake place between the SNAP and PIC, even when the SNAP is under high load. Unfortunately, itcan progress so slowly that the image transferred is almost pure white thanks to the over-exposure just described.

Our solution was to split off our event dispatch loop, which calls the image acquisition andcompression routines, into a thread of its own. When the event dispatcher receives the IMAGEevent, it elevates the priority of its thread to just above that of the web server, its primarycompetition for processor time. This seems to work beautifully: prior to this optimization, werecorded times for image captures—done while the web server was serving pages—in excess of10 seconds. After the thread priority elevation was implemented, this time dropped to no morethan 2 seconds. This results in a crisp, clear image.

However, we had introduced another problem: web server response time was now unacceptablyslow, since the 10 second image compression was now hogging the CPU. This was an easy fix:after image acquisition but prior to compression, the event dispatcher lowers its priority tonormal. Images take longer to appear on the web page, but web pages can once again load inreasonable time.

Page 3 of 7

Custom Default Servlet

Tynamo, like all Java servlet containers, relies on a set of mappings to associate specific servletclasses with appropriate URLs. Requested URLs which do not match any of these mappings arehanded off to what is called the default servlet. The default provided with Tynamo is capable ofserving static files from the SNAP’s Flash-based filesystem, and we used it to serve images andour lone static stylesheet. Unfortunately, there appear to be a couple of major bugs in Tynamo’sdefault servlet:

• Browser caching is not supported, i.e., browsers download each image/stylesheet everytime a page is loaded, even if they’ve downloaded those images/stylesheets before,resulting in higher load on the server

• Read()s of files in Flash don’t end, they time-out, and the browser will not display certainfiles until this time-out has occurred. This is really a bizarre problem, and the interestedreader is encouraged to inquire for more specific information regarding it, but the netresult is that each image and static stylesheet on a page increased its load time by 5-10seconds. Even for our minimalist main page this translated into load times approaching 1minute, clearly unacceptable.

These two bugs together made the response time for our website completely unbearable.Tynamo is closed-source, so we couldn’t fix the bugs ourselves, so in true hacker fashion we builtour own software to work around them. Our default servlet not only supports browsercaching—if the browser has downloaded a file once, it does not need to download it again unlessit has changed—but also provides in-memory caching. Flash read/writes are fairly costly, so ourservlet stores the contents of each file in memory the first time it is read. Subsequent requestsfor a file, assuming that file hasn’t changed since being cached, are serviced out of memory. Thisis a similar technique to the one we used to speed up dynamic page generation times. The resultsare fairly dramatic: file requests that once took 10 seconds now take less than 1 second, andpages are usable. There is still a slight delay before files are transmitted; we believe this is due toeither connection setup overhead in the SNAP’s TCP stack or servlet overhead in Tynamo, orsome combination of the two. Unfortunately, these are difficult to isolate and even more difficultto fix. We feel that the system is responsive enough for day-to-day use even with these slightdelays, but only user feedback will tell us for sure.

PIC ProtoboardWe moved our prototype PIC circuit from the solderless breadboard onto a 4” x 3” protoboard,and soldered all the components down. This includes:

• PIC microcontroller• Serial/TTL converter• Crystal oscillator• 5V voltage regulator• DB9 serial connector• Headers for the GBCam, LCD, and sensors• General purpose pushbutton

The schematic for our sensor microcontroller is shown in Figure 1.

Page 4 of 7

Figure 1 – PIC Schematic

Sensors/MountingMuch progress has been made for mounting the sensors. We have the mounting done for thephototransistor pairs. We used plastic pipe hangers and put two holes in each for sticking theleads of the LED’s through. Then we added a touch of solder to the LED leads to hold them inplace. A picture of the parts we have made are included in Figure 2.

Page 5 of 7

Figure 2 - Sensor Mounting

Enclosure

Over the past few weeks we have been working on an enclosure that will hold both our PIC andSNAP microcontrollers. The goal is to make the final product for the project as self contained aspossible. Basically everything will be contained inside one project box except for the sensorsand the camera. The sensors will all be mounted to the coffee machine and we are still workingon some ideas for mounting the camera. The project box will need connections for ethernet,power, and the sensors/camera. There will only be one power supply for the box that bothmicrocontrollers will share.

A plastic project box was found at Radio Shack (part number 270-1809) that would house bothmicrocontrollers as well as the LCD for the project. The SNAP microcontroller had to be

Page 6 of 7

carefully positioned within the project box so that the ethernet port on the TILT board wouldexit the project box at a good location. The PIC microcontroller was then mounted in theremaining room in the box. The LCD was mounted in the front of the box so that it will be easilyviewable for sending text messages to users of the coff-e-mail system.

In order to complete the enclosure all that remains is to come up with a good way for mountingthe camera and adding connections for the camera/sensors to the project box. Our currentideas for mounting the camera are:

1. Mount the camera directly to main project box – The main problem with mounting thecamera directly to the project box is that the box would have to be positioned so that thecamera pointed in the right direction. This may make it to where the LCD in the projectbox is not pointed in a desired direction.

2. Mount the camera to a piece of flexible tubing – This would work well because theposition of the camera could be changed to any desired position. The problem withallowing the position of the camera to be easily changed is that we want the camera toonly take pictures of the peoples coffee mugs, and if the camera moves around too easilyit is going to be hard to keep it pointed at the proper position.

3. Mount the camera on a stand – Mounting the camera to its own stand would work wellbecause it could be moved around but it would be harder to knock the camera off of itsdesired position. The drawback to this approach is that it is going to require more workto find a stand and figure out the routing of the wires.

So we have a few ideas for mounting the camera, we just need to decide what route to take sothat we can get it mounted and finish the wiring connections.

Current pictures of our enclosure are in Figure 3.

Page 7 of 7

Figure 3 - Project Box