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

91–100 of 114 posts

Re: 200 Milliseconds

#91

Post by rcxdude »

Method5440 wrote: post #79

“On the wire, each label is stored with its length in front, 3 api 11 thenodebook 3 com 0, and the final 0 marks the end of the name, where the last dot would go.” Am I the only one that doesn’t think of this as ‘api.thenodebook.com.’? What does the LLM mean by the zero after .com marking where the last dot would go?

The last '.' is essentially the equivalent of the first '/' in a file path: it refers to the root of the DNS and marks it as an absolute name (otherwise, in principle, it could be treated as relative even though it usually is not outside of the DNS machinery).

Re: 200 Milliseconds

#92

Post by rcxdude »

fragmede wrote: post #45
ahofmann wrote: post #15

Earlier quoted context omitted.

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.

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.

Re: 200 Milliseconds

#93

Post by dilyevsky »

> Its addresses are MAC addresses, serial numbers burned into each card at the factory.

oof

Nice idea, but execution could be better - way too many factual errors. Actually, considering it appears to be just 100% ai slop it's a little bit shocking how many just plain wrong statements it put out. Almost every section is at least a little bit off...

Re: 200 Milliseconds

#94

Post by fragmede »

rcxdude wrote: post #92
fragmede wrote: post #45

Earlier quoted context omitted.

Not for everyone, but most people are located in population centers with nearby PoPs.

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.

Re: 200 Milliseconds

#95

Post by bulder »

stratts wrote: post #60
foolswisdom wrote: post #42

Earlier quoted context omitted.

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

Codex does this too, I've noticed. LLMs seem to love documenting irrelevant implementation details in what should be user-facing text. I guess because the context is overwhelmingly the technical side of things, so without a later directive to steer it, that's what's most likely to come out.

The user-facing string stuff is definitely the thing that drives me the most nuts. I guess it's nice that it defaults to gag-inducingly transparent, but I don't think the backend structure should be written out in the title element of the app.

Re: 200 Milliseconds

#96

Post by jvuygbbkuurx »

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 printing the receipt.

I always wonder how it was so fast and if it was just some random dev optimising some obscure edge case.

Re: 200 Milliseconds

#97

Post by mrheosuper »

omgtehlion wrote: post #90
mrheosuper wrote: post #83

Earlier quoted context omitted.

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

I see, but the path from hardware to userspace app should remain unchange, right ?

Re: 200 Milliseconds

#99

Post by aa-jv »

zahlman wrote: post #5
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."

I learned three thresholds over the years. Well, one of them decades ago and the others recently. Basically: At 50ms, you notice. At 400ms, you care. At 2000ms, without output, you wonder if it crashed. (That was the old one.)

In the audio/synth world, the lower bound is 8ms, as in, anything above this can become bothersome to the musician. I've heard it stated that this is also the threshold for fighter pilot control systems providing feedback.

Re: 200 Milliseconds

#100

Post by rockmeamedee »

I hate this. The style of LLM-written prose is unbearable, and I found several mistakes. This is "dazzle them with bullshit details" with no understanding behind it.

I assume the book this post is marketing is also AI slop too and I lost respect for its author.

Post reply on HN