Showing posts with label science. Show all posts
Showing posts with label science. Show all posts

Saturday, December 14, 2013

Rolling my warm, moist balls around

So my apartment has a pretty small combo washer/dryer, which for the most part isn't a big deal, but combined with the fact that it's ventless, it tends to take basically forever to properly dry clothes and tends to leave them pretty wrinkled.

The problem is that the clothes don't really tumble, pushing hot air around and through the fabric, but instead just basically rotate. This isn't how a tumble dryer is supposed to work.

So the idea came to me to get some of those dryer balls to try to help the clothes tumble properly. I checked amazon and wasn't really too thrilled with what I saw: lots of hollow spiky balls that people complained tended to lose their spikes. After a bit more searching I found some felted wool balls that looked a bit better, but for $30 for a six pack they didn't really inspire me to buy.

Then I thought to myself "I'm a man, I have a perfectly good set of balls I can use", specifically the set of lacrosse balls that I bought a few years back for juggling. They're nice and heavy, rubber, and Canadian, the three qualities that matter the most.

I gave them a try last night, and they seemed to work quite well. The load came out dry after about an hour of drying rather than coming out with damp spots after 2 hours. I'm not sure if they'd make much of a difference in a dryer that isn't painfully undersized, but if you find yourself disappointed with your drying performance, you can do worse than taking a chance on using your balls.

Sunday, November 24, 2013

Salting my nuts

Ok, that title sounds a lot dirtier than it really should.

A little back story first: I love pistachios. Like seriously love them. If there's nuts in my mouth, they'd better be wrinkled and green or someone's got some explaining to do!

But there's one thing I don't love about pistachios: the shells. For some completely inexplicable reason, someone at some point decided that pistachios, unlike virtually every other nut on the planet, must only be sold in-shell. Now these days they're thankfully no longer dyed neon red, but pre-shelled pistachios are still as rare as chicken teeth.

So it was with great joy that I discovered that Trader Joe's sells pre-shelled pistachios. Hurray! I bought a bag, brought it home, and further discovered that they're unsalted pre-shelled pistachios. Slightly less hurray.

Now the trouble with unsalted nuts is that if you try to just add salt you end up with a bowl full of unsalted nuts with a pile of salt at the bottom. Similarly if you follow the internet's advice and coat the nuts with oil before salting, you'll just end up with salty, greasy fingers.

The answer is that we need the salt to crystallize on the nuts themselves. To do that, it's really just a simple matter of making an over saturated solution of saltwater by mixing a good heaping tablespoon of salt with just enough water to make it liquidy, then tossing that with the nuts.

Of course now we have well salted but entirely too soggy nuts, and one must never tolerate having soggy nuts. So it's onto a baking sheet and into the oven on the lowest setting for an hour or three, stirring occasionally to keep things drying evenly.

And at the end of this long, arduous journey, we have a nice pile of well salted, pre-shelled pistachios. Mmm.

Tuesday, January 3, 2012

Help, uploading makes my internet slow!

Consumer broadband connections aren't designed right. They sound good on paper, of course "The majority of users download far more than they upload, so giving them higher download speeds and only a tiny amount of upload speed makes sense". In truth, it usually sort of kind of works... so long as all you ever do is download.

I don't only ever download, though. I create content now and then, and some of it is quite large. Large enough to take well over 10 hours to upload through the wee tiny upload pipe my provider gives me.

On the face of it this isn't really a problem. The material I'm uploading isn't remarkably time sensitive, and I don't produce it at a rate that exceeds my connection's ability to upload it. The problem is what happens to the download side of the pipe while this upload is going on.

Communication is a two-way street, you see. We need to be able to send out a request before we can get any data back, and we need to send out an acknowledgement before we get the next chunk and so on. Unfortunately our ability to send out these requests and acknowledgements is essentially cut off when the upload pipe is saturated, and we end up with packets backing up to the point where having any sort of interactive online experience is impossible, as is achieving anything close to a reasonable download rate for the few requests that do manage to make it through.

The solution to this, of course, is actually remarkably simple: We just have to keep the pipe from backing up by limiting the rate that we send data out. Of course, to avoid just moving the logjam further upstream, we also want to make sure that we throw out stale packets so they don't take up as much space, and thus time, in the queue.

Now I use a linux box for my main internet gateway, sitting between my connection to the world at large, and the legion devices on the warm, cozy side of the LAN. This means that setting up this rate limiting is a simple and straightforward task.

Or it would be, if the documentation weren't utter shit.

