June 2011 Archives

Over 10 years ago I did jury duty in Australia. While researching the legalities of writing about my experience, 90% of the pages returned from a Google search were about how to avoid jury duty. I can understand the sentiment. Dodging it was my first thought upon receiving the letter announcing my random selection. However, work was slow and my employer was ok with me being away for a week, so I decided not to fight the summons.

I turned up at the District Court in the Perth CBD on the allotted day. The couple of hundred jury candidates for that week were corralled together and given a talk on our responsibilities and how the system worked (just the standard stuff like there are 12 jurors on a case and not to talk to anyone about your case). We were then told to wait until our name was called and we left in groups of around 30 or so. There was not much talking or socialising - it didn't seem that most people were happy to be there. I was called into the third group to depart. We went into a courtroom and told the case was an assault and who the main participants would be (so we could excuse ourselves if we knew any of them). Then potential jurors were called to the stand, but about half were rejected by the lawyers before they got there. No questions or reasons were given for the rejections. The lawyers didn't event look at the jurors, they were head down in paper - presumably our details. My name wasn't called by the time twelve jurors were chosen, so I and the remainder were led out of the court and back to the waiting room. I was called into another group after a short wait, this was for a sexual assault where most of the people involved had the same surname. I was called but rejected and quite happy about it. After another short wait I was called to a drug case, selected and not rejected. I was a juror.

It was supposed to be a 3 day case, but we started late on the first day and finished early on the last day. Also, we (the jury) spent probably a third of the time out of the court as the lawyers argued points of law. The basics of the case were that the police were looking for a lost cat. While searching they looked through the window of a house and saw what looked like hydroponic equipment - it was also the house the cat was in. They called in a special squad, entered the house (let the cat out) and found the remains of a large marijuana cultivation operation. While no actual cannabis was present, there were the remains of hundreds of plants. All this was recorded on film, including the arrival of the defendant who asked what was happening at his house. The defendant gave a tour of the house on tape and talked (somewhat reticently, but without being overly pressured) about how he grew drugs there, albeit with little detail beyond describing what we could see.

The procecution case rested heavily on his video confession. They then showed proof that the defendant actually owned the house, followed by evidence that it was a drug factory producing commercial quantities of cannabis. Finally, they said that even though no drugs were found, the law allowed that all the used equipment was good enough for conviction on the current drug cultivation charges. The defendant claimed personal use for a wasting illness, though there was no mention of why he needed so much. Then we had to decide. There was no overacting or histrionics like in TV or the movies. Most of the time neither lawyer looked at us - then were looking down at the notes the entire time, even when questioning witnesses. Both lawyers were just doing their job. The only time the process seemed to deviate from the banal, judging from the lawyers slightly increased excitement level, is when they would ask for us to be removed from the room. Or, maybe that was just me being intrigued by what I was missing.

I don't remember the details about any of my fellow jurors. They were a bunch of average people, no one really stood out as unreasonable. When we got in the room we first did an anonymous vote - about eight or nine of us (including me) voted guilty. After the vote we talked and it seemed no one was particularly keen to convict, but some people looked harder than others for a reason not to. At first the question was whether growing marijuana should be a crime at all. The scale of the operation won that argument fairly quickly. No one believed the personal use story. However, if there was only a couple of plants I think he would have been found innocent as the majority of us backed this view. Next there was the argument he was a patsy. Conspiracy theories abounded. I had some sympathy with these - the case wasn't quite right and the constant requests for us to leave the room had made us all feel we were missing something. The defendant did not come across as a smart or rich man, yet had a second house full of drugs. There must have been other people involved. Also where did all the drugs go? The operation was supposedly shutdown a few days or few weeks before the police found it. Some people even thought the cat story was a bit fishy and the police were in on the whole thing.

In the end the video won all arguments. The tape had no edits as far as we could tell, and showed the defendant from the time he first encountered the police. After some identification, warnings about getting a lawyer then without any more coercion than a few strongly put questions, he completely confessed. We watched it a couple of times, then the holdouts agreed to convict. There may have been a group of people involved, but the defendant was definitely one of them. The decision took a couple of hours. When we presented our verdict to the court the judge thanked us and said that the result was completely in keeping with the evidence presented to us. So what was the evidence not presented to us? We were led out of the court building immediately and didn't see the sentencing.

I never saw or spoke to any of the other jury members again. I checked the papers for a few days afterwards to see what happened, but couldn't find anything that seemed like my case. My main memory of the experience was boredom. We spent most of the three days waiting. The case itself was interesting, but the lawyers belaboured their points. I assume they wanted to be certain we understood what they were saying. The whole thing could have been done in a couple of hours if succinctness was prioritised. Still, if that was a stereotypical jury experience I wouldn't have an issue doing it again.

The moral of the story is: never admit guilt on camera!

Available on iTunes and OU Podcasts

Moving away from the Open University's Myth series, these podcasts look at how Rome (together with its port colony Ostia) was built and functioned. There are 14 videos in the series and one introductory audio podcast. The podcast files are prefixed with non-contiguous numbers, so I think that the released episodes are only part of a larger series. The videos are in documentary format with shots of a large model of Rome for context interspersed with contemporary scenes of the sites and talking heads. The podcasts range from under 2 minutes (12MB) to over 11 minutes (128MB) all recorded at 640×480 resolution, or a smaller iPod optimised format. Transcripts are available in PDF format.

