Java benchmarking

Raspberry-Pi is compact and has aside of that other benefits which makes it a really cool tool to play around with. Unfortunately the processing power is limited compared to current day computers and so I hit the performance limit pretty early. But it seems now that Oracle has released a pre-release test version of Java 8 which comes with ARM performance tweaks. And so I was very curious to check out the differences between all Java versions I’ve been using past few months. I used Hwbot Prime to test the difference in computational power between OpenJDK6, OpenJDK7 and Oracle’s JDK8 (pre-release). Here are the results:

java benchmarking

As you can see from the above chart, there is nearly no difference in using OpenJDK 6 or 7, but because of the ARM tweaks found in JDK 8 from Oracle we see a huge performance boost there, roughly 2,5 times higher performance. Off course these results should be taken with a grain of salt. This is a pure computational test, this will not say anything about process threading, MySQL performance or IO performance.. But it’s a nice indication that things are getting better.

Finishing the project

Last few week I had to spend quit a bit more time on the project as I wanted to make sure the basic functionality was there. I changed some parts of the code, did some performance testing, tuned the code a little bit and yesterday I put it into a state I think is good enough to show. Here is more or less an overview of  the software architecture:

software architecture

It’s more or less the same as the drawing you saw before. One of the differences is that the console application is now an application on its own plus the server IO back-end is more or less programmed as a service which automatically loads at boot. This way security rules can be applied, although they have not be implemented at this stage. The console app talks to the back-end server through TCP/IP and uses the same classes and methods as the front-end website when interacting with the XBee network. Regarding the front-end webserver, in the end I remained using the Jetty webserver. Altough it is still not performing very well, it does with it is supposed to do and I can’t find a solution which can be used as easily as the current one. Loading web pages still takes some time, but since this is more a research project than a product design I think concluding that “the functionality is doing what we hoped for” is good enough. Below you’ll find a screenshot of the analog values page which got a small interface update since my last screenshot of it. Notice the labels that get displayed when hovering one of the samples.

webapp3

New in the front-end website is this “Command line” page which does exactly what you think it will do: allow the user to send commands to the XBee network. The back-end server has been upgraded to maintain a list of connected devices (with a timeout value of 1 hour) and so we can query the connected devices at all time. A dropdown box is filled with all connected devices and list of all available AT commands is also displayed as a dropdown box. The parameter box can be filled in optionally. In the picture below you see a demonstration of using the front-end ‘command line’. In the previous form submit we selected a node, selected the D1 command and filled in no parameters. After hitting the submit button the D1 command is send to the node which will then reply with its configuration value of the D1 register. Next the page loads as the one seen in the picture below and displays the value of the D1 register. As you see the value is 5 which means the D1 register is configured as digital high output. Next I filled in 4 in the parameter field, the dropdown boxes automatically select the same command from before when the pages loads and so when I would now push the submit button the D1 command with parameter 4 would be send to the remote XBee node which will then be configured as digital low output. To make a long story short, the led that was connected to the remote XBee on pin D1 was once lighted on but has now been turned of through our front-end website.

webapp5

At this moments I’m finalizing my report which should be finished on friday, with next week my final presentation about what I’ve been doing past few months. Wish me luck because if all goes well I can call myself Professional Bachelor in ICT from then on!!

Admin site revisited

For now I’ve added a basic user interaction console method which allows to send commands  and receive responses from the XBee network. I would like to add more functionality but it is kind of hard to include specific handlers for every XBee AT command because there are really a lot. I’ll have to team up with other people involved in this project to discuss what functionality we want to support and which ones we would like to ignore and handle with the Digi software. Furthermore I also experimented a bit more with other Java Servlet webservers… As said, Glassfish really takes a lot of time to startup, same counts for Tomcat. If stumbled upon 2 more webserver applications (Jetty & Winstone) which should be a less of a burden to run. Winstone seems to be the lightest one of the two but I failed to get it running. Furthermore, this Winstone project doesn’t seem to be updated any longer, but I managed to get the Jetty webserver up and running on the Raspberry-pi and I also managed to deploy my first JSP website on the remote (Raspberry-pi) webserver. After launching the necessary processes I got the following response in my webbrowser:

Screenshot from 2013-05-14 14:41:43

For development purposes however I’ll continue to use the Glassfish webserver on my desktop computer as this one can easily be integrated into Netbeans while Jetty is currently not supported. I’ll also add a Netbeans build command which automatically copies the compiled .war website to the Jetty webserver so that I only need to “git push-pull” my code after compilation if I wanted to test it on the Raspberry-pi.

So, another goal completed, what’s left:
– make the xbee server aware of it’s connected devices
– add a command line page to the admin site
– add GUI configuration possibilities through the admin side
– add more database filtering options

This week however I’ll be writing more text for the thesis than writing program code, and next weekend I’m visiting the south coast of Portugal in between Faro and Sagres. Até à proxima!

Migrating to the Raspberry-Pi, part 2

Like I said, I was getting closer to my end-goal. What I have so far is a Java application which launches two service threads: one which handles TCP/IP requests and one which handles the IO. There is also a database connected to this server application and in case IO samples are received they will be saved in this database. I also made a JSP website which is capable of displaying the database data and should soon also be capable of sending TCP/IP requests to the TCP/IP service.

HOWEVER! It seems that the glassfish webserver is quite a burden to run on the Raspberry-Pi, the pages are showing but launching the service takes roughly 5 minutes. I have to find some lightweight service which offers the same functionality. But, this is something I’ll do later: as my deadline is coming nearer and nearer I’ll have to wrap up my work and put it into a test environment where I simulate a real life scenario. My next goal will be to make the service flexible in a way that once the application is running the user can dynamically adjust the configuration and stuff like this. I’ll have to program a console function which will allow the user to set up the XBee network and later on I can add the a more user friendly interface by using the JSP website as frontend.

Anyway, this week we have the Queima Das Fitas, a week full of ‘festivalitis’, and later on I have 3 more weeks to finish so I’m not sure if I’ll get all of  this working before the deadline (because in the meantime I also need to write up the thesis).

Queima!

http://www.queimadoporto.com/

Migrating to the Raspberry-Pi

As expected, migrating from a x86-64 Windows environment to the ARM Raspbian environment isn’t going as easily as copy-paste the code…
… no, there were:
– java code conversions
– git versioning problems
– database access problems
– Serial bus (UART) detection problems
– software deployment problems
– and off course local network problems (because I didn’t had these yet…)

But, we’re getting closer!

2013-04-30-134240

Raspberry-Pi running an IO-service which saves data from remote sensors in a local database

system architecture

Below I’ve added a quick drawing which shows you more or less the current status of the project. At this moment I’m still running on Windows but I received the Raspberry-Pi last week so we can soon start with porting all the code to the Raspbian operating system. That I can hopefully start with next week, so far the administrative website can display IO data that has been stored in the MySQL database but my next goal is to let the individual services talk to each other so that the admin can send XBee commands from the admin website. That will be the goal for this week.
server_application_schets