League of Legends game protocol

I continue to be interested in understanding League of Legends lag. It’s a custom UDP protocol, so the usual way of measuring TCP packet loss doesn’t work.

I realized today the game must have something like a sequence number in the protocol. Apparently the LoL protocol is based on ENet, an open source “reliable UDP library”. There’s no dissector for ENet included in Wireshark but Google searches suggest several people have written them. packet-lol also has a LoL dissector but it is a couple years old, no idea if it’s still valid.

I’ve been hanging out on Freednode ##loldev recently, a nice little IRC channel. One thing they’re working on is documenting the observer protocol on a GitHub Wiki. But apparently that’s a totally different protocol from the UDP live game, based on HTTP requests for 30 second chunks of the game as well as keyframes, etc. A fair number of third party tools use the spectator protocol, sites like riftwalk.gg are doing some great game analysis. Neat stuff, but not relevant to the lag experienced while playing the game.

Here’s a big stack of links I’ve collected relevant to LoL protocols.


I have a headless Linux box and every time I reboot it there’s a several minute anxiety where I don’t know if it’s working or not. (I reboot only every year or so, I think fsck’s timer kicks in and it takes awhile.)

I want to see the console while its booting, without a monitor. I don’t want to fuss with serial cables. Netconsole looks like an option; kernel module that sends UDP log messages via a pre-arranged MAC address. Before the TCP/IP stack is initialized. Docs: Ubuntu, Arch, kernel.

SMART errors: living dangerously

My once-yearly look through root’s mail on my home server reveals errors from smartd

Device: /dev/sdb [SAT], 17 Offline uncorrectable sectors
Device: /dev/sdb [SAT], 17 Currently unreadable (pending) sectors

The error started 14 May 2014 10:57:07 +0000 at 5 errors, then jumped to 17 two hours later and has stayed at 17. It’s just a backup disk, so I’m going to live dangerously and see what happens. The disk is 2.5 years old and has a three year warranty.

Possibly related, rsnapshot hasn’t run cleanly in weeks and I didn’t notice because errors go to a local mail spool I never check. I should rethink that.


MacOS dd timings

I need to clone a 2TB USB disk on my Mac. Going to use dd. What’s the right block size?

The bigger the better, apparently, but there are diminishing returns. “bs=128k” is good; reading from USB and writing to /dev/null that gives me 38Mbytes / second, which IIRC is about the rate for a 5400 RPM disk. 16384 gives about 20Mbytes / second. The default 512 byte blocks gives 1.2Mbytes / second.

I love that the default is 30x slower than maximum. The legacy of SysV’s 512 byte disk blocks is never going to end.

$ dd if=/dev/rdisk2 of=/dev/null bs=128k count=10000 skip=1m
10000+0 records in
10000+0 records out
1310720000 bytes transferred in 34.233990 secs (38287094 bytes/sec)

Update: that was for timing disk reads. Disk writes were slower, a test copy from one USB disk to another on my iMac showed 17 MB/s, which would take 32 hours to copy a 2TB disc. I thought at first that was because writes are slow but then I remembered the iMac is USB 2.

My Linux box has USB 3 and can read the disk at 100 MB/s. Shouldn’t have trusted my memory about disk speeds! And a copy from disk to disk on my Linux box is showing 117 MB/s, or about 5 hours to do the copy. Bonus: I trust Linux not to be doing something weird behind my back with the disks.

The full 2TB copy ended up taking about 6.5 hours, for an average rate of 85 MB/s. I forget slow the end of a disk is.

1Mbps is inadequate

So there I am, playing along in League of Legends, a tense game but we might win yet if I just position Annie right and time her stuns (an exercise in counting to 4). It’s exciting and fun. Suddenly the game lags out; characters freeze, skills don’t respond, things start sliding around and teleporting. Basically unplayable, 10 seconds later suddenly I get the packet that says “you died”.

Curse and swear. Switch to the bandwidth monitor, some random IP address is taking all my bandwidth. All 1 megabit. Go to the router status page, do the OUI identification of the Mac address, see it as an iPhone. That narrows it down to 3 iPhones. During death timers I find all three and put them in airplane mode, but by then it’s too late.

1 Megabit internet is just not adequate anymore. Seems crazy to say it, but there it is. The direct cause this time is some random iPhone deciding that right then was a good time to download a software update. At full speed, of course, because throttling is not a concept that’s well implemented in TCP/IP. In San Francisco I have a 100 Mbit link that’s either faster than the server or else the download completes so quickly I don’t notice. In Grass Valley, with the 1Mbps fixed wireless (the best I can buy), nope.

The underlying problem here is the US broadband infrastructure and the FCC’s collusion with the cable/telco duopoly ensuring no investment in the captive market. Fuck them.


softwareupdated (MacOS sucks)

I’ve lost track of all the confusing ways MacOS updates itself. But one of them that keeps biting me is that it insists on updating iTunes. I don’t want iTunes, I’ve set it to mode 000, I don’t want to waste my limited bandwidth downloading copies of it. Sometimes a popup appears in the upper right saying “updates available Install?” and there’s no way to see what it will install. So as a sucker I click Install, and suddenly here I am downloading iTunes.

The best part of all this is there’s no way clean to cancel the update. The App Store program will show the update progress bar, but the Cancel button does nothing. Using MacOS’ excellent Activity Monitor I can see the process doing all the downloading is softwareupdated. It ignores or catches ordinary kill signals. My only option seems to be a kill -9. Awesome.

WebGL vs Shutdown (MacOS sucks)

I went to a WebGL test page that warned it might crash your machine by drawing lots of polygons. Boy it wasn’t kidding. Locked up Chrome, locked up the Mac graphical shell. I could log in via ssh and the machine was fine, not even anything spinning CPU, but couldn’t kill the Chrome processes. kill -9 did nothing. So then I rebooted. It didn’t reboot either, the best MacOS could do was to shut down sshd so I couldn’t even log into my machine.

It’s pretty awful that some Javascript can kill all of MacOS. Chrome should know better. V8 should know better. WebGL should know better. OpenGL should know better. The Mac graphical shell should know better. The Mac kernel really should know better, because you really can’t count on anything else to. All fail.