If you expected to see another site instead of this one, please don’t panic: it just means that your ISP’s DNS servers are being a bit slow with their cache updates.

You can also use “ipconfig /flushdns” in Windows to force flushing the local OS’s resolver cache.

While it’s a neat little client and does its job pretty well, there is something weird about versions 1.8.1 and above. That “something weird” is their new protocol, based on UDP and called uTP. As you can read in the description, it’s supposed to be playing nice and fair with our networking infrastructure.

Up until 2.0, uTP wasn’t actively enabled, instead, clients were by default set to only receive uTP handshake requests, not initiate them; thus the only case uTP was used is when a client had a 2.0 beta version with uTP enabled for outgoing connections and the receiving client had an UDP port forwarded from their router. Therefore, the amount of transfers which used uTP wasn’t huge.

However, 2.0 introduced a default of “uTP enabled for both outgoing and incoming connections”, which — as μTorrent automatically updated itself after the release — resulted in a steady growth of those UDP-based connections. While UDP in itself isn’t “bad” — and P2P networks like Winny, Share, or eDonkey2000 used the protocol for quite a few years — the approach to UDP transfers in μTP is a bit different.

Let’s have a brief look at the differences between TCP and UDP — from an ISP’s point of view as well; I’ll try to explain it as simple as I can.

TCP, the Transmission Control Protocol, was built to serve connections that are established and then used for data exchange. It has built-in error handling and transmission control, and includes some algorithms that help solve bad connection issues. Keywords: reliability. TCP is about making sure that the packet has been received correctly.

UDP, the User Datagram Protocol, is a connectionless protocol used to send short messages between hosts — messages that do not require acknowledgement or confirmation of delivery. It’s perfect for tasks where reliability is not required, for example, for VoIP — as the VoIP codecs are designed to be loss-proof, but they do require a stable transmission rate to relay voice and video properly. Keywords: transmission rate. UDP in these applications is about making sure that the packets are being sent at a steady rate; it doesn’t matter much if the application on the other end actually receives them or not, and whether they were damaged in the process.

In file sharing, UDP is used to make such transfers less “trackable”, and usually you would send a large packet of data that, including protocol overhead and UDP headers, would roughly reach the size of the MTU (maximum transmission unit). After sending a set of such packets, you wait for the confirmation from the other side to make sure the data was received correctly.

Let’s assume we’re a home user, and we connect to the Internet over a 5Mbps line. Our internet service provider has some hardware installed to ensure that we only use our 5Mbps bandwidth, and not more. That’s pretty much understandable. This process is called “traffic shaping”.

When the shaping router receives a data packet for us from the Internet, it has three possible choices.

• Accept the traffic and pass it through to the customer;
• If the customer’s bandwidth is already used entirely, put the packet into a queue;
• If the queue is already full, drop the packet.

The problem is that our router has no way to tell the remote side, “Hey, you’re sending too fast, please slow down!”, and the incoming packets keep on arriving all the time, even though our queue is already full.

Now, there are different queues (it’s called QoS, Quality of Service), and different protocols have different priorities. In most cases, you would pass TCP ACKnowledgement packets and DNS requests/replies through first, for example. However, everything else gets in the same queue, and here’s where the differences between protocols strike.

So, how does traffic shaping work with TCP?

TCP has a built-in mechanism that optimises its throughput. If put simply, it works like this:

1. Send X packets; where X equals “1″ on the first transfer attempt.
2. Wait for the confirmation of a successful transfer.
3. If the confirmation wasn’t received, reset X to “1″, else increase X by “1″.
4. Repeat.

The more packets we send in a single batch, the faster the transfer goes because we’re eliminating the delay between sending the data and receiving confirmation.

Now, let’s see what happens when we hit a shaping router with a transfer like this (while at it, I’ll also explain why “download accelerators” exist).

Our system will send a single packet, then two of them, and so on. But then we’ll hit the bandwidth/queue limit, and our next batch won’t get through — we get a “transmission error, packet lost” TCP service message from our destination. “Let’s restart the sequence,” we think, and re-send these packets as single, double, triple, etc batches. Thus we’re keeping a certain speed that fits our destination; we’re, of course, losing some packets — but it’s not much of a loss, usually less than 3-5% of the entire data volume.

