If I open this on iPhone and tap a bar, they eventually shrink down until they look like this https://ibb.co/B2PJXD7 and stay that way. What’s the point?
If you tap above a bar you can make them larger again. The bars are scaled to always stay relative to each other, the point is that you can explore back and forth to see the relative time it takes to complete various operations for a computer.
Why should I want to tap the bars in the first place?
Why can I tap the largest bar so much that it can become as small as others in the end?
Why can't bars just auto-resize when I scroll the page horizontally?
You're the designer here, so it's up to you to shape user experience to deliver your point. Instead you allow users to ruin it for themselves and don't even try to control the narrative of the page. Sorry, don't know what you wanted to do here but I don't think it's working.
I think it’s a nice visualization, and I really appreciate your open welcoming attitude in the comments here to all manner of critique.
How much work was this and what are the trickiest parts? I see a lot of discussion of different platforms & browsers, which has always been surprisingly tough.
FWIW, I think you’re close to a nice UX and it wouldn’t take much to eliminate most complaints, though I’m speculating, and I know (from experience developing UIs) that everyone’s got different expectations and opinions about their UIs so it can be hard to find the maxima…
I don’t mind the sideways text much, but it would be cool if the bars were narrower so they all fit on-screen at once. (I’m on iPad btw.) It would be nice if the text didn’t move with the bar, but always stayed fixed and visible while the bar changed sizes.
It would be nice if the credit dialog could be minimized/toggled. Or maybe positioned as a title banner, and the data didn’t overlap? I don’t know why but overlapping things give me anxiety.
At first I didn’t understand how the bigger/smaller controls on a data bar worked, I thought it was a toggle, so I thought I had a hard time getting the L1 number to come back up, and didn’t realize I needed to click further up near the title overlay. A toggle might be more intuitive? (i.e. click above bar to make it scale to top of screen, click on bar to set scale so that the bar to the right is exactly top of screen…) Might be neat if the bars were draggable - are they already?
It is indeed a year. The latencies are based on the calculations done by Colin Scott in https://github.com/colin-scott/interactive_latencies and support projecting out into the future. Sorry it's not as obvious as it could be.
It’s indeed been about 100ns for a long time. Part of this is that memory is larger though, so there may be more decisions to make to look up a line (and those are made faster). And throughput has improved. Some consumer high-end desktop hardware (think gaming rather than workstation) can have lower latency ram.
Very cool little thing. The interface initially isn't very intuitive but once you figure out the correlation between the above/below bar clicks it is kind of cool.
I didn't spend quite as long on this as I would my "proper" posts, so I completely agree the interface could be better. To help me learn and get better at this, I'd love to hear what you specifically had problems with trying to use it <3
Agreed, on my second view I noticed the tutorial box, totally missed it the first time.
It's neat. OP, have you considered adding a toggle to switch to logarithmic scale? You could retain the time travel feature, but also show all values simultaneously.
DC round trip at a constant 500 mics is a bit surprising to me. I guess it’s just a hard number for Scott to get historical values for, and depends a lot on how networking in a datacentre is set up.
I bring criticism: The first few bars on my screen cannot be read, as the text is hidden behind the floating HUD. If I click on the next few bars, to bring those below the box, then the bar becomes too small and the text is cropped, so I cannot read it either.
It is also a bit uncomfortable to read 90° text. It's fun to click the bars and play with the UI, but not to actually read what they say. It's a nice visualization, but it suffers from form over function! I can't comfortably use it to learn about the numbers I should know :(
I appreciate the feedback! I'm trying to get better and comments like this genuinely help.
Are you reading on a landscape tablet? I know the sizes of stuff are wrong on that form factor. Desktop and mobile shouldn't have the first couple of bars obscured.
The sideways text is meant to be a subtle nod to the fact the page scrolls sideways, but I agree it's not as nice to read as it would be were the text the right way around.
>> Desktop and mobile shouldn't have the first couple of bars obscured.
I am on a desktop with a huge monitor in ultra high res. It is pretty bad.
>> The sideways text is meant to be a subtle nod to the fact the page scrolls sideways, but I agree it's not as nice to read as it would be were the text the right way around.
Then the subtle nod is lost on me... why not turn the text when I click, or have hover text, or make the whole page rotated 90 degrees?
Like the original response, it was fun for one second, then I was like I can not read this stuff, or its painful.
I'm reading on a 1080p desktop. Although accounting for the browser chrome (bookmarks, tabs on the side), my window.inner{Width,Height} comes out as 1583x950
Don’t forget Grace Hopper (1906 – 1992), American computer scientist, mathematician, and United States Navy rear admiral.
> Hopper became known for her nanoseconds visual aid. People (such as generals and admirals) used to ask her why satellite communication took so long. She started handing out pieces of wire that were just under one foot long—11.8 inches (30 cm)—the distance that light travels in one nanosecond. She gave these pieces of wire the metonym "nanoseconds." She was careful to tell her audience that the length of her nanoseconds was actually the maximum distance the signals would travel in a vacuum, and that signals would travel more slowly through the actual wires that were her teaching aids. Later she used the same pieces of wire to illustrate why computers had to be small to be fast. At many of her talks and visits, she handed out "nanoseconds" to everyone in the audience, contrasting them with a coil of wire 984 feet (300 meters) long, representing a microsecond. Later, while giving these lectures while working for DEC, she passed out packets of pepper, calling the individual grains of ground pepper picoseconds.
Maybe because speed of light is more approachable to a general audience, and maybe because she’s making a point about absolute upper bounds for all possible signals and didn’t want to reference something that could be improved, or because signal speed depends on the medium and maybe she didn’t feel like rat-holing on materials to make a point about speed of light? Light signals travel at light speed through space. 27cm works for electrical signals but not optical signals in fiber or space, nor other signal types. 30cm as a bound always works, and happens to be a nice round number too, more memorable… I see a lot of reasons why not just. :P
interesting demo. also scaling logarithmically would look cool as most bars disappear most of the time. (maybe you can add horizontal bars to the background and scale the distances between them as well)
What aspects of this are unreadable? Is it all a bit too big? Does there need to be a way to identify the columns after they’re off screen that doesn’t involve tapping on them again?
Sorry, want to dig in a little bit here to help me improve for next time. I really appreciate your replies.
When you say it’s impossible to see times and text labels at the same time, are you aware you can move each bar to any height on the screen? They move to the height of the cursor when you click. It’s extremely unobvious, I know, I’m sorry.
It always frustrated me a little that it's hard to use on mobile, so I had a go at making something a bit different. Did my best to give credit to Colin. :)
1. I didn't expect people to have such a negative reaction to sideways text. It doesn't bother me personally, but it seems some people really can't work with it. I'll likely avoid it in everything else I do going forward.
2. I feel a big part of the problem here is that it's not obvious how to get it back once it's gone. I could certainly try making the text visible after the bar is gone.
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.
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.
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?)
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.
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.
Another problem is that on low resolution screens (or small browser windows) the boxes on the top left hide the text on the bars behind. I had to zoom out to 50% for it to be readable, which then put other bars behind the boxes.
Because they're comparing two different things. The main memory reference is latency, the 1K is a throughput measurement.
In other words they're not saying "if you send only 1K of data it will take this long". They're saying "if you send 1 GB, then the total time divided by 1 million is this much".
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;
}
They’re saying that a “commodity NIC” doubles in bandwidth every 2 years, and extrapolating forward given that 1Gb was (supposedly) standard in 2003; the website in the post transcribed this incorrectly and put 1Gb in the description of the datapoint, but we can see from first principles that the figure is clearly that of a 200Gb link.
The original source linked from this post [0] is using models that assume exponential growth of bandwidths over time (see the JavaScript at the bottom of the page): this is fun, but these figures are real things that can be measured, so I think it’s very misleading for the site in this link to present them without explaining they’re basically made up.
The 1Gb network latency figure on this post is complete nonsense (I left another comment about this further down); looking at the source data it’s clear that this is because this isn’t based on a 1Gb network, but rather a “commodity NIC” with this model, and the quoted figure is for a 200Gb network:
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;
}
I don't think I'd wait even 15 seconds. Maybe on average across all users because a lot of users have slower connections or devices so they're more patient. But I'd expect to have something in 3 or 4 seconds. Even that I consider slow. At probably 8 or 10 I'm gone.
Some of these have always been quite counterintuitive to me, particularly the networking ones. Google Stadia was always an exercise in edge cases in expectations on these numbers for me.
It felt weird that a gaming computer in a datacenter could be "faster" than a computer on my network, but one frame takes ~16ms to render, bandwidth is big enough to stream, network latency might only be another ~frame, and suddenly the image is on my machine within 2 or 3 frames. However there were unexpectedly slow parts! The controller actually ran over WiFi directly, so that inputs went straight to the server rather than via Bluetooth, comparing with Xbox Cloud on a Bluetooth controller, this made a huge difference, but that makes sense because Bluetooth's latency might be 1-2 frames itself. It's counterintuitive to me that the latency from my controller to my computer, less than 1m, might be higher than the latency from my computer, to my router, to my ISP, to Google's DC, and to a server. Similarly, the latency on HDMI from a computer to my TV is in the same ballpark of a few frames because of all the processing my cheap TV does to look good.
Man, I had such high hopes for Stadia. I was an SRE at Google when it was being built and knew some of the traffic folks working on the networking parts of it. Some of the absolute best people. Such a shame.
I’d never have considered adding WiFi to the controller to _reduce_ latency, that’s absolutely wild. Thanks for sharing!
I'm not sure why you'd find it wild. Any gamer with decent tech knowledge never buys Bluetooth wireless devices (mouse kb headset etc) for gaming precisely for this reason. Sites like rting measures latency for the same reason.
Gamers know about bluetooth latency when specifically compared to wired peripherals, and in that case I think that's intuitive. The counterintuitive part is that WiFi – a much more complex spec, plus all the IP stack, connecting to web services from a small low powered device, etc – is faster than a "simple" bluetooth connection designed for such devices.
This is great. Lots of feedback and info sharing from everyone’s collective knowledge base. Lot of feedback from thr grey beards around in the retro era eg 1980-1990 and those who are on the bleeding edge inventing the future. Good job. Keep going.
1) If a technology didn’t exist. I’d make the bar black / grey. The pedants will hound you to death
2) A means to see the trend of a given feature on log plot if necessary. Eg Memory access 1980-2030 is interesting.
3) An info icon on the bar (i in a circle) to get details about the measurement. Disks seek for example is pegged at 1ms because it’s where mechanical disks have limits. If so is it track to track or full stroke seek ?
The 1MB streaming data from disk should be closer to 4ms (250MB/s). Disk streaming rates (on 7200rpm drives) have not improved significantly, based upon the published “sustained transfer rate OD” metrics from the three drive manufacturers.
The design is aesthetic and all, but it does not convey the information well.
Instead, just show an isometric graph with dates moving right-down, and each type, right-up, if that makes sense. Then, a single static 3d-ish image would show the different latencies and how they've changed over the years. No need for all the interactive gadgetry, that adds nothing, and in fact just obscures the big picture.
Unless using log scales, you might need some way to adjust the scales so that everything fits - maybe click on a 'column', or even an individual bar, to normalize it, and everything else scales relative, somewhat like your site.
First of all, I hope you don't take the feedback here personally. It's great that you tried your design skills in a risky, unconventional presentation form. With all that said, I still think this page is unusable. The colors, fonts are nice though.
Just open your site on mobile and imagine that you don't know the dataset by heart.
Can you glance at the values, can you easily compare different values? When you scroll half a screen to the right, are you completely lost? I know I am. When you select the largest or smallest item, what do you see? What if you then scroll to the other end of the spectrum? Can you read what the smallest item stands for? L1 C something? Can you change the scale so that you can improve what you see? Does scrolling up and down behave intuitively?
All in all, it's just impossible to extract useful information and context using this design. It looks great, you could post it on Behance and it will get positive feedback, but when someone actually wants to use it to discover what the data says, it's a very frustrating user experience.
It was a small experiment with some data I found interesting, I didn't expect it to get around as much as it has. I'm trying to get better at aspects of the web I'm not very good at.
It has given me lots to think about and learn from.
134 comments
[ 3.3 ms ] story [ 173 ms ] threadCan’t stress enough how grateful I am to Colin Scott for doing the work and open sourcing the calculations for the latencies over time.
Why can I tap the largest bar so much that it can become as small as others in the end?
Why can't bars just auto-resize when I scroll the page horizontally?
You're the designer here, so it's up to you to shape user experience to deliver your point. Instead you allow users to ruin it for themselves and don't even try to control the narrative of the page. Sorry, don't know what you wanted to do here but I don't think it's working.
You should disable pointer events / text selection etc.
I'm on Android (Samsung Galaxy S23+)
How much work was this and what are the trickiest parts? I see a lot of discussion of different platforms & browsers, which has always been surprisingly tough.
FWIW, I think you’re close to a nice UX and it wouldn’t take much to eliminate most complaints, though I’m speculating, and I know (from experience developing UIs) that everyone’s got different expectations and opinions about their UIs so it can be hard to find the maxima…
I don’t mind the sideways text much, but it would be cool if the bars were narrower so they all fit on-screen at once. (I’m on iPad btw.) It would be nice if the text didn’t move with the bar, but always stayed fixed and visible while the bar changed sizes.
It would be nice if the credit dialog could be minimized/toggled. Or maybe positioned as a title banner, and the data didn’t overlap? I don’t know why but overlapping things give me anxiety.
At first I didn’t understand how the bigger/smaller controls on a data bar worked, I thought it was a toggle, so I thought I had a hard time getting the L1 number to come back up, and didn’t realize I needed to click further up near the title overlay. A toggle might be more intuitive? (i.e. click above bar to make it scale to top of screen, click on bar to set scale so that the bar to the right is exactly top of screen…) Might be neat if the bars were draggable - are they already?
It's neat. OP, have you considered adding a toggle to switch to logarithmic scale? You could retain the time travel feature, but also show all values simultaneously.
I hadn’t, but it would be very easy to add.
It is also a bit uncomfortable to read 90° text. It's fun to click the bars and play with the UI, but not to actually read what they say. It's a nice visualization, but it suffers from form over function! I can't comfortably use it to learn about the numbers I should know :(
Are you reading on a landscape tablet? I know the sizes of stuff are wrong on that form factor. Desktop and mobile shouldn't have the first couple of bars obscured.
The sideways text is meant to be a subtle nod to the fact the page scrolls sideways, but I agree it's not as nice to read as it would be were the text the right way around.
I am on a desktop with a huge monitor in ultra high res. It is pretty bad.
>> The sideways text is meant to be a subtle nod to the fact the page scrolls sideways, but I agree it's not as nice to read as it would be were the text the right way around.
Then the subtle nod is lost on me... why not turn the text when I click, or have hover text, or make the whole page rotated 90 degrees?
Like the original response, it was fun for one second, then I was like I can not read this stuff, or its painful.
It is big but unreadable in 4k 32inch screen.
- Peter Norvig (original (?)) - http://norvig.com/21-days.html#answers
- Jeff Dean (slides) - https://www.cs.cornell.edu/projects/ladis2009/talks/dean-key...
- Colin Scott - https://github.com/colin-scott/interactive_latencies?tab=rea...
- this post
> Hopper became known for her nanoseconds visual aid. People (such as generals and admirals) used to ask her why satellite communication took so long. She started handing out pieces of wire that were just under one foot long—11.8 inches (30 cm)—the distance that light travels in one nanosecond. She gave these pieces of wire the metonym "nanoseconds." She was careful to tell her audience that the length of her nanoseconds was actually the maximum distance the signals would travel in a vacuum, and that signals would travel more slowly through the actual wires that were her teaching aids. Later she used the same pieces of wire to illustrate why computers had to be small to be fast. At many of her talks and visits, she handed out "nanoseconds" to everyone in the audience, contrasting them with a coil of wire 984 feet (300 meters) long, representing a microsecond. Later, while giving these lectures while working for DEC, she passed out packets of pepper, calling the individual grains of ground pepper picoseconds.
https://en.wikipedia.org/wiki/Grace_Hopper
New UI is just a cool animation, but it is unreadable on a 4K 32-inch screen.
Old UI is intuitive and doesn't require 10 pages of instructions and you can actually see numbers and labels all the time.
It is impossible to see times and text labels at the same time.
I am not going to remember what that 100ms was when I am changing years.
When you say it’s impossible to see times and text labels at the same time, are you aware you can move each bar to any height on the screen? They move to the height of the cursor when you click. It’s extremely unobvious, I know, I’m sorry.
I have to make bar smaller (hide text label) to see time, but then I cannot see the text label.
I want to compare something in middle (memory read) and last bar (CA->Ned) at the same time.
https://imgur.com/a/7lBCQob
L1 cache reference = 1ns
Branch mispredict = 3ns
L2 cache reference = 4ns
Mutex lock/unlock = 17ns
Send 1K bytes over 1 Gbps network = 44ns
Main memory reference = 100ns
Compress 1K bytes with Zippy = 2us
Read 1 MB sequentially from memory = 3us
Read 4K randomly from SSD = 16us
Read 1 MB sequentially from SSD = 49us
Round trip within same datacenter = 500us
Read 1 MB sequentially from disk = 825us
Disk seek = 2ms
Send packet CA->Netherlands->CA = 150ms
Can we discuss the actual material now.
1. The vertical text is difficult to read despite its size, because it's vertical.
2. When we click on it a large part of the text disappears below the bottom margin of the page.
Problem number 1 is not so bad but the combination with 2 kills the UX. The text in the clicked bar should appear somewhere on screen, horizontally.
Edit: if anybody like me wonders what's Zippy its a C++ compression library from Google. It's called Snappy now [1]
[1] https://en.wikipedia.org/wiki/Snappy_(compression)
2. I feel a big part of the problem here is that it's not obvious how to get it back once it's gone. I could certainly try making the text visible after the bar is gone.
That’s why we have graphs and charts in the first place.
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?)
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.
In other words they're not saying "if you send only 1K of data it will take this long". They're saying "if you send 1 GB, then the total time divided by 1 million is this much".
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:
[0] https://colin-scott.github.io/personal_website/research/inte...The 1Gb network latency figure on this post is complete nonsense (I left another comment about this further down); looking at the source data it’s clear that this is because this isn’t based on a 1Gb network, but rather a “commodity NIC” with this model, and the quoted figure is for a 200Gb network:
[0] https://colin-scott.github.io/personal_website/research/inte...Doubt.
40ms - average human thinks the operation is instant.
15s - user gets frustrated and closes your app or website.
It felt weird that a gaming computer in a datacenter could be "faster" than a computer on my network, but one frame takes ~16ms to render, bandwidth is big enough to stream, network latency might only be another ~frame, and suddenly the image is on my machine within 2 or 3 frames. However there were unexpectedly slow parts! The controller actually ran over WiFi directly, so that inputs went straight to the server rather than via Bluetooth, comparing with Xbox Cloud on a Bluetooth controller, this made a huge difference, but that makes sense because Bluetooth's latency might be 1-2 frames itself. It's counterintuitive to me that the latency from my controller to my computer, less than 1m, might be higher than the latency from my computer, to my router, to my ISP, to Google's DC, and to a server. Similarly, the latency on HDMI from a computer to my TV is in the same ballpark of a few frames because of all the processing my cheap TV does to look good.
I’d never have considered adding WiFi to the controller to _reduce_ latency, that’s absolutely wild. Thanks for sharing!
1) If a technology didn’t exist. I’d make the bar black / grey. The pedants will hound you to death
2) A means to see the trend of a given feature on log plot if necessary. Eg Memory access 1980-2030 is interesting.
3) An info icon on the bar (i in a circle) to get details about the measurement. Disks seek for example is pegged at 1ms because it’s where mechanical disks have limits. If so is it track to track or full stroke seek ?
Instead, just show an isometric graph with dates moving right-down, and each type, right-up, if that makes sense. Then, a single static 3d-ish image would show the different latencies and how they've changed over the years. No need for all the interactive gadgetry, that adds nothing, and in fact just obscures the big picture.
https://camo.githubusercontent.com/6e7f6707a2532cca1a5bf4ffb...
Unless using log scales, you might need some way to adjust the scales so that everything fits - maybe click on a 'column', or even an individual bar, to normalize it, and everything else scales relative, somewhat like your site.
Love the site.
Just open your site on mobile and imagine that you don't know the dataset by heart.
Can you glance at the values, can you easily compare different values? When you scroll half a screen to the right, are you completely lost? I know I am. When you select the largest or smallest item, what do you see? What if you then scroll to the other end of the spectrum? Can you read what the smallest item stands for? L1 C something? Can you change the scale so that you can improve what you see? Does scrolling up and down behave intuitively?
All in all, it's just impossible to extract useful information and context using this design. It looks great, you could post it on Behance and it will get positive feedback, but when someone actually wants to use it to discover what the data says, it's a very frustrating user experience.
And I probably not the only one that took a few minutes to realize the number referred to the year.
It has given me lots to think about and learn from.