By comparison, on the Apple 2e, there basically aren\u2019t handoffs, locks, or process boundaries. Some very simple code runs and writes the result to the display memory, which causes the display to get updated on the next scan.<\/p>\n

Refresh rate vs. latency<\/h3>\n

One thing that\u2019s curious about the computer results is the impact of refresh rate. We get a 90 ms<\/code> improvement from going from 24 Hz<\/code> to 165 Hz<\/code>. At 24 Hz<\/code> each frame takes 41.67 ms<\/code> and at 165 Hz<\/code> each frame takes 6.061 ms<\/code>. As we saw above, if there weren\u2019t any buffering, we\u2019d expect the average latency added by frame refreshes to be 20.8ms<\/code> in the former case and 3.03 ms<\/code> in the latter case (because we\u2019d expect to arrive at a uniform random point in the frame and have to wait between 0ms<\/code> and the full frame time), which is a difference of about 18ms<\/code>. But the difference is actually 90 ms<\/code>, implying we have latency equivalent to (90 - 18) \/ (41.67 - 6.061) = 2<\/code> buffered frames.<\/p>\n

If we plot the results from the other refresh rates on the same machine (not shown), we can see that they\u2019re roughly in line with a \u201cbest fit\u201d curve that we get if we assume that, for that machine running powershell, we get 2.5 frames worth of latency regardless of refresh rate. This lets us estimate what the latency would be if we equipped this low latency gaming machine with an infinity Hz<\/code> display — we\u2019d expect latency to be 140 - 2.5 * 41.67 = 36 ms<\/code>, almost as fast as quick but standard machines from the 70s and 80s.<\/p>\n

Complexity<\/h3>\n

Almost every computer and mobile device that people buy today is slower than common models of computers from the 70s and 80s. Low-latency gaming desktops and the ipad pro<\/code> can get into the same range as quick machines from thirty to forty years ago, but most off-the-shelf devices aren\u2019t even close.<\/p>\n

If we had to pick one root cause of latency bloat, we might say that it\u2019s because of \u201ccomplexity\u201d. Of course, we all know that complexity is bad. If you\u2019ve been to a non-academic non-enterprise tech conference in the past decade, there\u2019s a good chance that there was at least one talk on how complexity is the root of all evil and we should aspire to reduce complexity.<\/p>\n

Unfortunately, it’s a lot harder to remove complexity than to give a talk saying that we should remove complexity. A lot of the complexity buys us something, either directly or indirectly. When we looked at the input of a fancy modern keyboard vs. the apple 2<\/code> keyboard, we saw that using a relatively powerful and expensive general purpose processor to handle keyboard inputs can be slower than dedicated logic for the keyboard, which would both be simpler and cheaper. However, using the processor gives people the ability to easily customize the keyboard, and also pushes the problem of \u201cprogramming\u201d the keyboard from hardware into software, which reduces the cost of making the keyboard. The more expensive chip increases the manufacturing cost, but considering how much of the cost of these small-batch artisanal keyboards is the design cost, it seems like a net win to trade manufacturing cost for ease of programming.<\/p>\n

We see this kind of tradeoff in every part of the pipeline. One of the biggest examples of this is the OS you might run on a modern desktop vs. the loop that\u2019s running on the apple 2<\/code>. Modern OSes let programmers write generic code that can deal with having other programs simultaneously running on the same machine, and do so with pretty reasonable general performance, but we pay a huge complexity cost for this and the handoffs involved in making this easy result in a significant latency penalty.<\/p>\n

A lot of the complexity might be called accidental complexity<\/a>, but most of that accidental complexity is there because it\u2019s so convenient. At every level from the hardware architecture to the syscall interface to the I\/O framework we use, we take on complexity, much of which could be eliminated if we could sit down and re-write all of the systems and their interfaces today, but it\u2019s too inconvenient to re-invent the universe to reduce complexity and we get benefits from economies of scale, so we live with what we have.<\/p>\n

For those reasons and more, in practice, the solution to poor performance caused by \u201cexcess\u201d complexity is often to add more complexity. In particular, the gains we\u2019ve seen that get us back to the quickness of the quickest machines from thirty to forty years ago have come not from listening to exhortations to reduce complexity, but from piling on more complexity.<\/p>\n

The ipad pro<\/code> is a feat of modern engineering; the engineering that went into increasing the refresh rate on both the input and the output as well as making sure the software pipeline doesn\u2019t have unnecessary buffering is complex! The design and manufacture of high-refresh-rate displays that can push system latency down is also non-trivially complex in ways that aren\u2019t necessary for bog standard 60 Hz<\/code> displays.<\/p>\n

