Professor Knuth will present his 19th Annual Christmas Tree Lecture on Monday, December 9, 2013 at 7:00 pm in NVIDIA Auditorium in Huang Engineering Center, 475 Via Ortega, Stanford University . For those unable to come to Stanford, the lecture will be broadcast online as a free webinar. If you would like to view the live broadcast, please register so that we can send you the link prior to the event.
The proper operation and maintenance of a network requires a reliable and efficient monitoring mechanism. The mechanism should handle large amount of monitoring data which are generated by different protocols. In addition, the requirements (e.g. response time, accuracy) imposed by long- term planned queries and short-term ad-hoc queries should be satisfied for multi-tenant computing models.
This paper proposes a novel mechanism for scalable storage and real-time processing of monitoring data. This mechanism takes advantage of a data-intensive framework for collecting network flow information records, as well as data points’ indexes. The design is not limited to a particular monitoring protocol, since it employs a generic structure for data handling. Thus, it’s applicable to a wide variety of monitoring solutions.
“As computing increases in importance in an ever more connected world, it becomes essential for the children of the world to have access to one of the critical tools that make this world possible: my genius. I mean, let’s be frank: I’m basically smarter than the next fifty smartest humans put together, and it would be criminal to hoard the benefits of my massive, veiny, throbbing brain all to myself and the wealthy elite. With that in mind, I have decided to make Mathematica — which only I could have developed and which is listed at many thousands of dollars per copy (and, really, a steal at twice the price given how infused it is with my unique brilliance) — free to all Raspberry Pi users. Sure it’ll be slow as shit. But think of it this way, even if you had like one ten millionth of my brain available to use, that could make the difference between you begging in the street and you being like a stockbroker or financial… guy… or something. Man, and I have to carry the whole thing around all the time! I’m surprised it doesn’t set off alarms at airport security checkpoints it’s so freakin’ powerful.”—Stephen Wolfram
Threads are the vehicle for concurrency in many approaches to parallel programming. Threads can be supported either by the operating system kernel or by user-level library code in the application address space, but neither approach has been fully satisfactory.
This paper addresses this dilemma. First, we argue that the performance of kernel threads is inherently worse than that of user-level threads, rather than this being an artifact of existing implementations; managing parallelism at the user level is essential to high- performance parallel computing. Next, we argue that the problems encountered in integrating user-level threads with other system services is a consequence of the lack of kernel support for user-level threads provided by contemporary multiprocessor operating systems; kernel threads are the wrong abstraction on which to support user-level management of parallelism. Finally, we describe the design, implementation, and performance of a new kernel interface and user-level thread package that together provide the same functionality as kernel threads without compromising the performance and flexibility advantages of user-level management of parallelism.
Sometimes people ask me what I do for a living, and “engineering hobo” doesn’t make sense to most.
I joined Facebook in the TI (traffic infrastructure) team where I work on proxygen (layer 7 load balancer), thrift (RPC and serialization framework), and perf (which focuses on client to edge performance). There was a recent post from Facebook Engineering titled, “Secure browsing by default”. This touched on a lot of work done by TI (as well as other teams) over the past year, some of which has just been landing.
The proxygen team did a lot of the OpenSSL/crypto work so that we could build SPDY support and roll it out widely. This helped enable SSL for a number of clients (since SPDY runs on top of SSL). This post also talked about efforts from the perf team (and other parts of TI) to build out an edge network. The Facebook edge network is what allows clients to terminate connections locally (at an edge POP), thus avoiding the expensive SSL handshake being even more expensive (by having to make multiple round trips across the world). This allows SSL handshaking to be network cheap and CPU distributed. Pair this with SPDY, where you have multiplexed requests over a single secured connection, and you have a pretty performant SSL infrastructure.
The article also talked about some of the upcoming security related work for Facebook, much of which TI will be building. This includes things like 2048-bit RSA keys, ECC (elliptic curve cryptography), PFS (perfect forward secrecy) via ECDHE key exchange, and a bunch of others as well. I’m particularly excited about ECDHE because it uses ephemeral keys on a per session basis, which makes retroactively decrypting recorded data a much more difficult problem.
It’s really fascinating to work on software that a billion people get to touch. Things that aren’t an issue with a million users or a hundred millions users become enormous problems. Scaling software to handle millions of requests per second is really challenging. The proxygen team is like ~4 people, the perf team is 3 people. Tiny teams solving huge problems. This is some of the stuff I get to work on. It’s pretty fun.
After my wife and I decided to trade in the big lights of NYC and head out west, I found myself asking the question, “What’s next?”. My career until this point has primarily consisted of startups, from the very small 1-2 person org to the larger 180 person org that Tumblr became while I was there. I had lived all over the country but until now hadn’t found my way out to the bay area. Did I want to start my own company? Did I want to join a seed stage startup? Did I want to join a well established startup? Lots of choices in the startup world of San Francisco.
One thing that I firmly believe, regardless of who or where you are, is that you should invest in yourself. You can’t be certain what the future of any job holds so if you’re going to work for someone else, at least pick an employer that will stretch you in a new way. Choose an employer that will give you opportunities that you haven’t had before. Been at an established startup? Join a seed stage startup. Been an engineer? Join as a senior engineer (or the dumbest engineer in a sea of smart guys). Make the long bet, invest in yourself.
As an engineering manager (and engineer) at startups I have found on many occasions that my experience betrays me. Eventually you don’t have fresh eyes for problems because at startups every problem starts to look the same. Your MySQL/PGSQL/Mongo/etc data store is at capacity. Your PHP/C++/Java/Scala/Ruby applications has gotten too big/slow/scary. Your architecture creaks. You go from bi-weekly to twice a month pay checks back to bi-weekly back to twice a month. The list goes on. If you ignore the technology, startup problems (for me) all end up looking the same.
When I started thinking about my next job, I started thinking about making the long bet. What experience would serve me well in 5 or 10 years, regardless of where my career goes? As I thought about the beginners mind problem (everything looks the same), I saw an opportunity to stretch by going the opposite direction (this is known as a pivot in the startup world). While most people tend to move towards startups from big companies, I was going to go the opposite direction and join a big company. I talked to people from Twitter, Intel, Salesforce, Facebook, and Google, getting some offers and some declines. Eventually I decided on Facebook
As an outsider, one thing I admired deeply about Facebook is something I heard consistently from friends who were employees. Facebook has a culture where innovation and speed aren’t just valued but are ‘the way’. To me this is a fascinating feat of organizational architecture and scale; how at 5000 employees does Facebook manage to maintain that culture? I have been at companies with less than 100 employees that managed to lose their way and forgot how to do this. As I went through the interview process I found this culture permeated throughout every part of my experience. In my first week as an employee, I have found the same to be true.
I joined Facebook to stretch myself, as I am not a big company person. More than anything however I want to know how FB does it, how they manage to scale the company. As an added bonus I think some of the tech is fascinating, and the people are great. This doesn’t have quite the conclusion I had hoped for, so I’ll leave this as is.
“The big surprise is that Google still uses the manually-crafted formula for its search results. They haven’t cut over to the machine learned model yet. Peter suggests two reasons for this. The first is hubris: the human experts who created the algorithm believe they can do better than a machine-learned model. The second reason is more interesting. Google’s search team worries that machine-learned models may be susceptible to catastrophic errors on searches that look very different from the training data. They believe the manually crafted model is less susceptible to such catastrophic errors on unforeseen query types.”—Anand Rajaraman in his blog post titled “Are Machine-Learned Models Prone to Catastrophic Errors?” (via foldmap)