As you see, TCP is shaping-proof, and its self-regulation allows us to traverse a traffic shaping router with minimal losses, still delivering our content to the consumer at the fastest possible speed.

The load on the ISP’s router is minimal, because the packets have the maximum possible size, their destination is constant, and the TCP overhead is kept to a minimum — normally, we get through dozens of packets in a batch (MTU is 1492 bytes, so roughly the payload for a single packet would be around 1400 bytes — these calculations including possible PPP overhead); with a 5Mbps channel this means we can theoretically pass up to 457 packets per batch, when the counter resets (note that it’s for an ideal “only one connection present” case; in reality, we’ve got other applications hogging parts of the bandwidth).

Now, you probably noticed that once the counter resets, we lose some time returning the batch counter back up. This is where download accelerator software, Bittorrent and other multipeer P2P systems kick in.

By having multiple connections, we decrease the maximum possible batch count, but in the meanwhile, we have several transfers going, and as they overlap, our 5Mbps channel is used completely (when the first connection resets its counter, the second is reaching the middle of the graph, and so on). The load on the router is a bit higher, but still nothing really serious.

We can obtain the same results with UDP, however, this time we have to rely on the software to control the flow and catch errors. Well-designed software takes note of TCP’s advantages and implements the same scheme, but with some optimisations (for example, instead of incrementing the batch counter, it multiplies the counter by 2, thus reaching larger payloads in a batch quicker; it also can store the “last maximum batch size” for a connection, and use it to further enhance its bandwidth management).

Note: the protocol itself does not provide any bandwidth management measures, unlike TCP. Thus a badly designed piece of software would just spam the shaping router with packets over and over again, resulting in massive amounts of them being dropped and not making it to the remote client. And this would force the software to re-send the dropped packets again and again. As you see, this is an example of a trainwreck situation.

Now, with uTP, we have UDP with a dynamically changed payload size. Why would we need to change the size of a data packet dynamically? According to the developers, this allows to traverse clogged channels easily, increasing the overall performance of the connection.

They say that the packet size can go to as little as 150 bytes. Note: an UDP datagram contains a header which takes up 64 bytes. As you might notice, in this case the overhead is unreasonably high — especially when it’s a file transfer where we need to get as little overhead as possible due to massive amounts of data to be transferred.

But it’s not just about the payload vs overhead ratio. Transferring 1400 bytes in chunks of 150 bytes will require ten packets instead of a single one. And that’s just for a small, 1400 bytes, piece of data. Ten packets require 640 bytes just for the UDP datagrams’ headers.

Processing a single packet requires some CPU time on the router. Processing 10 packets requires ten times more CPU attention. Naturally, the packet rate rises rapidly and in the worst case scenario can get up to 3 000 packets per second for our 5Mbps channel. Three thousands packets per second. Just think about it.

The problem is that µTorrent, at least in its 2.0 release, tends to constantly decrease the packet size. The more connections you have allowed, the more concurrency there is, and the more µTorrent decreases the payload per packet. And the more users download something with µTorrent like this, the more the routers suffer.

Actually, SOHO routers like Linksys’s WRT54G start behaving extremely slow and sometimes even reboot on such occasions. Of course, the ISPs have far more sturdy devices, but the hardware is always limited in performance and even a monstrous $30 000 border router made by Cisco might get overloaded if a lot of customers participate in this conspiracy.

In short: please, disable uTP in your clients. At least until the µTorrent guys finally shape it into something more usable.

So I wanted the new version on my server.

And yeah, I had to update the port. Took much less time than back in February; this time I only had to update the patches, and remove one of them (the one which was required to build ejabberd using Erlang R12 and below). And of course update the pkg-plist file (packaging list, responsible for the removal of package’s files during deinstall).

There’s still a small problem with ejabberd somehow setting the permissions for Mnesia files to 750 instead of 640, but I’m too tired to fix it right now.

In case anyone is interested, here is the updated port directory (extracts to jabberd2 so you’ll want to extract it in /usr/ports/net-im).

