I'd be impressed with a touchpad and OS that can go from an actuation to a userspace process receiving a click event in 1.2ms. I'd expect something more like 10x that. My understanding is that most hardware samples between 90-130Hz, and even premium hardware only samples at 250Hz which would average 2ms before the kernel is aware.
200 Milliseconds
41–50 of 114 posts
Re: 200 Milliseconds
#42> Violet marks the data as it moves, always top to bottom. Nothing else on the page uses that color. I'm seeing 3 violet elements on my screen. "ms" in the top left, the dot next to that text, and a dot on a horizontal timeline at the lower edge of the screen. Scrolling down I see yet more violet UI elements, I assume the one on the vertical timeline represents the data, while all the others represent... other things…
Yeah this smells like the type of comment an LLM leaves when it gets a really specific instruction. “use one consistent color for the data timeline. Right now we’re using multiple which is confusing.” Then the LLM writes some comment that’s a mini retrospective on what happened to justify itself.
Claude seems to do this all the time. That, the empty words and the increased self initiative of claude were all reasons I decided to just use codex (now merged into GPT).
Re: 200 Milliseconds
#43So why does it take 5-10 seconds from card presented to accepted at Starbucks and CVS?
Re: 200 Milliseconds
#44This is magnificent! Gave me roller-coaster ride across 40 years of gathering knowledge about computers and networks. I'm very jealous of whoever created that. Well done!
You are not jealous. You are envious. Homer explains it best https://youtu.be/Tmx1jpqv3RA
I can always rely on hacker news to improve my English
Re: 200 Milliseconds
#45200ms is insane, 50ms is the goal. But really, great page. Someone new could learn from it the basics of what to check when debugging web.
The US is so big, that 50 ms is physically not possible for everyone. This is something that not everybody is aware of. When I as a German build something for germans, everyone who needs to wait longer than 100 ms for a request, is rightfully mad. But when I want to serve the same stuff to americans at the same speed, I have to build something completely different and much more complex.
Not for everyone, but most people are located in population centers with nearby PoPs.
Re: 200 Milliseconds
#46Earlier quoted context omitted.
> At 2000ms, without output, you wonder if it crashed. (That was the old one.) That must have been a really, really long time ago indeed, because there are very few websites now that take less than 2000ms to load. The linked site didn’t even come close on my phone (probably 3-4 seconds), and I most certainly didn’t wonder whether it had crashed.
I'm finding more and more web sites that won't load at all until I request them a second time.
maybe the site's debouncing logic on the buttons isn't working well
Re: 200 Milliseconds
#47Am I crazy if for something like an online purchase, I kind of expect it to take a second or two to process the payment, so I would assume something went wrong if it was 200ms?
IIRC TurboTax has a bunch of loaders / spinners like this, similar idea.
reticulating spines...
kicking llama's ass...
Re: 200 Milliseconds
#48is it bad that while this does look like a really cool method to explain a complex topic, my instinct on reading mic-droppy, RLHF AI prose is to be dismissive? there's just something about the persistent mic drops and this-not-that writing that feels so cheap
I think it's because the explainer is passive, there's no interiority, it tells and doesn't show. plus, stylistically, if this were rewritten in second person (like most explainers are) it would make it a heck of a lot more readable:
'You order a coffee on your coffee shop's tablet. 211.4 ms later you see 'Order Confirmed'.
There's a world of complexity behind that status confirmation. Let's see how it all works.' etc
Re: 200 Milliseconds
#49So why does it take 5-10 seconds from card presented to accepted at Starbucks and CVS?
Usually the dominant time is from POS to acceptor. These are frequently still on high latency links.
Also a lot of times in person payment flows allow a lot more in their latency budget because it won’t impact the sale, you won’t walk out because of a second here or there, unlike online.
So systems aren’t as optimized, they route to older systems, marketing or further risk checks are added, and a broader range of accepted services that have higher latency (ent/snap processors and the like).
Re: 200 Milliseconds
#50 > A problem repeatedly occurred on "https://200ms.thenodebook.com/#act-O-prologue”