irq

more than a tweet, less than a blog, serially techie

[irq]

The exponential growth in data traffic puts ever-increasing demands on the packet processing elements in the network, resulting in a need for high performance IP packet handling. OpenFastPath is an open source implementation of a high performance TCP/IP stack that provides features that network application developers need to cope with today’s fast-paced network.

OpenFastPath | The OpenFastPath project page

[irq]

(via xkcd: Water Delivery)

[irq]

QJump is a simple approach that improves latency determinism in datacenter networks. It works by employing two techniques: 1. rate-limiting the input into the network, so that long queues cannot build up; and 2. prioritizing traffic in the network, so that different applications can use rate-limits that suit them best. With QJump, traffic from latency-sensitive applications (e.g., memcached) can "jump-the-queue" over traffic from latency-insensitive applications (like Hadoop). At the same time, traffic from many instances of memcached is rate-limited, so that they do not interfere with each other, while traffic from Hadoop runs without rate-limits and achieves full network utilization.

QJump - By CamSaS

[irq]

Realities of Performance Appraisal

Much has been written recently about performance ratings and management at some large and successful companies. Amazon has surfaced as a company implementing OLRs, organization and leadership revie...

[irq]

(via Bits or pieces?: On the future.)

[irq]

Adrian sees it as a calculated risk. “You’re gambling that the ecosystem is going to grow faster and bigger,” he says, “rather than 100 percent control of a small ecosystem, you become a dominant player in a much bigger ecosystem.”

TNS Analysts, Show 55: Google, Docker and the State of Open Source Projects - The New Stack

[irq]

I’ll paint a stark picture: Given a piece of code that is absolutely optimal — it is faster than any other piece of code that does the exact same thing on earth, only no one knows now it works except the author — versus a piece of code that was written by someone in order for it to be augmented, modified, adapted, flexible and all of these things, I would take the latter.

Microservices, monoliths and laser nail guns: Etsy tech boss on finding the right focus — > S C A L E — Medium

[irq]

First, assembling the right team. (That means) hiring, certainly, but it also means parting ways with folks that just aren’t cutting it…making sure that we’re paying attention to that team dynamic and [that] it’s collaborative and it’s really challenging itself. Number two is making sure decisions are being made. I say that if I have to make a decision, we have an organizational failure. (That's) because I don’t have the same context as someone who is working day to day with the data, with the understanding of the customer. I definitely see the organization and the people in it as the ones to make the decisions, because they have the greatest context for what needs to be done.

Jack Dorsey: Twitter co-founder, Square CEO, punk | Marketplace.org

[irq]

Modern software engineering is built upon abstractions that allow programmers to manage the complexity of ever-larger systems. Abstractions do this by simplifying or generalizing some aspect of the underlying system. This doesn't come for free, though—simplification is an inherently lossy process and some of the lost details may be important. Moreover, abstractions are often defined in terms of function rather than performance. Somewhere deep below an application are electrical currents flowing through semiconductors and pulses of light traveling down fibers. Programmers rarely need to think of their systems in these terms, but if their conceptualized view drifts too far from reality they are likely to experience unpleasant surprises.

Evolution and Practice: Low-latency Distributed Applications in Finance - ACM Queue

[irq]

Most systems exhibit some variance in latency from one event to the next. In some cases the variance (and especially the highest-latency outliers) drives the design, much more so than the average case. It is important to understand which statistical measure of latency is appropriate to the specific problem. For example, if you are building a trading system that earns small profits when the latency is below some threshold but incurs massive losses when latency exceeds that threshold, then you should be measuring the peak latency (or, alternatively, the percentage of requests that exceed the threshold) rather than the mean. On the other hand, if the value of the system is more or less inversely proportional to the latency, then measuring (and optimizing) the average latency makes more sense even if it means there are some large outliers.

Evolution and Practice: Low-latency Distributed Applications in Finance - ACM Queue

[irq]

The latency requirements of a given application can be addressed in many ways, and each problem requires a different solution. There are some common themes, though. First, it is usually necessary to measure latency before it can be improved. Second, optimization often requires looking below abstraction layers and adapting to the reality of the physical infrastructure. Finally, it is sometimes possible to restructure the algorithms (or even the problem definition itself) to achieve low latency.

Evolution and Practice: Low-latency Distributed Applications in Finance - ACM Queue

[irq]

[continuations]

Technology companies have a tendency towards the quantitative. We like to measure things. And there is a lot that can be measured from page load times to net promoter scores. Even in board meetings the question “have we A/B tested that” is common. But the quantitative can only take you so far.

...

[irq]

While it’s correct to worry about the big issues, you must resist the urge to act on them directly. Before acting, you should first translate the big thing into a related set of little things. For example, if you are worried about making the quarter, then you should go on a few sales calls and see if you are selling your product in the most effective way possible. Are your sales people properly trained? Do they run a process that puts your product in the very best light and sets appropriate traps for your competitors? Are you selling at the right level in the organization? Is your product truly competitive? As you get the answers to these questions, you will develop more constructive little things to take action on. These little things might not help you make this quarter, but they will certainly help you make next quarter.

Little Things - Ben's Blog

[irq]

[irq]

Remove “like” from the discussion: Everyone has opinions about design — that’s simply natural and expected! One way to mitigate the “I like” (or “I don’t like”) is to remove that word and instead focus on “what works” or “doesn’t work” for a particular persona, context, or scenario. This forces the discussion to be about the functional nature of various design elements (yup, color has a function!) not subjective personal tastes, which tend to derail matters.

Lessons from Leading UX at a Startup — Medium

[irq]

It seems to me that we'll see Venn diagrams - your door lock, garage door opener, thermostat and alarm might talk to each other, but not talk to your fridge. The fridge might talk to Instacart and nothing else, while the washing machine (and thermostat) might talk to the smart meter to pick the best power cycle. And your phone will talk to them over wifi and IP, and one app or many. That is, for some things the connecting protocol will be something closed and sophisticated, for some IP, and for some it'll be AC power.

The home and the mobile supply chain — Benedict Evans