CPSC 483 Computer System Design. Coff- Biweekly Report 4. April 26, 2004

Transcription

1 CPSC 483 Computer System Design Coff- Biweekly Report 4 April 26, 2004 Don McGee Eric Peden Payton Quackenbush Zack Roman

2 Software - Performance As in previous weeks, the functionality of the system is sufficiently far along that we can afford to tweak and optimize slower pieces of code. Over the past fortnight, primary optimizations made 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 in performance when our dynamic pages are generated inline rather than through tedious search-and-replace of a template file. This work was completed about a week and a half ago, and the 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, but arguably the most important criteria in an end-user s evaluation of the system. Thread Spawning An early concern with the Coff- system was how well it would handle high-load conditions. 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 a good 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 computational resources 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 s output is controlled by an external clock. This makes it easy for us to read data from it at a speed that is convenient for us, but because the camera lacks a framebuffer, if the data is not read quickly enough over-exposure occurs in the resulting image. Thanks to our new image transfer protocol (each row of pixels must be acknowledged by the SNAP before the PIC sends the next row; this as opposed to the all-at-once transfer we were using previously) image transfer can still take place between the SNAP and PIC, even when the SNAP is under high load. Unfortunately, it can progress so slowly that the image transferred is almost pure white thanks to the overexposure just described. Our solution was to split off our event dispatch loop, which calls the image acquisition and compression routines, into a thread of its own. When the event dispatcher receives the IMAGE event, it elevates the priority of its thread to just above that of the web server, its primary competition for processor time. This seems to work beautifully: prior to this optimization, we recorded times for image captures done while the web server was serving pages in excess of 10 seconds. After the thread priority elevation was implemented, this time dropped to no more than 2 seconds. This results in a crisp, clear image. However, we had introduced another problem: web server response time was now unacceptably slow, 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 to normal. Images take longer to appear on the web page, but web pages can once again load in reasonable time. Page 2 of 7

3 Custom Default Servlet Tynamo, like all Java servlet containers, relies on a set of mappings to associate specific servlet classes with appropriate URLs. Requested URLs which do not match any of these mappings are handed off to what is called the default servlet. The default provided with Tynamo is capable of serving static files from the SNAP s Flash-based filesystem, and we used it to serve images and our lone static stylesheet. Unfortunately, there appear to be a couple of major bugs in Tynamo s default servlet: Browser caching is not supported, i.e., browsers download each image/stylesheet every time 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 certain files until this time-out has occurred. This is really a bizarre problem, and the interested reader is encouraged to inquire for more specific information regarding it, but the net result is that each image and static stylesheet on a page increased its load time by 5-10 seconds. Even for our minimalist main page this translated into load times approaching 1 minute, 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 built our own software to work around them. Our default servlet not only supports browser caching if the browser has downloaded a file once, it does not need to download it again unless it has changed but also provides in-memory caching. Flash read/writes are fairly costly, so our servlet stores the contents of each file in memory the first time it is read. Subsequent requests for a file, assuming that file hasn t changed since being cached, are serviced out of memory. This is a similar technique to the one we used to speed up dynamic page generation times. The results are fairly dramatic: file requests that once took 10 seconds now take less than 1 second, and pages are usable. There is still a slight delay before files are transmitted; we believe this is due to either connection setup overhead in the SNAP s TCP stack or servlet overhead in Tynamo, or some combination of the two. Unfortunately, these are difficult to isolate and even more difficult to fix. We feel that the system is responsive enough for day-to-day use even with these slight delays, but only user feedback will tell us for sure. PIC Protoboard We 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 3 of 7

4 Sensors/Mounting Figure 1 PIC Schematic Much progress has been made for mounting the sensors. We have the mounting done for the phototransistor pairs. We used plastic pipe hangers and put two holes in each for sticking the leads of the LED s through. Then we added a touch of solder to the LED leads to hold them in place. A picture of the parts we have made are included in Figure 2. Page 4 of 7

5 Figure 2 - Sensor Mounting Enclosure Over the past few weeks we have been working on an enclosure that will hold both our PIC and SNAP microcontrollers. The goal is to make the final product for the project as self contained as possible. Basically everything will be contained inside one project box except for the sensors and the camera. The sensors will all be mounted to the coffee machine and we are still working on 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 both microcontrollers will share. A plastic project box was found at Radio Shack (part number ) that would house both microcontrollers as well as the LCD for the project. The SNAP microcontroller had to be Page 5 of 7

6 carefully positioned within the project box so that the ethernet port on the TILT board would exit the project box at a good location. The PIC microcontroller was then mounted in the remaining room in the box. The LCD was mounted in the front of the box so that it will be easily viewable for sending text messages to users of the coff- system. In order to complete the enclosure all that remains is to come up with a good way for mounting the camera and adding connections for the camera/sensors to the project box. Our current ideas for mounting the camera are: 1. Mount the camera directly to main project box The main problem with mounting the camera directly to the project box is that the box would have to be positioned so that the camera pointed in the right direction. This may make it to where the LCD in the project box is not pointed in a desired direction. 2. Mount the camera to a piece of flexible tubing This would work well because the position of the camera could be changed to any desired position. The problem with allowing the position of the camera to be easily changed is that we want the camera to only take pictures of the peoples coffee mugs, and if the camera moves around too easily it 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 well because it could be moved around but it would be harder to knock the camera off of its desired position. The drawback to this approach is that it is going to require more work to 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 so that we can get it mounted and finish the wiring connections. Current pictures of our enclosure are in Figure 3. Page 6 of 7

7 Figure 3 - Project Box Page 7 of 7