The website is barely readable on my shitty screen.
200 Milliseconds
81–90 of 114 posts
Re: 200 Milliseconds
#82>touchpad controller >capacitance dip → interrupt raised >hid driver report: x 512 · y 288 · button 1 down >... >One millisecond in, the click has passed through four pieces of software and nothing has left the laptop. I'm going to press X to doubt. There's no way you're getting from "finger touching glass" -> "chrome seeing a click" in one millisecond. Heck, I know for a fact that even the cap touch controller isn't…
1ms latency is too much for RTOS, from ISR to the app code should be less than 1ms
but bloated OS ? i have no idea
Re: 200 Milliseconds
#83I'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.
chrome can detect my 1000hz polling mouse, but i bet there must be a buffer somewhere.
Re: 200 Milliseconds
#84Am 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?
I agree that purchases on e-commerce sites are virtually never this fast; but I have used some extremely fast physical payment terminals (e.g., Square): sometimes it seems like the transaction is sub 300ms, which I find very impressive given the complexity of payment processing.
Re: 200 Milliseconds
#85Earlier quoted context omitted.
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).
Absolutely, makes my blood boil. Claude proposes an obviously wrong/overengineered solution to a problem. I come up with a better approach and we agree to do that instead. Every step of the way, Claude leaves code comments with long-winded explanations of how we're doing X instead of doing $insane_thing.
Literally # This method rejects splines that can't be reticulated. This helps us avoid murdering puppies and punching a baby in the face.
Re: 200 Milliseconds
#86is 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 (…
No, this site is awful.
You read this sentence:
>This website shows what happened in between.
And immediately get shown an ad "how to build a backend framework from the wire up".
The first thing you think to yourself is how does building a backend relate to a coffeeshop click? Why would you even have to click in a coffee shop in the first place? If you really insist on product placement, why not explain how your order page works instead?
"the rules of this page" is a terrible wall of text that expects you to read carefully and memorize instead of using the scroll mechanism itself to show the clock in the center of the screen and then move it with a fluid animation to the top, so you notice it is there. Same problem problem with the time stop. You have to introduce the time stop mechanic as you go.
"the cast" is terrible yet again, you've primed me to expect the clock to start and I scroll through the request and nothing happens??? Why emphasize the infrastructure at the end with text? Why are there six requests? You only need one HTTP request/reply and TCP does not have the concept of requests. The packet round trips created by TCP/TLS handshakes do not count as multiple requests. This explainer feels wrong from a technical perspective already .
Then there is the fact that the text columns are incredibly thin with heavy vertical separation, there's an incredible waste of horizontal and vertical space to the point where you hardly get to read anything at all. You can divide the screen into 9 rectangles and only one of those is used. 90% of the screen is empty.
It also keeps jumping from single column, to double column to single double column (yes) and left bound text.
Not only does it not hook me, I'm having a hard time believing that the creator of this actually looked at the output or iterated on it at all.
Re: 200 Milliseconds
#87I don’t know how much a human was involved in making this, but clearly not enough. Some parts of the timing it’s talking about make no sense, the ordering of some parts is incoherent, and it promptly goes into unreasonable and irrelevant detail while completely missing other actually relevant aspects of that detail. For example, “HSTS preload”: it’s utterly irrelevant, because you already know it’s HTTPS; and even if…
I looked at the beginning and it is already wrong. It talks about multiple requests and when you go all the way to the end, it suddenly talks about a single request.
Re: 200 Milliseconds
#88200 ms is very slow.
Re: 200 Milliseconds
#89Wow, input lag is a lot lower than I thought. I thought it was a polling-based flow at some 120 Hz roughly. Good to update these numbers.
You actually should not, usual (non-gaming) mice still do the same (most touchpads in cheap laptops even slower, they share already slow i2c bus with several other endpoints), and the article ignores drivers and the UI stack altogether.
Re: 200 Milliseconds
#90I'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.
chrome can detect my 1000hz polling mouse, but i bet there must be a buffer somewhere.
recent chrome versions actually throttle these reports down to 60hz max, checked this on several systems and mice