I actually spent quite a few hours paging through man pages and google looking for the magic incantation that would allow me to set up a sane rate limit queue on my linux box before coming up with the solution. To save you the trouble, here it is:

tc qdisc add dev shaw root tbf rate 60kbps burst 1540 latency 100ms

The command we're executing is "tc". The "qdisc" part means were issuing a queueing discipline command. The "add" means we're adding a new queueing discipline. All fine and dandy so far.

Now we specify the device we want to operate on. I've used "ifrename" to name my external interface "shaw", because that's who my provider is. Yours will probably be something uncreative like "eth0", but that aside the "dev shaw" part specifies the correct ethernet interface on my particular system.

The "root" part is the simple part of a complex puzzle. You can actually create a whole tree full of queues that feed into each other, each with different limits, algorithms, and a whole lot of other overcomplicated and unnecessary junk. We just want one queue, so we want it to be the root.

The "tbf" part is where we've specified the type of queue, in our case it's a "token bucket filter". Without going into too much detail, data is only sent downstream when there's enough "tokens" in the "bucket" to "pay" for them, and the tokens are replenished in wall-time thus achieving the rate limiting.

We specify this rate limit explicitly with the next part, "rate 60kbps". My upload bandwidth is actually 0.5mbit which translates to roughly 64kbps, but we want to make sure that we don't run too close to that limit or the logjam might form again at the cable modem.

The next part, "burst 1540" is where things start going off into the weeds. The documentation regarding this part of the command goes on about some technical details of how this needs to be set very large for things to work properly on fast connections because of kernel tick resolution limits. Of course, this is at least 5 years out of date since the kernel went tickless back in 2007 or so. In either case, this specifies the maximum size of the bucket (after which no more tokens can be added to it) and we want it to be at least big enough to pay for a full ethernet frame.

Finally, perhaps the most important part for keeping the logjam from forming, is the "latency 100ms" part. This defines how long a packet can linger in the queue before it's thrown out to make way for newer packets. Now one might think that throwing packets out would tend to make a complete mess of things, but in fact this is exactly what we want to do as reliable stream protocols like TCP will throttle back in the face of packet loss, reducing the logjam, and isochronous protocols will of course benefit more from having packets dropped rather than delivered late.

By deploying this rate limiting queue on my linux box I was able to ensure interactive internet performance while at the same time sacrificing little to no upload speed performance. This makes me happy, and I hope if you come into a similar situation that it'll make you happy too.

Saturday, December 10, 2011

Jet Airliners, Tractor Pulls, and Math

Recently a friend of mine made a post about the AF-447 crash and some of the human factors involved. One of the things he noted was that the thrust levers were not designed to indicate, by their position, the current thrust setting of the engines they controlled. At first glance, this seems an odd decision, but there is indeed a method to the madness.

Before we dive into that method, we first need to take a little detour through the deliciously redneck world of competitive tractor pulling. Yes, you read that right, tractor pulling...

Tuesday, December 14, 2010

A minor scare

So yesterday, when I was out in the Polo Park area after writing my exam, I had left my backpack with my laptop in the car (I know, I know). It was still there when I returned a few hours later, but unfortunately the cold temperature had taken its toll.

When I woke up my laptop when I got home, to my horror I saw a series of teal streaks on the display. Needless to say, I was not pleased.

The streaks were on the order of a pixel or two wide, and up to an inch long. They seemed to react to pressure, so I surmised that whatever was happening wasn't just outright pixel death. I played a bit of minecraft to see if exercising the pixels with a changing picture would help things along, and after a little while of playing it seemed that the streaks were starting to get better.

Then the inspiration hit me: condensation inside the panel! The cold temperatures and high relative humidity inside my car had clearly caused some water or frost to infiltrate the panel and condense, messing with the function of the display.

To test this theory, I got out my hair dryer and, starting on low, heated up some problem areas. To my delight, they reacted by shrinking and lightening. After 10-15 minutes of heating, the areas I was concentrating on had vanished into perfect, flawless pixels, and I continued my way around the monitor cooking off the streaks. In the bottom corner, the last and worst trouble spot, I had to switch the hair dryer onto high, but those pixels too were soon brought back to life.

All in all, I'm annoyed but happy, and find myself with yet another reason to hate winter.

Monday, August 24, 2009

A Sense of Scale

If you took a hydrogen atom and scaled it up so that the proton was the size of a golf ball, you'd find the electron about 2.22 kilometers away.

People tend to have a much more compact mental image of atoms.