Category: Pseudo Random

Chasing the MHz

Is it just me or is the smart-phone market actually going down the similar path as the PC market did a decade ago – chasing more cores and more Mega-Hertz speeds. Even while the smart-phone market is dominated by ARM-only platforms, it is still folly to be making hand-sets that are faster and furiouser than the rest.

I would think that these companies would have realised that it is far more important to improve the experience and functionality of the smart-phone than to increase the speed of the phone. Increasing the speed of a phone is easy – just wait a few months and Moore’s Law will ensure that it happens eventually. There is no magic in that.

I would think that the smart-phone is a booming market, that has still got so many pain-points. Although I must confess that I do not own a smart-phone, I am fairly familiar with their architectures and have a good idea of how to actually build one. The reason that I do not own one is because I do not see any useful phones out in the market.

If you were to just sit down and observe a smart-phone user, you will find that there are lots of problems with using the phone. For one, it’s terribly small and it requires a person to stare at the screen to use it. While I think that the touch interface is a pretty cool invention, I do not understand why it is that for a device that comes with a microphone and a speaker, I need to use my fingers and eyes to interact with it. To me, this is just silly.

If I was one of those smart-phone hand-set makers, I would put some good money into developing a new user experience that does not take my eyes off the road and fingers off the wheel. The first should be easy enough to accomplish. With gobs of memory and processing power, the phone should be able to speak to me instead of presenting a visual response. You don’t need to build some fancy text-to-speech engine to do this – just store MP3 samples of audio output.

As for getting user input, again, the system does not need to have some super speech-recognition engine built in. Just being able to discern a “yes” from a “no” can already build us a tremendously complex menu system. Then, put the money into the smarts of predicting what it is that the user wants to do based on context. If the user is driving, the user may be interested in accessing the GPS and *not* the camera application.

With that, we can probably come up with a better smart-phone – one that actually has some ‘smarts’ and is not dependent on my smarts.

Region and Country

I recently realised that there are a lot of corporate websites out there that will ask a user for region/country when visiting, and then forward the user to a different landing page depending on the geographical location of the user. With the technology available today, I sometimes wonder why any of this is necessary at all.

There is such a thing called GeoIP. While it is not 100% accurate, it is largely accurate and is used by certain people like Google analytics to work out where a site’s visitor comes from. It occurred to me that these websites should just use GeoIP to redirect the user to the appropriate landing page instead of asking the user a bunch of useless questions.

This is just a random thought.

Mulling over DDoS

The Wikileaks fracas is escalating, with hacktivists on both sides of the divide working to take down sites that are seen to be on the wrong side of the issue. Personally, I do not have any political opinion on either the Wikileaks issue or the attacks. I leave that to less technical authors to write on. Personally, I just like mulling over the whole problem of DDoS attacks.

Any reader of this blog should be familiar with what a DDoS attack is. But to me, the problem of a DDoS attack is similar to that of an arms race – the side with the bigger gun or bullet wins. In the case of the initial attack, Wikileaks moved over to AWS and was able to hold off attacks for a while. This is because Amazon had bigger pipes and defenses than the attackers. However, the attacks have taken a turn and secondary sites such as credit cards and law-firms are being hit as well. It seems like certain parties are taking this opportunity to settle some beef.

But back to the whole problem with DDoS.

I’ve mulled over this with my former boss and some co-workers, for the purpose of a clandestine project that I was working on. The conclusion that I came to is that a DDoS is effective in its simplicity – the side with the bigger pipes win. The company that I used to work for, has one of the biggest pipes in Malaysia and we could take people down, single-handedly, if we wanted to.

However, there are strategies to mitigate a DDoS attack.

Bigger pipes
Wikileaks moving to Amazon was in effect, buying bigger pipes. This mitigated attacks for a while until they got booted off Amazon. If it is not possible to buy pipes from a single provider, it would make sense to buy pipes from multiple providers and distributing the site across the globe. This is what Wikileaks has now done – distribute its content over a list of hundreds of worldwide mirrors operated by volunteers.

Faster software
DDoS attacks exploit the fact that a computer is kept busy by servicing network packets (either at the application or networking layers). Obviously, the solution to this problem would be to have bigger machines – this means having faster processors, larger memories, lighter operating systems. Surprisingly, some people do not realise that the TCP/IP stack plays an integral role in these attacks and if the OS has a more efficient stack, it would be able to withstand more punishment. Not all web-servers are created equal and some are able to handle concurrency better.

IPv6
One method that is not often thought of, is moving infrastructure over to IPv6. Most of the internet still runs on IPv4 today. In fact, many network providers simply do not cater to IPv6 and simply drop the packets from their network. Therefore, moving a site over to IPv6-only could help mitigate DDoS attacks by limiting the available sources of attack. Compromised botnets would be less effective if most of their machines were still on IPv4 only.

Future clouds
What would have been interesting would be if the attackers had shifted to launching attacks from cloud service providers. In fact, this was one of the queries that I raised once, in a meeting with a local cloud provider – launching attacks from within the cloud provider itself. If the provider is not careful, attackers could buy network and computing resources in order to launch attacks within the cloud itself. This would be difficult to detect because most cloud providers put their metering on external traffic, not internal ones. Imagine the attackers buying EC2s to attack Wikileaks from the inside of Amazon infrastructure. The attack would only need to be bad enough to take down the Wikileaks machines, without compromising the rest of Amazon’s infrastructure. Therefore, it is important for cloud providers to think about isolating their internal machines from each other.

Of course, there are many more considerations that could fit this little blog, but these were just some thoughts that I felt like writing down.

Server Upgrade

Not sure if anyone has noticed this – might or might not be a good thing – but I have upgraded the server hosting this blog. Externally, nothing much has changed but underneath, things have changed quite a bit. The reason for the upgrade was due to the last server, constantly choking under any slight increase in load. The new server is cheaper too.

The specs for the new server are not all impressive, but it is good enough for hosting a simple blog. There is 128MB of RAM and 256MB of swap. It runs 32-bit Debian Lenny as the OS and has MySQL with Lighttpd and PHP5. It runs smoothly with two threads of PHP managing all the connections. I have stress tested it with siege and it gracefully handles about 10 concurrent connections with a response time of under 3 seconds.

Maybe this is a good time for me to describe my methodology for tuning a web server.

Firstly, I run siege -g example.com to see if the site is working correctly. This is useful for debugging the entire web stack because it will also display the HTTP headers sent and received.

Next, I simulate a random series of connections by using siege -i -c 5 example.com to simulate a number of concurrent connections. While I am doing this, I am also running htop on the server to monitor the server load and resource consumption.

Finally, I hammer the server with increasing number of concurrent connections using siege -b -c 10 example.com while continuously monitoring the server load and the response times. I tweak the numbers until performance drops.

That gives me some statistics that I can use as a benchmark. Then, I tweak the server settings and repeat the siege to get new numbers. Rinse and repeat until the desired concurrency and response times are achieved.


Lifting the server siege... done.
Transactions: 502 hits
Availability: 100.00 %
Elapsed time: 151.08 secs
Data transferred: 6.40 MB
Response time: 1.50 secs
Transaction rate: 3.32 trans/sec
Throughput: 0.04 MB/sec
Concurrency: 4.97
Successful transactions: 502
Failed transactions: 0
Longest transaction: 6.09
Shortest transaction: 0.76