TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Computer Latency: 1977-2017

244 点作者 2pEXgD0fZ5cF超过 2 年前

26 条评论

haberman超过 2 年前
When I saw this page a few years back I had an idea for a project. I want to create the lowest-latency typing terminal I possibly can, using an FPGA and an LED array. My initial results suggest that I can drive a 64x32 pixel LED array at 4.88kHz, for a roughly 0.2ms latency.<p>For the next step I want to make it capable of injecting artificial latency, and then do A&#x2F;B testing to determine (1) the smallest amount of latency I can reliably perceive, and (2) the smallest amount of latency that actually bothers me.<p>This idea was also inspired by this work from Microsoft Research, where they do a similar experiment with touch screens: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vOvQCPLkPt4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vOvQCPLkPt4</a>
评论 #33689620 未加载
评论 #33694603 未加载
评论 #33688276 未加载
评论 #33688954 未加载
评论 #33687482 未加载
gtrevorjay超过 2 年前
An anecdote that will probably sway no one: was in a family friendly barcade and noticed-- inexplicably--a gaggle of kids, all 8-14, gathered around the Pong. Sauntering up so I could overhear their conversation, it was all excited variants of &quot;It&#x27;s just a square! But it&#x27;s real!&quot;,&quot;You&#x27;re touching it!&quot;, or &quot;The knobs <i>really</i> move it.&quot;<p>If you wonder why we no long we have &quot;twitch&quot; games, this is why. Old school games had a tactile aesthetic lost in the blur of modern lag.
评论 #33688857 未加载
评论 #33690870 未加载
veloxo超过 2 年前
FWIW, a quick ballpark test shows &lt;30 ms minimum keyboard latency on my M1 Max MacBook, which has a 120-hz display.<p><pre><code> Sublime Text: 17–29 ms iTerm (zsh4humans): 25–54 ms Safari address bar: 17–38 ms TextEdit: 25–46 ms </code></pre> Method: Record 240-fps slo-mo video. Press keyboard key. Count frames from key depress to first update on screen, inclusive. Repeat 3x for each app.
评论 #33686883 未加载
评论 #33687376 未加载
amluto超过 2 年前
I wonder if a compositor, and possibly an entire compositing system designed around adaptive sync could perform substantially better than current compositors.<p>Currently, there is a whole pile of steps to update a UI. The input system processes an event, some decision is made as to when to rerender the application, then another decision is made as to when to composite the screen, and hopefully this all finishes before a frame is scanned out, but not too far before, because that would add latency. It’s heuristics all the way down.<p>With adaptive sync, there is still a heuristic decision as to whether to process an input event immediately or to wait to aggregate more events into the same frame. But once that is done, an application can update its state, redraw itself, and trigger an <i>immediate</i> compositor update. The compositor will render as quickly as possible, but it doesn’t need to worry about missing scanout — scanout can begin as soon as the compositor finishes.<p>(There are surely some constraints on the intervals between frames sent to the display, but this seems quite manageable while still scanning out a frame immediately after compositing it nearly 100% of the time.)
评论 #33692159 未加载
评论 #33684470 未加载
评论 #33684628 未加载
preinheimer超过 2 年前
Global Ping Data - <a href="https:&#x2F;&#x2F;wondernetwork.com&#x2F;pings" rel="nofollow">https:&#x2F;&#x2F;wondernetwork.com&#x2F;pings</a><p>We&#x27;ve got servers in 200+ cities around the world, and ask them to ping each other every hour. Currently it takes our servers in Tokyo and London about 226ms to ping each other.<p>We&#x27;ve got some downloadable datasets here if you want to play with them: <a href="https:&#x2F;&#x2F;wonderproxy.com&#x2F;blog&#x2F;a-day-in-the-life-of-the-internet&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wonderproxy.com&#x2F;blog&#x2F;a-day-in-the-life-of-the-intern...</a>
评论 #33685791 未加载
评论 #33685634 未加载
评论 #33688661 未加载
评论 #33688070 未加载
johnklos超过 2 年前
I recently had some free time and used it to finish fixing up an Amiga 3000 (recapping the motherboard, repairing some battery damage on the motherboard). I installed AmigaDOS 3.2.1 and started doing things with it like running a web browser and visiting modern web sites.<p>The usability is worlds better than what we have now, even comparing a 1990 computer with a 25 MHz m68030 and 16 megs of memory with a four core, eight thread Core i7 with 16 gigs of memory. Interestingly, the 1990 computer can have a datatype added which allows for webp processing, whereas the Mac laptop running the latest Safari available for it can&#x27;t do webp.<p>We&#x27;ve lost something, and even when we&#x27;re aware of it, that doesn&#x27;t mean we can get it back.
still_grokking超过 2 年前
Previous discussions:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25290118" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25290118</a> (December 3, 2020 — 454 points, 259 comments)<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16001407" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16001407</a> (December 24, 2017 — 588 points, 161 comments)
评论 #33690893 未加载
FartyMcFarter超过 2 年前
Going through the list of what happens on iOS:<p>&gt; UIKit introduced 1-2 ms event processing overhead, CPU-bound<p>I wonder if this is correct, and what&#x27;s happening there if so - a modern CPU (even a mobile one) can do a <i>lot</i> in 1-2 ms. That&#x27;s 6 to 12% of the per-frame budget of a game running at 60 fps, which is pretty mind-boggling for just processing an event.
评论 #33683832 未加载
Smoosh超过 2 年前
Has anyone else used an IBM mainframe with a hardware 327x terminal?<p>They process all normal keystrokes locally, and only send back to the host when Enter and function keys are pressed. This means very low latency for typing and most keystrokes. But much longer latency when you press enter, or page up&#x2F;down as the mainframe then processes all the on-screen changes and sends back the refreshed screen (yes, you are looking at a page at a time, there is no scrolling).<p>Of course, these days people use emulators instead of hardware terminals so you get the standard GUI delays and the worst of both worlds.
pjkundert超过 2 年前
Using emacs on an SGI Iris in 1988 was … sublime.<p>Every computer systems since then has been a head shaking disappointment, latency-wise.
walrus01超过 2 年前
Something I recently observed is that cutting edge, current generation gaming-marketed x86-64 motherboards for single socket CPUs, both Intel and AMD, still come with a single PS&#x2F;2 mouse port on the rear I&#x2F;O plate.<p>I read something about this being intended for use with high end wired gaming mice, where the end to end latency between mouse and cursor movement is theoretically lower if the signal doesn&#x27;t go through the USB bus on the motherboard, but rather through whatever legacy PS&#x2F;2 interface is talking to the equivalent-of-northbridge chipset.
评论 #33686572 未加载
userbinator超过 2 年前
I&#x27;d like to see older MS-DOS and Windows on there for comparison; I remember dualbooting 98se and XP for a while in the early 2000s and the former was noticeably more responsive.<p>Another comparative anecdote I have is between Windows XP and OS X on the same hardware, wherein the latter was less responsive. After seeing what GUI apps on a Mac actually involve, I&#x27;m not too surprised: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11638367" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11638367</a>
评论 #33687894 未加载
drewtato超过 2 年前
Powershell isn&#x27;t a terminal (it&#x27;s a shell, obviously), so the windows results are most likely tested in conhost. If it&#x27;s on windows 11 it might be windows terminal, which may be more likely since I think cmd is still default on windows 10.
评论 #33685586 未加载
giantdude超过 2 年前
I always thought that Apple ][ + was as good as it gets. It&#x27;s been downhill from there, for Apple and for the rest of us.
评论 #33685182 未加载
评论 #33685646 未加载
shpx超过 2 年前
iPads predict user input <a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;uikit&#x2F;touches_presses_and_gestures&#x2F;handling_touches_in_your_view&#x2F;minimizing_latency_with_predicted_touches" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;uikit&#x2F;touches_pres...</a> . Did they do this back when this article was written or is this a newer thing that lets them get to even lower user perceived latencies than 30ms?<p>In general, predicting user input to reduce latency is a great idea and we should do more of it, as long as you have a good system for rolling back mispredictions. Branch prediction is such a fundamental thing for CPUs that it&#x27;s surprising to me that it doesn&#x27;t exist at every level of computing. The JavaScript REPL&#x27;s (V8&#x27;s REPL) &quot;eager evaluation&quot; where it shows you the result of side-effect free expressions before you execute them is the kind of thing I&#x27;m thinking about <a href="https:&#x2F;&#x2F;developer.chrome.com&#x2F;blog&#x2F;new-in-devtools-68&#x2F;#eagerevaluation" rel="nofollow">https:&#x2F;&#x2F;developer.chrome.com&#x2F;blog&#x2F;new-in-devtools-68&#x2F;#eagere...</a>
fnordpiglet超过 2 年前
Yet more proof we should have just stopped with the SGI Indy
ksec超过 2 年前
There is hardware input ( Keyboard and mouse ) latency as well as output like display latency. Unfortunately the market, and industry as a whole doesn&#x27;t care about latency at all.<p>While I am not a fan or proponent of AR &#x2F; VR. One thing that will definitely be an issue is latency. Hopefully there will be enough incentive for companies to look into it.
sovietswag超过 2 年前
Isn&#x27;t this experiment a bit bogus? Extrapolating a terminal emulator&#x27;s behavior to represent a machine&#x27;s latency &#x2F;in general&#x2F;... what if the terminal emulator just sucks? Dan Luu is of course aware of this but he&#x27;s willing to swallow it as noise:<p>&gt; Computer results were taken using the “default” terminal for the system (e.g., powershell on windows, lxterminal on lubuntu), which could easily cause 20 ms to 30 ms difference between a fast terminal and a slow terminal.<p>If that was the only source of noise in the measurements then ok, maybe, but compounded with other stuff? For example, I was thinking: the more time passes, the further we drift from the command-line being the primary interface through which we interact with our computer. So naturally older computers would take more care in optimizing their terminal emulator to work well, as it&#x27;s the face of the computer, right? Somebody&#x27;s anecdote about PowerShell performance in this thread makes me feel more comfortable assuming that maybe modern vendors don&#x27;t care so much about terminal latency.<p>Using the &quot;default browser&quot; as the metric for mobile devices worries me even more...<p>I like Dan Luu and I SupportThismessage™ but I feel funny trying to take anything away from this post...
ngcc_hk超过 2 年前
Should it be personal computer latency.<p>Wonder about hat as we just talked about the importance of sub-second response time in 1990s (full screen 3270 after hitting enter; even if no ims or db2 how can it be done …). The terminal keyboard response is fine (on 3270). Network (sna) …<p>1977 still have mainframe and workstation.
nikanj超过 2 年前
On my state-of-the-art desktop PC, Visual Studio has very noticeable cursor&amp;scrolling lag. My C64 had the latter as well, but I used to assume the cursor moved as fast as I could type &#x2F; tap the arrow keys
killjoywashere超过 2 年前
I really found this valuable, particularly the slide at the top that enables you to visualize low level latency times (Jeff Dean numbers) over the years. tl;dr: not much has changed in the processor hardware numbers since 2012. So everything right of the processor is where the action is. And sounds like people are starting to actually make progress.<p><a href="https:&#x2F;&#x2F;colin-scott.github.io&#x2F;personal_website&#x2F;research&#x2F;interactive_latency.html" rel="nofollow">https:&#x2F;&#x2F;colin-scott.github.io&#x2F;personal_website&#x2F;research&#x2F;inte...</a>
wodenokoto超过 2 年前
I didn’t quite catch why we have 2.5 frames of latency and not just up to one frame of latency.
egberts1超过 2 年前
So much added sluggishness and they still cannot bring themselves to show us a current dynamic keyboard mapping to this day.
评论 #33684225 未加载
JoeAltmaier超过 2 年前
I wonder how this was all measured.<p>I didn&#x27;t dig into the text blob to ferret that out.<p>Did anybody?<p>Because this doesn&#x27;t pass the sniff test for data I want to trust
评论 #33687816 未加载
LastTrain超过 2 年前
That is because latency on it&#x27;s own is an often useless metric.
still_grokking超过 2 年前
Cynic comment ahead, beware!<p>---<p>Does this actually even matter today when every click or key-press triggers dozens of fat network request going around the globe on top of a maximally inefficient protocol?<p>Or to summarize what we see here: We&#x27;ve build layers of madness. Now we have just to deal with the fallout…<p>The result is in no way surprising given we haven&#x27;t refactored our systems for over 50 years and just put new things on top.
评论 #33683990 未加载
评论 #33684463 未加载