The videos can be split in three rough categories. There are episodes on Rome: how it was constructed, aqueducts; the Aurelanic wall; how the population was fed; the water system; and some industry, mainly fulleries. Then there are some podcasts on Ostia, its warehouses, insulae and baths. The last videos focus on a couple of Rome's monumental buildings, namely the Pantheon and the Baths of Caracalla.

At its peak, Rome had a population of around a million people - the largest western city in history until London and Paris in the 18th century. The Romans were not known for their invention, but they were good developers of existing technology and very organised. To maintain the large population aqueducts were used to bring in water, while sewers took the waste out (although urine was used in the fulleries. Grain and other goods were transported up the Tiber on barges from Ostia after arriving there from around the Mediterranean. Only the rich could afford horses and carts were banned in Rome during daylight. Thus the size of the city was dictated by walking distance. To fit the large population the city had to built upwards. Many people lived in apartment blocks called Insulae (which means "island" in Latin). Upto six stories tall, the better apartments were at the bottom, as these were nearer the water supply, involved less stairs and were safer in the event of a fire.

The standard Roman building method used thin bricks combined with concrete. This technique allowed them to build strong buildings. The Baths of Caracalla is a massive building able to serve thousands of bathers at a time. It had a large dome over the caldarium (hot room), underfloor heating and furnaces and large windows (unusual in older buildings). The Pantheon at a diameter of 43 metres is still the worlds largest concrete dome. It is constructed using marble from all over the world - publicly demonstrating the Emperor's power. The portico's 12 metre tall columns are each from a single block of stone quarried in Egypt. Peculiarly, if the columns were 15 metres tall then the portico would better integrate with the rotunda. It is theorized that the columns were originally supposed to be taller, but that it was too difficult produce and transport such columns to Rome - thus necessitating the mismatch between portico and rotunda.

Many interesting details on the functioning of a Roman city - recommended.

Recently the Blender 2.5x series was properly released (as opposed to the beta versions that have been around for some time). There have been significant changes since the old 2.4x releases, so to learn the new interface I tried modelling something simple. Here I describe the steps to modelling a Roman lamp, with the final result below.

The continuation of this post is a set by step tutorial detailing my methodology.

After some previous work building Java NIO servers, there was still some question over the performance of the system created. Here are the results from a number of tests I ran, to see how such a server would handle connection and message storms.

The code from the previous blog article was modified so that there was a single-threaded selector to handle initial connections, but it handed off the message processing to a number of other selectors running in a thread pool. All of the tests were run on my 4-core Win7 64-bit desktop (full specs here). All programs (both client and server components) were run through Eclipse Helios using JDK1.6.0.24, always with 256MB of heap space and no other VM options set. The code is not (yet) available online, but it shouldn't be too hard to work out a rough understanding from the previous article and some Java NIO knowledge.

Firstly, I wanted to check the system could handle a storm of connections. The test code would fire off 10,000 connections either: 1 per millisecond; as fast as it could in 1 thread; or as far as it could with 5 threads sharing the load. The average time to reach various code points were recorded and results are in the table below. The Accept column is the time from when the connection is first received by the server to just after the server accepts the connection. The Server column is the time from when the connection is first received by the server until it completes all actions on the connection - this is the Accept column plus time spent initialising message processing. The Client column is the time from when the client opens a connection until it receives notification it is ready. Also during these tests I tracked heap usage and it barely budged - an extra few MB on a system that was already using 30MB after initialisation. All the heap gain was reversed after the next GC. No problems there.

As can be seen the Accept and Server times are fairly steady (I would guess 0.07 milliseconds is the fastest a selector can accept a connection on average). However, the faster the connections are created, the greater the lag at the client. No connections were dropped. I imagine the client delays are caused by some queuing. Possibly in the PC's networking, but more likely in the wait before the selector starts processing the connection. In all the above tests the selector wait time is 1 millisecond, so the server will not wait long for a connections. I tried setting the wait time to 0, but some connections were then dropped. I also increased the wait time, and unsurprisingly this only increased the response time.

Speeding up the server code after the accept (ie, trying to decrease the Server column) could speed up acceptance by decreasing the time before the server is ready to process the next connection. This code could be moved into another thread, but then I'm not sure what would happen if a message arrived on a connection that hadn't finished. I also looked at the cost of selector creation by having each connection create a selector just for itself. In this scenario the time taken increased, but more importantly the server crashed having run out of heap after 641 connections (the old generation filled up). I would estimate that each selector requires around 0.25 MB of heap.

Next to test the message processing. The client created 10,000 connections and once they were accepted each connection sent 10 message (for a total of 100,000 unique messages). The server just reflected the message back to the client. The client checked each message returned from the server was as expected (all messages were present and correct) and recorded total time taken. The variables in the tests were the number of selectors processing messages and the number of threads handling those selectors. The results are below. During all tests the heap didn't grow to more than 55MB (from a 30MB base).

The rule seems to be that the more selectors the better and there should be roughly the same number of threads as selectors (it may be easier to see in the raw numbers). More threads than selectors does no good at all. I checked a few points further out, 7 selectors/7 threads and 10/10. They were quicker on average, but showed decreasing returns as they were both 1.26 milliseconds on average. However, the standard deviation also grew to around 2ms, when for all the other tests it was around 1ms (perhaps due to the extra thread scheduling in the VM)

This such a system should handle connection and message storms short of a concerted DDOS attack. For performance the rule seems to be pre-build as many message handling selectors as you wish and then provide about one thread per selector to support them.