Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

200 Milliseconds

200ms.thenodebook.com

Post reply on HN
Print view View original

101–110 of 114 posts

Re: 200 Milliseconds

#101

Post by LtdJorge »

fragmede wrote: post #94
rcxdude wrote: post #92

Earlier quoted context omitted.

Yeah, but you would need to run an API server in each of those to reach that latency, and even then you're well into eventually-consistent distributed system headache if you accept the POST without synchronising with all the others first.

You terminate SSL (err, TLS) at the pop so the clients TCP connection gets setup faster, and then you use a hot TCP connection from the pop to a centralized API server. That gets you not having to deal with the headache of running a distributed system but a better experience for the client.

And you still have to send your light pulses through a fiber over thousands of kilometers, so 50ms is still physically impossible.

Re: 200 Milliseconds

#102

Post by josters »

paimapi wrote: post #48

is 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 (…

Thank you for putting into words how a lot of AI prose makes me feel. 'Persistent mic drops' is the most accurate way I have seen it described and I would even argue the 'this-not-that writing' is part of it. Setting up a chain of ever increasing seemingly powerful phrases to then conclude in a final statement which may or may not actually explain the core concept.

It also made me think of the Feynman Learning Technique[1] or learning by teaching in general: being able to accurately explain in simple terms requires to fully grasp the concept and noticing gaps in the explanation is an insight to the explainer to evaluate and understand those parts again at a deeper level. An AI arguably does not have this understanding and will happily drive home any point we have asked it to make.

In a way I think it's tied to the other discussion from today[2] where it was posited that domain knowledge makes you better at prompting LLMs and, consequently, would enable you to also better structure and evaluate explainers. But then again, explaining well is a different skill altogether.

[1]: https://en.wikipedia.org/wiki/Learning_by_teaching#Plastic_p... [2]: https://news.ycombinator.com/item?id=49161518

Re: 200 Milliseconds

#103

Post by jonathanlydall »

jvuygbbkuurx wrote: post #96
felooboolooomba wrote: post #2

> The person who clicked noticed no delay. Just to be the "actually..." guy: People notice 200ms delay. It's just that in cases it doesn't cause any bad feelings."

Indeed. But there are also delays that cause good feelings. I still remember the POS in my previous employers cafeteria. It had something like 100-200ms delay in processing a contactless payment card. It felt like an order of magnitude faster than any grocery store (exact same POS device). It was always very satisfying to pay for lunch. By the time you brought the card to the reader it felt like it was already printi…

In South Africa I notice this difference all the time where the big supermarket chains seem to be near instantaneous while small stores are 10+ seconds.

I'm certain it's because the big store's card machines have a wired network connection to a router with a fibre connection, while most smaller shops just use card machines with integrated GPRS wireless modems as they even show feedback about connecting as you tap your card.

A stall vendor who I use somewhat regularly warned me one time that her card machine was down (I guess some kind of maintenance as it was earlyish on a Sunday morning) so would only be able to accept cash. I helped her put the card machine on a nearby shop's free WiFi and not only did it work around the problem, but it made card transactions going forward significantly faster.

Re: 200 Milliseconds

#104

Post by jonathanlydall »

jonahrd wrote: post #14

Am 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?

For one of the supermarket chains I frequent, from me handing over the single item I'm purchasing I can be walking away within 20s. They scan the item, then a loyalty barcode on my phone and finally I tap my iPhone which has my bank card loaded onto it.

Basically, they don't have any significant bottlenecks, POS hardware + software is responsive with an efficient UI for the operator, and the card machine is a wired connection to a router with a fibre uplink.

Re: 200 Milliseconds

#105

Post by samlinnfer »

sriram_malhar wrote: post #66
samlinnfer wrote: post #63

Earlier quoted context omitted.

Not really, jealous is defined as envious (being envious is one of the definitions of being jealous). For common usage they are equivalent, e.g. I'm jealous of X is the same as I'm envious of X.

They may be equivalent in common parlance, but that’s a bit like saying it is ok to use ‘your’ instead of “you’re” just because it is so common. We say “jealously guarded’ not ‘enviously guarded’ for a reason. Jealousy is about being protective of your own possessions and relationships; you feel jealousy if your spouse responds well to a coworker’s flirtations. Envy is when you find think of the coworker’s luck in ha…

https://www.merriam-webster.com/dictionary/jealous

1: hostile toward a rival or one believed to enjoy an advantage : envious

>His success made his old friends jealous.

>They were jealous of his success.

I rest my case.

Re: 200 Milliseconds

#106

Post by cloverich »

I'm surprised at all the "200ms is slow" comments. I make many purchases online, don't we all? I can't remember the last time one took sub 1000ms; they usually take several. What are some of the websites you purchase from that truly complete a purchase in sub-200ms?

Re: 200 Milliseconds

#107

Post by advisedwang »

felooboolooomba wrote: post #2

> The person who clicked noticed no delay. Just to be the "actually..." guy: People notice 200ms delay. It's just that in cases it doesn't cause any bad feelings."

Users know to expect different things at different speeds, and have come to expect the actual "buy" button to be slow. 200ms is pretty fast for that, tbf

Re: 200 Milliseconds

#108

Post by zahlman »

Aurornis wrote: post #10
p-e-w wrote: post #6

Earlier 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.

The timing refers to feeling like the device acknowledged your request with some response. Not seeing the final completion of the request. Your phone probably showed something after you clicked the link but before the page rendered: Link highlight change, a progress bar, etc. If your phone had crashed and the browser was non-responsive, you would have recognized it quickly. More quickly than the page load time.

Yes, exactly what I meant. (FWIW, the original context was J2ME mobile games. It was important to use as few classes as possible to keep JAR size down; but in my testing, everything put into the entry-point class had to be loaded before the program would get past an initial black screen.)

Re: 200 Milliseconds

#109

Post by ksec »

jvuygbbkuurx wrote: post #96
felooboolooomba wrote: post #2

> The person who clicked noticed no delay. Just to be the "actually..." guy: People notice 200ms delay. It's just that in cases it doesn't cause any bad feelings."

Indeed. But there are also delays that cause good feelings. I still remember the POS in my previous employers cafeteria. It had something like 100-200ms delay in processing a contactless payment card. It felt like an order of magnitude faster than any grocery store (exact same POS device). It was always very satisfying to pay for lunch. By the time you brought the card to the reader it felt like it was already printi…

May be your cafeteria was doing offline processing, while other were doing it online?

But even offline there are huge differences, say Visa / Mastercard EMV and Suicia's Felica in Japan, where the whole transaction finish in 150ms.

There were previously some work where they try to get it down to 50ms, I don't know if they are still working on it or has abandoned it.

Re: 200 Milliseconds

#110

Post by hex4def6 »

mrheosuper wrote: post #82
hex4def6 wrote: post #69

>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

You're right the kernel might be able to handle that pretty quickly, but I know from experience even good, ~200Hz sampling captouch system is 1/200 = 5ms worst case, 2.5ms avg. That's already 2.5-5x the budget and we haven't gotten off the display.
Post reply on HN