Showing posts with label Shmoocon2013. Show all posts
Showing posts with label Shmoocon2013. Show all posts

Tuesday, February 26, 2013

Context matters: we only appear to be blackhats

After the #Shmoocon cybersec conference, a bunch of us were hanging out in the bar playing “Cards Against Humanity”. The rules are just like the family game “Apples to Apples”, but with content that’s not so family friendly. For example, “Harry Potter erotica” which was the winning card for the suggestion “A new interactive exhibit that will expand Smithsonian's audience”.

An eavesdropper might conclude that we are a bunch of child molesters, murderers, rapists, or racists. Of course we aren’t. We are crass and jaded; we are only pretending to be horrible people.

Thursday, February 21, 2013

Multi-core scaling: it’s not multi-threaded


I’m writing a series of posts based on my Shmoocon talk. In this post, I’m going to discuss “multi-core scaling”.

In the decade leading to 2001, Intel CPUs went from 33-MHz to 3-GHz, a thousand-fold hundred-fold increase in speed. In the decade since, they’ve been stuck at 3-GHz. Instead of faster clock speeds, they’ve been getting more logic. Instead of one instruction per clock cycle, they now execute four (“superscalar”). Instead of one computation per instruction, they now do eight (“SIMD”). Instead of a single CPU on a chip, they now put four (“multi-core”).

However, desktop processors have been stuck at four cores for several years now. That’s because the software is lagging. Multi-threaded software goes up to about four cores, but past that point, it fails to get any benefit from additional cores. Worse, adding cores past four often makes software go slower.

Wednesday, February 20, 2013

Custom stack: it goes to 11

I’m writing up my Shmoocon preso as a series of blogposts. Today I’m going to talk about custom network stacks.

The way network stacks work today is to let the kernel do all the heavy lifting. It starts with kernel drivers for Ethernet cards, which passes packets to the kernel’s TCP/IP stack. Upon the reception, the packet must make an arduous climb up the network stack until it finally escapes to user-mode. (User-mode is where applications run).

Tuesday, February 19, 2013

Unlearning College


I’m writing up my Shmoocon talk as a series of blog posts. In this post, I’m going to talk about the pernicious problem of college indoctrination. What colleges teach about networking is bad. A lot of material is out of date. A lot is just plane inaccurate (having never been “in date”). A lot is aspirational: networks don’t work that way, but your professor wishes they would. As a consequence, students leaving college are helpless, failing at real-world problems like portability, reliability, cybersecurity, and scalability.

Sunday, February 17, 2013

Scalability: it's the question that drives us

In order to grok the concept of scalability, I've drawn a series of graphs. Talking about "scalability" is hard because we translate those numbers into "performance". But the two concepts are unrelated. We say things like "NodeJS is 85% as fast as Nginx", but speed doesn't matter, scalability does. The important difference in those two is how they scale, not how they perform. I'm going to show these graphs in this post.