This is actually a common theme when working on latency reduction. A common trick to reduce latency is to add a cache, but adding a cache to a system makes it more complex. For systems that generate new data and can\u2019t tolerate a cache, the solutions are often even more complex. An example of this might be large scale RoCE deployments<\/a>. These can push remote data access latency from from the millisecond range down to the microsecond range, which enables new classes of applications<\/a>. However, this has come at a large cost in complexity. Early large-scale RoCE deployments easily took tens of person years of effort to get right and also came with a tremendous operational burden.<\/p>\n

Conclusion<\/h3>\n

It\u2019s a bit absurd that a modern gaming machine running at 4,000x<\/code> the speed of an apple 2<\/code>, with a CPU that has 500,000x<\/code> as many transistors (with a GPU that has 2,000,000x<\/code> as many transistors) can maybe manage the same latency as an apple 2<\/code> in very carefully coded applications if we have a monitor with nearly 3x<\/code> the refresh rate. It\u2019s perhaps even more absurd that the default configuration of the powerspec g405<\/code>, which had the fastest single-threaded performance you could get until October 2017, had more latency from keyboard-to-screen (approximately 3 feet<\/code>, maybe 10 feet<\/code> of actual cabling) than sending a packet around the world (16187 mi<\/code> from NYC to Tokyo to London back to NYC, more due to the cost of running the shortest possible length of fiber).<\/p>\n

On the bright side, we\u2019re arguably emerging from the latency dark ages and it\u2019s now possible to assemble a computer or buy a tablet with latency that\u2019s in the same range as you could get off-the-shelf in the 70s and 80s. This reminds me a bit of the screen resolution & density dark ages, where CRTs from the 90s offered better resolution and higher pixel density than affordable non-laptop LCDs until relatively recently. 4k displays have now become normal and affordable 8k displays are on the horizon, blowing past anything we saw on consumer CRTs. I don\u2019t know that we\u2019ll see the same kind improvement with respect to latency, but one can hope. There are individual developers improving the experience for people who use certain, very carefully coded, applications, but it’s not clear what force could cause a significant improvement in the default experience most users see.<\/p>\n

Other posts on latency measurement<\/h3>\n