/usr/local/etc/rc.d/ejabberd stop
cd
fetch http://media.fujibayashi.jp/software/ejabberd2-port.tar.gz
cd /usr/ports/net-im
tar xvzf ~/ejabberd2-port.tar.gz
cd ejabberd
make deinstall
cd ../ejabberd2
make install
/usr/local/etc/rc.d/ejabberd start

There is no need to convert your Mnesia database, however I advise to back it up (before stopping ejabberd) so you can restore in case something goes wrong:

su ejabberd -c "ejabberdctl dump /tmp/ejabberd.dump.`date \"+%Y-%m-%d\"`"

Of course, you can backup the database “as is” after you stop the server by copying /var/spool/ejabberd somewhere or archiving as a .tar file.

Almost nothing caught my attention (well, except, probably, kimi ni todoke, which is really nice but I can’t manage to get striking screenshots).

However, the decisive battle against my laziness will be held tomorrow, and should the victor of that round be yours truly, this site will be blessed with some more crappy reviews.

This magazine subscription can be purchased on a revolving basis (where we’ll reserve and bill each issue as it comes in) or annually (for a flat fee w/ SAL shipping included).

So each issue is reserved. I guess it means that my reserve subscription has priority over normal site orders – J-List probably accounts these subscriptions when ordering from the publisher.

Only not.

It’s not accounted. Either that, or their staff are incompetent, cannot read, etc.

To put it short, I have a reserve subscription, I got my July 2009 issue, as well as the August one. And then I got another package, which I opened to find another July 2009 volume – instead of September 2009 one. Hello, J-List?.. The delivery takes up to one month. So when I got the magazine, and mailed them about “なにぜファック”, they were out of stock. Now, I’m not really sure if that issue ever was “in stock” for me. Something tells me that sending a duplicate of a not-yet-sold-out issue instead of a rare one (and September 2009 issue is of the “rare” kind – because of lots of exclusive stuff that comes with it) isn’t something purely accidental.

How do you put an issue that stands out as having a different cover, and “2009-07″ printed, in a handful of all the same “2009-09″ volumes, for packing before shipping?

A friend of mine who uses subscription (but with credit card payments instead of Paypal) got his issue no problems. Fine; that doesn’t prove anything. And some other people whom I know ordered the exact September 2009 issue from J-List on a regular basis, not having a subscription active… and got theirs. And it wasn’t a “reserved for you” kind of order. They just preordered it on the site.

Thank you, J-List, for your excellent service. I’ll look for a more reliable source for my magazine subscriptions.

…And I still can’t find that issue anywhere.

In the meanwhile, some shitty photos (my camera is totally dying on me).

Seems like I have successfully moved this site to the server; and I’m not using Apache this time – the site runs on nginx using fastcgi-to-PHP interface.

Catching up on various anime series. Notable examples are Tayutama -kiss on my deity-, Pandora Hearts, and Fullmetal Alchemist: Brotherhood. There’s also Chrome-Shelled Regios.

As I have probably mentioned, I’ve never watched the original Fullmetal Alchemist series past episode 4 or 5, maybe 10 but not more – I got kind of bored with the slow pace of the series, and the lack of action. Basically, last episode I remember from the first version of the TV adaptation is the one where that guy (I’ve forgot his name yet again) uses his pet dog and his own daughter to transmute a chimera. I’m at episode 11 of the Brotherhood series, and so far there only were two filler episodes (or so); mostly it’s a really dynamic show – and I’d even put it on the “best of the season” list. So far it seems like they’re doing a fast forward of the events to get to the ‘main’ part – but even so it’s nicely done. However Roy Mustang still looks like he was born on a planet with extra high gravity.

Tayutama is still the same stereotypical, low-budget, and obvious-outcome type of a show; as expected from a series based on an eroge. However, I’m still watching it (and still mostly for Ameri and Nue; I sort of don’t like Mashiro and Yumina).

Last episodes of Pandora Hearts introduce a new character – a really cute girl called Echo (one of the manga volumes’ cover features Alice and Echo together in gothic lolita outfits and the art is pretty much damn awesome – however they look kind of alike).

