Comment by magnio

I guess the most readable form would be a static logarithmic plot with colored dots/bars and a legend in the corner (or on tap/hover). Everyone interested in these numbers likely knows how to read it.

Point 1, we're used to sideways text because of books on a shelf but here it's compounded by the text almost disappearing after the click. The only way to get it back is clicking multiple times in the empty space above the bar. The only hint to click there is in one of the steps in the text box on the left, which probably nobody reads. Something to click above the bar (an arrow up?) would probably remove the need for the help text. Other hints could remove the need for any help text and free the box to display the content of the clicked bar.

It seems like there's some potential here, but not quite nailed yet.

I'd already seen cost model numbers like these before, but this interactive visualization still seemed to obscure the information as I was taking a first look.

I wonder whether it would be more useful adapted to a visualization/calculator for specific numbers, maybe for multiple operations in an algorithm, and the alternatives for implementing each? (And the click-to-scale is for selecting N for each operation, and maybe somehow constants?)

FWIW I don't mind the sideways text, but the ant's-eye-view histogram is one of the strangest user experiences I've had in data science.

Not to diminish your art or anything, but if you just want to present some numbers, a <table> with two columns is fine. We can infer scale.

My intuition was that scrolling would increase the y-axis maximum. (Effectively, scrolling would “zoom out”)

And that scrolling horizontally would pan me through the content.

Browsing on mobile, I should clarify.

But I’ll add that I also got the hang of scrolling back “in” fairly quickly. After I had zoomed out a couple times, then finally stopped to read the instructions.

Mmm.. you could rotate both text and bars, right? Like, horizontal bars.

It also has very poor contrast. I can turn my phone on the side to read the vertical text but the white text is impossible to read on the yellow and orange backgrounds.

On an iPad most of text is obscured and I can’t read some of the bars in landscape or portrait mode. The sideways text is also hard to read.

This figure quoted on this website is completely wrong: the serialisation delay of 1KiB on a 1Gb link is much higher than that, it’s actually closer to 10us.

This is a transcription error from the source data, which as it turns out is based on a rough exponential model rather than real data, but first let’s consider the original claim:

If there’s a buffer on the send side, then assuming the buffer has enough space, the send is fire and forget, and costs a 1KiB memcpy regardless of the link speed.

If there’s no buffer, or the buffer is full, then you will need to wait the entire serialisation delay, which is orders of magnitude higher than 44ns.

One might further make assumptions on the packet size and arrival rate distributions, and compute an expected wait time, but otherwise the default assumption for a figure like this would be to assume the link is saturated, and the sender has to wait the whole serialisation delay.

> They're saying "if you send 1 GB, then the total time divided by 1 million is this much".

This would take ~8s to serialise, neglecting L1 overheads, dividing that by 1MM gives you 8us (my ~10us figure above), which is ~200x higher than 44ns.

Looking at the source data [0], it says “commodity network”, not 1Gb, so based on the presented data, they must be talking about a 200Gb network, which is increasingly common (although rare outside of very serious data centres), not a 1Gb network like the post claims.

Interestingly the source data quotes an even smaller number of 11ns when first loaded, which jumps back to 44ns if you change the year away from 2020 (the default when it loads) and back again.

That implies 800Gb: there is an 800GbE spec (802.3df), but it’s very recent, and probably still too specialised/niche to be considered “commodity”.

Digging further, we see that the source data is computed based models that show various bandwidths growing exponentially over time, not based on a any real data, so these data are extremely rough, given these are real figures that can actually be measured:

    function getNICTransmissionDelay(payloadBytes) {
            // NIC bandwidth doubles every 2 years
            // [source: http://ampcamp.berkeley.edu/wp-content/uploads/2012/06/Ion-stoica-amp-camp-21012-warehouse-scale-computing-intro-final.pdf]
            // TODO: should really be a step function
            // 1Gb/s = 125MB/s = 125*10^6 B/s in 2003
            // 125*10^6 = a*b^x
            // b = 2^(1/2)
            // -> a = 125*10^6 / 2^(2003.5)
            var a = 125 * Math.pow(10,6) / Math.pow(2,shift(2003) * 0.5);
            var b = Math.pow(2, 1.0/2);
            var bw = a * Math.pow(b, shift(year));
        // B/s * s/ns = B/ns
            var ns = payloadBytes / (bw / Math.pow(10,9));
            return ns;
        }

[0] https://colin-scott.github.io/personal_website/research/inte...