\n
• Terminal latency<\/a><\/li>\n
• Keyboard latency<\/a><\/li>\n
• Mouse vs. keyboard latency<\/a> (human factors, not device latency)<\/li>\n
• Editor latency<\/a> (by Pavel Fatin)<\/li>\n
• Windows 10 compositing latency<\/a> (by Pekka Vaananen)<\/li>\n
• AR\/VR latency<\/a> (by Michael Abrash)<\/li>\n
• Latency mitigation strategies<\/a> (by John Carmack)<\/li>\n<\/ul>\n

  Appendix: why measure latency?<\/h3>\n

  Latency matters! For very simple tasks, people can perceive latencies down to 2 ms<\/code> or less<\/a>. Moreover, increasing latency is not only noticeable to users, it causes users to execute simple tasks less accurately<\/a>. If you want a visual demonstration of what latency looks like and you don\u2019t have a super-fast old computer lying around, check out this MSR demo on touchscreen latency<\/a>.<\/p>\n

  The most commonly cited document on response time is the nielsen group article on response times, which claims that latncies below 100ms<\/code> feel equivalent and perceived as instantaneous. One easy way to see that this is false is to go into your terminal and try sleep 0; echo "pong"<\/code> vs. sleep 0.1; echo "test"<\/code> (or for that matter, try playing an old game that doesn’t have latency compensation, like quake 1, with 100 ms<\/code> ping, or even 30 ms<\/code> ping, or try typing in a terminal with 30 ms<\/code> ping). For more info on this and other latency fallacies, see this document on common misconceptions about latency<\/a>.<\/p>\n

  Throughput<\/a> also matters, but this is widely understood and measured. If you go to pretty much any mainstream review or benchmarking site, you can find a wide variety of throughput measurements, so there\u2019s less value in writing up additional throughput measurements.<\/p>\n

  Appendix: apple 2 keyboard<\/h3>\n

  The apple 2e<\/code>, instead of using a programmed microcontroller to read the keyboard, uses a much simpler custom chip designed for reading keyboard input, the AY 3600. If we look at the AY 3600 datasheet<\/a>,we can see that the scan time is (90 * 1\/f)<\/code> and the debounce time is listed as strobe_delay<\/code>. These quantities are determined by some capacitors and a resistor, which appear to be 47pf<\/code>, 100k ohms<\/code>, and 0.022uf<\/code> for the Apple 2e. Plugging these numbers into the AY3600 datasheet<\/a>, we can see that f = 50 kHz<\/code>, giving us a 1.8 ms<\/code> scan delay and a 6.8 ms<\/code> debounce delay (assuming the values are accurate — capacitors can degrade over time<\/a>, so we should expect the real delays to be shorter on our old Apple 2e), giving us less than 8.6 ms<\/code> for the internal keyboard logic.<\/p>\n

  Comparing to a keyboard with a 167 Hz<\/code> scan rate that scans two extra times to debounce<\/a>, the equivalent figure is 3 * 6 ms = 18 ms<\/code>. With a 100Hz<\/code> scan rate, that becomes 3 * 10 ms = 30 ms<\/code>. 18 ms<\/code> to 30 ms<\/code> of keyboard scan plus debounce latency is in line with what we saw when we did some preliminary keyboard latency measurements<\/a>.<\/p>\n

  For reference, the ergodox uses a 16 MHz<\/code> microcontroller with ~80k transistors and the apple 2e<\/code> CPU is a 1 MHz<\/code> chip with 3.5k transistors.<\/p>\n

  Appendix: why should android phones have higher latency than old apple phones?<\/h3>\n

  As we’ve seen, raw processing power doesn’t help much with many of the causes of latency in the pipeline, like handoffs between different processes, so phones that an android phone with a 10x more powerful processor than an ancient iphone isn’t guaranteed to be quicker to respond, even if it can render javascript heavy pages faster.<\/p>\n

  If you talk to people who work on non-Apple mobile CPUs, you’ll find that they run benchmarks like dhrystone (a synthetic benchmark that was irrelevant even when it was created, in 1984) and SPEC2006 (an updated version of a workstation benchmark that was relevant in the 90s and perhaps even as late as the early 2000s if you care about workstation workloads, which are completely different from mobile workloads). This problem where the vendor who makes the component has an intermediate target<\/a> that’s only weakly correlated to the actual user experience. I’ve heard that there are people working on the pixel phones who care about end-to-end latency, but it’s difficult to get good latency when you have to use components that are optimized for things like dhrystone and SPEC2006.<\/p>\n

  If you talk to people at Apple, you’ll find that they’re quite cagey, but that they’ve been targeting the end-to-end user experience for quite a long time and they they can do “full stack” optimizations that are difficult for android vendors to pull of. They’re not literally impossible, but making a change to a chip that has to be threaded up through the OS is something you’re very unlikely to see unless google is doing the optimization, and google hasn’t really been serious about the end-to-end experience until recently.<\/p>\n

  Having relatively poor performance in aspects that aren’t measured is a common theme and one we saw when we looked at terminal latency<\/a>. Prior to examining temrinal latency, public benchmarks were all throughput oriented and the terminals that priortized performance worked on increasing throughput, even though increasing terminal throughput isn’t really useful. After those terminal latency benchmarks, some terminal authors looked into their latency and found places they could trim down buffering and remove latency. You get what you measure.<\/p>\n

  Appendix: experimental setup<\/h3>\n

  Most measurements were taken with the 240fps camera (4.167 ms<\/code> resolution) in the iPhone SE<\/a>. Devices with response times below 40 ms<\/code> were re-measured with a 1000fps camera (1 ms<\/code> resolution), the Sony RX100 V<\/a> in PAL mode. Results in the tables are the results of multiple runs and are rounded to the nearest 10 ms<\/code> to avoid the impression of false precision. For desktop results, results are measured from when the key started moving until the screen finished updating. Note that this is different from most key-to-screen-update measurements you can find online, which typically use a setup that effectively removes much or all of the keyboard latency, which, as an end-to-end measurement, is only realistic if you have a psychic link to your computer (this isn’t to say the measurements aren’t useful — if, as a programmer, you want a reproducible benchmark, it’s nice to reduce measurement noise from sources that are beyond your control, but that’s not relevant to end users). People often advocate measuring from one of: {the key bottoming out, the tactile feel of the switch}. Other than for measurement convenience, there appears to be no reason to do any of these, but people often claim that’s when the user expects the keyboard to “really” work. But these are independent of when the switch actually fires. Both the distance between the key bottoming out and activiation as well as the distance between feeling feedback and activation are arbitrary and can be tuned. See this post on keyboard latency measurements for more info on keyboard fallacies<\/a>.<\/p>\n

  Another significant difference is that measurements were done with settings as close to the default OS settings as possible since approximately 0% of users will futz around with display settings to reduce buffering, disable the compositor, etc. Waiting until the screen has finished updating is also different from most end-to-end measurements do — most consider the update “done” when any movement has been detected on the screen. Waiting until the screen is finished changing is analogous to webpagetest’s “visually complete” time.<\/p>\n

  Computer results were taken using the \u201cdefault\u201d terminal for the system (e.g., powershell on windows, lxterminal on lubuntu), which could easily cause 20 ms<\/code> to 30 ms<\/code> difference between a fast terminal and a slow terminal<\/a>. Between measuring time in a terminal and measuring the full end-to-end time, measurements in this article should be slower than measurements in other, similar, articles (which tend to measure time to first change in games).<\/p>\n

  The powerspec g405<\/code> baseline result is using integrated graphics (the machine doesn\u2019t come with a graphics card) and the 60 Hz<\/code> result is with a cheap video card. The baseline was result was at 30 Hz<\/code> because the integrated graphics only supports hdmi<\/code> output and the display it was attached to only runs at 30 Hz<\/code> over hdmi<\/code>.<\/p>\n

  Mobile results were done by using the default browser, browsing to https:\/\/danluu.com<\/a>, and measuring the latency from finger movement until the screen first updates to indicate that scrolling has occurred. In the cases where this didn\u2019t make sense, (kindles, gameboy color, etc.), some action that makes sense for the platform was taken (changing pages on the kindle, pressing the joypad on the gameboy color in a game, etc.). Unlike with the desktop\/laptop measurements, this end-time for the measurement was on the first visual change to avoid including many frames of scrolling. To make the measurement easy, the measurement was taken with a finger on the touchscreen and the timer was started when the finger started moving (to avoid having to determine when the finger first contacted the screen).<\/p>\n

  In the case of \u201cties\u201d, results are ordered by the unrounded latency as a tiebreaker, but this shouldn\u2019t be considered significant. Differences of 10 ms<\/code> should probably also not be considered significant.<\/p>\n

  The custom haswell-e<\/code> was tested with gsync<\/code> on and there was no observable difference. The year for that box is somewhat arbitrary, since the CPU is from 2014<\/code>, but the display is newer (I believe you couldn\u2019t get a 165 Hz<\/code> display until 2015<\/code>.<\/p>\n

  The number of transistors for some modern machines is a rough estimate because exact numbers aren\u2019t public. Feel free to ping me if you have a better estimate!<\/p>\n

  The color scales for latency and year are linear and the color scales for clock speed and number of transistors are log scale.<\/p>\n

  All Linux results were done with a pre-KPTI<\/a> kernel. It’s possible that KPTI will impact user perceivable latency.<\/p>\n

  Measurements were done as cleanly as possible (without other things running on the machine\/device when possible, with a device that was nearly full on battery for devices with batteries). Latencies when other software is running on the device or when devices are low on battery might be much higher.<\/p>\n

  If you want a reference to compare the kindle against, a moderately quick page turn in a physical book appears to be about 200 ms<\/code>.<\/p>\n

  This is a work in progress. I expect to get benchmarks from a lot more old computers the next time I visit Seattle. If you know of old computers I can test in the NYC area (that have their original displays or something like them), let me know! If you have a device you\u2019d like to donate for testing, feel free to mail it to<\/i><\/p>\n

  Dan Luu
\nRecurse Center
\n455 Broadway, 2nd Floor
\nNew York, NY 10013<\/p>\n

  Thanks to RC<\/a>, David Albert, Bert Muthalaly, Christian Ternus, Kate Murphy, Ikhwan Lee, Peter Bhat Harkins, Leah Hanson, Alicia Thilani Singham Goodwin, Amy Huang, Dan Bentley, Jacquin Mininger, Rob, Susan Steinman, Raph Levien, Max McCrea, Peter Town, Jon Cinque, Anonymous, and Jonathan Dahan for donating devices to test and thanks to Leah Hanson, Andy Matuschak, Milosz Danczak, amos (@fasterthanlime), @emitter_coupled, Josh Jordan, mrob, and David Albert for comments\/corrections\/discussion.<\/i><\/p>\n

  \u2190 Randomized trial on gender in Overwatch<\/a> How good are decisions? \u2192<\/a><\/div>\n

  Archive<\/a> Support this site (patreon)<\/a> About<\/a> Twitter<\/a> RSS<\/a><\/div>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"

  Computer latency: 1977-2017<\/p>\n

  Read more →<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1],"tags":[],"class_list":["post-5753","post","type-post","status-publish","format-standard","hentry","category-senza-categoria"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6daft-1uN","jetpack-related-posts":[{"id":763,"url":"https:\/\/monodes.com\/predaelli\/2015\/10\/31\/how-to-differentiate-between-an-average-and-a-good-programmer\/","url_meta":{"origin":5753,"position":0},"title":"How to differentiate between an Average and a Good Programmer?","author":"Paolo Redaelli","date":"2015-10-31","format":false,"excerpt":"\u00a0How to differentiate between an Average and a Good Programmer? \u00a0 Oh my! It's so true! javarevisited looks like a really good programming blog as I found gems like\u00ab10 Articles Every Programmer Must Read \u00bb among What Every Programmer Should Know about Memory What Every Computer Scientist Should Know About\u2026","rel":"","context":"In "Senza categoria"","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"Being a good programmer is 3% talent, 97% not being distracted by the Internet","src":"https:\/\/i0.wp.com\/monodes.com\/predaelli\/wp-content\/uploads\/sites\/4\/2015\/10\/Being%2Ba%2BProgrammer.jpg?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":4452,"url":"https:\/\/monodes.com\/predaelli\/2018\/07\/31\/with-daas-windows-coming-say-goodbye-to-your-pc-as-you-know-it-slashdot\/","url_meta":{"origin":5753,"position":1},"title":"With DaaS Windows Coming, Say Goodbye To Your PC As You Know It – Slashdot","author":"Paolo Redaelli","date":"2018-07-31","format":false,"excerpt":"Knowing how lazy and ignorant are people this is not a good news: With DaaS Windows Coming, Say Goodbye To Your PC As You Know It - Slashdot people are too much accostumed to rent things to understand how crippled they will be. Ostracus shares a report from Computerworld, written\u2026","rel":"","context":"In "Mood"","block_context":{"text":"Mood","link":"https:\/\/monodes.com\/predaelli\/category\/mood\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":5851,"url":"https:\/\/monodes.com\/predaelli\/2019\/07\/23\/web-bloat\/","url_meta":{"origin":5753,"position":2},"title":"Web bloat","author":"Paolo Redaelli","date":"2019-07-23","format":"link","excerpt":"Web bloat Some developer should learn this by heart! Web bloat A couple years ago, I took a road trip from Wisconsin to Washington and mostly stayed in rural hotels on the way. I expected the internet in rural areas too sparse to have cable internet to be slow, but\u2026","rel":"","context":"In "Senza categoria"","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":14967,"url":"https:\/\/monodes.com\/predaelli\/2026\/02\/07\/lenovo-no-thanks\/","url_meta":{"origin":5753,"position":3},"title":"Lenovo? No, thanks","author":"Paolo Redaelli","date":"2026-02-07","format":false,"excerpt":"I have never been really fond of Lenovo notebooks, even if they are used by many notable Linux hackers. Now I have an actual yet feeble reason to avoid them, preferring Linux-friendly vendors (such as Laptopwithlinux.com, tuxedocomputers.com, slimbook.com, even dell.com1 or system76.com in the USA) since it happens that in\u2026","rel":"","context":"In "Yet another reason to avoid"","block_context":{"text":"Yet another reason to avoid","link":"https:\/\/monodes.com\/predaelli\/category\/ethics\/yet-another-reason-to-avoid\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2547,"url":"https:\/\/monodes.com\/predaelli\/2017\/06\/02\/forwarding-audio-elsewhere-on-linux\/","url_meta":{"origin":5753,"position":4},"title":"Forwarding audio elsewhere on Linux","author":"Paolo Redaelli","date":"2017-06-02","format":false,"excerpt":"These days I've been attending to an online course that require me not to do anything else in the user session beside watching and listening. Actually I've been able to pass two checks while I've been hacking on another machine, just listening and watching now and then. But it's boring\u2026","rel":"","context":"In "Documentations"","block_context":{"text":"Documentations","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2174,"url":"https:\/\/monodes.com\/predaelli\/2017\/02\/19\/how-to-install-ubuntu-on-computer-with-uefi\/","url_meta":{"origin":5753,"position":5},"title":"How to install Ubuntu on computer with UEFI","author":"Paolo Redaelli","date":"2017-02-19","format":false,"excerpt":"How to install Ubuntu on computer with UEFI Nice! I may just need it soon. My wife asked for a new laptop. But while she finds Linux great - I've been exclusively using Linux since 1997 - some software requires for schooling out children sadly runs only on Windows. So\u2026","rel":"","context":"In "Senza categoria"","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/5753","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/comments?post=5753"}],"version-history":[{"count":0,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/5753\/revisions"}],"wp:attachment":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/media?parent=5753"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/categories?post=5753"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/tags?post=5753"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}