Regios is quickly approaching the grand finale; the meaning of those weird scenes in the middle of the episodes is finally uncovered in the last three (or so) episodes. Nina still makes everyone worry, and Felli is being cute as always.

In other news: I don’t understand humans. Their behaviour is a complete mystery to me. And every step I take in the department of relations with them leads to a total clusterfuck (even though I just wanted to be friends with someone, some other person told me – with quite some pressure, too – that I’d better not talk much to that friend-to-be).

P.S. I need a new job. The current one is totally draining me out.

However.

I managed to catch up with Basquash!, the series featuring a brilliant and original idea of making an anime about basketball… played using giant robots. While it sounds stupid, it’s less dumb than it looks – but it was kind of hard to fight my way through the first three or four episodes which feature excessive fanservice.

The amount of fanservice drasically lowers in the following episodes, focusing more on Basquash’s highlight: street basketball. While I doubt that the idea of making robots wear running shoes would actually work, it’s overall cool. Especially when in the last two or three episodes Eclipse – the trio that sings the opening theme, nO limiT – enters the storyline with this dazzling debut of Rouge.

So far, my favourite characters are Flora/Alan (reverse trap; hey Haruka, question: if you really talk with feet, why didn’t you realise that Alan is girl yet?), Rouge, and Iceman (“Destroy! Destroy!! Destroy!!“).

Also in today’s Bunbunmaru issue:

I’ve managed to scrap up some parts for the server – since it needs an upgrade. Almost everything will be replaced, though, and one of the nicest parts about it is that I’ll use Intel PRO/1000 integrated NIC instead of this slightly laggy nForce4′s builtin one.

Currently, the server is an Athlon64-3200+ on a Gigabyte GA-K8N-SLi board – with a total of 5 hard disk drives (40GB system, and an assorted set of 200, 250, 320 and 500GB drives for data storage).

My plans are to use a Core2 Duo processor (probably the 3.0GHz one) on a Gigabyte Q35-based board, with 6 Serial ATA ports (instead of K8N-SLi’s four); and the drives will be replaced with the following structure: two 500GB drives in a GEOM_MIRROR array – hosting the system and the database files, along with static content and such stiff; two more 500GB drives in a raidz pool; and probably one 750GB drive for media files. The sixth port will probably be occupied by another 500GB drive, maybe in a pool – this time a stripe/RAID0 because I don’t need redundancy for the media storage.

The OS will also be changed; 7.2-STABLE used on the current server will be replaced with 8.0-STABLE as a fresh install. Yeah, it’ll take some time to migrate all settings and data, but it will be worth it. The new configuration is being stress-tested by me for the last few days and I’ve yet to see processes stuck in zfs I/O state which seems to be a common problem for 7.2′s ZFS implementation.

It contains, mainly, just some pictures.

My laptop went to the service centre last Thursday; it suffered some mild damage due to the lid’s fixture ripping through the case’s plastic. There also were two cracks on the top cover (the one with keyboard in it, not the lid). At first, they told me it might not be covered by the warranty but in the end I get completely free repairs. They will probably replace the DVD recorder, too, as it doesn’t work with CDs at all – it doesn’t even read them. And I’ve got 5 more months of warranty left.

I’m pretty stressed by the fact that the repairs will take at least one week and a half (up to two weeks, actually) because they need to get the new case for my laptop delivered from South Korea.

In other news:

Alice in episode 5 of Pandora Hearts is going tsundere with a charming accent on the dere side. Sometimes she’s just too cute; also, I giggled when Raven called Oz and Alice “kids”. Screenshots, probably, later.

Been to the new Star Trek movie this Sunday with some friends. I should note that I never watched any series or movies related to the Star Trek universe; so I pretty much didn’t expect too much and I got what I expected – a pretty nicely done sci fi action, way better than those new Star Wars episodes. Leonard McCoy was really nicely done, a pity he didn’t get much time. I also liked old Spock (the one from the “original” timespace), and the first captain of USS Enterprise (Christopher Pike was his name, I think). There were silly moments, of course, but not many of them. Conclusion: an overall good and entertaining movie.

And finally,

H*I*N*A Hinagiku! hai! hai!