Let's add to that all the fuss that occurs to deliver us ads according to our recent navigation ... Improving physical delays will not speed up browsing!
I get amazed every time I'm configuring a new install of an OS, because the Internet is shit until I install uBlock. Then suddenly it's back to normal.
AFAIK (and I don't know much), c is also a huge limiting factor in processor design, since high-enough clock speeds put a hard cap on how far a signal can travel between ticks, even assuming perfect components. Agree that c is too low and we should attempt to simulate a universe in which it is higher and go live there instead.
The timing calculation approximation we used had no term for 'c' in it at all. The simple approximation is just an RC timing curve: total capacitance of the wire and gates that you need to change, through the on-resistance of the driving FET. The more complex version treats each wire as a transmission line and incorporates its inductance, but ultimately for electrical signals travelling in a medium near a ground the important factor is the dielectric, not the speed of light.
The other massive limiting factor in processor design is heat conduction.
You really shouldn't be complaining about the speed of light. We're leaving a lot on the table by sending the data along the surface of earth instead of through it.
With neutrino-based signalling you eliminate both the lower propagation speed and the suboptimal path.
Basically, lightning causes ripples in the Earth's electromagnetic sphere. Those ripples travel across the surface of the earth at an apparent speed that's faster than light, because the actual path is through the earth.
Has neutrino-based signalling been achieved or is it still a research topic? Last time I read about it it was more a case of "if we could do this it would be great, but we have no idea how to do it" and a quick Google search only brought a Forbes article from 2012 which had a similar sentiment.
The OPERA experiment (of false FTL neutrino discovery fame) did create and detect neutrino pulses as part of their experimental setup.
It's possible as far as the physics go but also impractical given the particle accelerator and detectors needed. And the post-processing the scientists had to do to tease out the timing information also would negate any latency advantage.
> Has neutrino-based signalling been achieved or is it still a research topic?
An accelerator- or reactor-based neutrino experiment can detect whether the source is on or off, so in principle you can send binary information. This has been demonstrated using NuMI/MINERvA [1]. It's more of a novelty than anything practical.
No, that is a common misconception. Quantum teleportation always requires a classical communication side-channel and thus is bounded by the same speed limitations as the classical link.
Or soon via low orbit satellite networks. Should be able to speed up latency between continents (and not as expensive as the microwave towers that high frequency traders use).
A lot of latency inflation over past 10 yeara came from increase in L3 switchings over L2. Nowadays, you can have over 10 IP switching in DCs, and within the last mile.
You also get more hops thanks to some backbone networks abandoning MPLS in favour of native routing/packet labeling.
In Romania, as I understand, networks are largely free of L3 switching overhead thanks to large portion of networks running pure L2
Most switches are routing switches and the same pipeline is used for both L2 switching and L3 routing. There is no sensible difference in switching and routing unless the switch has the ability to completely disable L3 routing. The typical latency is 500ns in store-and-forward mode (cut-through fallbacks to store-and-forward in most situations). If L2 processing could be done in 300ns, this is 200ns. With 10 routers, this is 0.002 milliseconds. Not something noticeable. Even if you compare with cut-through switching which could lower the latency to 50ns, that's still only a 0.005 milliseconds penality.
My measurements give me from 10ms to 50ms for IP routing on mainstream hardware (for the whole route).
L2 switching is faster than IP routing because even cheap "smart" L2 hardware come with hardware acceleration, but a typical non-core router for a mid-tier ISP is usually a consumer grade, PC hardware based router.
Do you mean microseconds here? ms is milliseconds, and that just does not make any sense. E.g. I'm 7 (visible) hops away from the nearest Google DNS, and roundtrip pings to 8.8.8.8 are between 7ms and 8ms.
Yes, milliseconds. The difference there is because routers above you most likely are a carrier grade equipment like Cisco gear with ASIC based switching. This is what you can expect from big ISP in a big city, and less likely in networks serving more remote suburbs.
An EX2200, a routing switch you can pay for about 500$, is also ASIC-based. Linux on a server has no problem routing with a latency in the order of 100ns. I don't see what kind of equipments would route in the order of 10ms. That's just too huge.
Linux is able to handle about 5 Gbps of traffic of small packets (64 bytes) with one core. This gives a latency of 100ns to keep the pace. You need to find a Linux router 10000 time slower than this to get a 1ms latency.
If you want an easy speed up and you use a modern version of nginx, which you should for many reasons but chiefly performance and security.
Add these lines to your nginx config file:
# Only support HTTPS and enable http2
# which will allow you to multiplex requests.
# In a separate config do a 301 from normal HTTP
# for all paths / subdomains.
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
# Make TCP send multiple buffers as individual packets.
tcp_nodelay on;
# Send half empty (or half full) packets.
tcp_nopush on;
It reduced our page load time by around 75%, and more for people accessing the site from the other side of the world.
I'm not very experienced with these nginx settings. Could you explain how this improves speed so much for you?
It seems that you've followed [1] by the similarity of what that suggests to what you've suggested. tcp_nodelay seems to force it to not wait 0.2 seconds, which nginx does so that it doesn't send lots of really small packets. I can see this increasing speed by 200ms (a lot) but increases network traffic as a cost.
tcp_nopush seems to be about optimising each packet sent, reducing the total size of them.
So I'm more of a machine learning / cyber security guy than a sys admin, but with that proviso, here is my understanding:
Of course you'll have to check your own site for your own performance issues, but while travelling from Toronto to Vilnius I found our site much slower and investigated why. We have a webapp running Ember with mix of largish assets, like images, and smallish assets, talking to a JSON API standard API written in rails and proxied through nginx (responses are usually around 1kb of JSON, but this gets compressed with HTTP2).
In reality waiting 200ms is an enormous cost and carries a hidden cost: Larger packets are easier to lose. If you're going mostly to browsers that is more and more often going through wifi or cell tower networks with at least 1% packet loss and when the resend happens you're stuck with that 200ms delay again.
That's my understanding, but the real truth is "it just works for me when testing around the world with real-world use cases, try testing it out yourself and please let me know if you learn something new".
Nagle's algorithm is not a network level delay. If data is lost then it is retransmitted as soon as the sender learns about the loss. Nagle only delays application level sends.
The problem with webapps is a compounding effect of many requests.
a) dependency chains (asset A loads B loads C) mean the browser only knows to load C once B has been loaded, so the latencies (including nagle) add up. http/2 push is supposed to help with that.
b) statistics. your 95th percentile latency is irrelevant if you're loading hundreds of assets and want to know when the site has finished loading.
Doesn't help with first page view when visiting from organic search or somewhere like HN. I do cache like it was going out of fashion, but I optimise for the first hit and assume 100% bounce rate anyway!
I just tried this and was unable to measure any difference.
Variation in page load times far outweighed any difference the config change might have brought.
So, YMMV.
From a theoretical standpoint I agree http/2 should help (although in practice I didn't measure any difference). I can't see why tcp_nodelay would help except in extremely niche applications (sending tiny responses with lots of pauses?)
My evidence is that HTTP/2 doesn't help much if at all for lightweight sites, especially if the site manages to hit my target of the first 10kB hitting the client rendering all the above-the-fold information, and especially if the clients are reasonably close to the server.
Indeed, given that HTTP/2 forces TLS (for any mainstream browser) which forces an extra RTT, for light pages my evidence is that HTTP/2 makes things marginally worse...
> which you should for many reasons but chiefly performance and security.
Why would you use nginx for security? I see over 100 CVEs for nginx.
This isn't exactly unexpected. Nginx is an incredibly complicated piece of software written for performance in C. That's basically the trifecta of security badness.
If you want security, why not use a (possibly slower) simpler product written in a safer language?
Did I read this correctly? Is it saying that a general internet connection, without specialist low latency connectivity, is only 37x slower than its theoretical minimum?
That's astonishingly good. It's great that they think they can do better but bloody hell.
Indeed - I've been using the Internet since the early 1990s and I'm constantly amazed that I can be playing a multi-user game (e.g. WoT) with tens of people in multiple countries and get sub 50ms ping times.
What's even more impressive is how games like WOT hands multiple users with different latencies, and how they attempt to hide that from you! Reminds you that the ping number you see on screen is (almost) meaningless when you start to dig into it
You're saying that achieving 2.7% of the theoretical efficiency is good?
Many car engines have an efficiency of around 20% for example, as compared to the maximum theoretical efficiency of 67%. If car engines performed only well enough to meet your standard of amazingness, your gas costs would be 7 or 8 times higher. Or if you used a modern Toyota engine for comparison, something like 14 times higher.
Obviously I took an example from a different sphere for comparison... if you really find this to be an astonishing result can you elaborate?
You should not compare the fastest car speed, but the average car speed, which for this argument would probably be closer to 200km/h. That puts it in a factor of 5 million, which is within one order of magnitude of the original guess.
Your car is not operating at 20% efficiency of theoretical limits if you take the whole energy pipeline into account. You know... fusion, sunlight, plankton, oil, refining, combustion, mechanical energy. On the other hand speed-of-light to actual ping times is an end-to-end efficiency calculation.
Plankton in particular is terrible at converting energy.
sun -> mj-PV -> battery -> electric motors run circles around those.
Not to belittle the internal combustion engine but that's just the theoretical efficiency of chemical combustion. It's a local maximum. That's tiny compared to the global maximum energy available from the same amount of fuel.
As a trite comparison, it's a similar to arguing the theoretical maximum speed that a person can run. Interesting, but doesn't tell you anything about the maximum speed that a person can move.
The speed of light in a vacuum, though, is qualitatively different. It's not a local maximum, it's the global maximum.
Anyway, I reserve the right to be impressed. I spend enough of my life being jaded and cynical. Sometimes I see things like this and it makes me think about stuff that I take for granted.
Well, the internet essentially was born from scientists displaying their research and papers, linking to other scientist pages, experiment data, and so on. The early internet was essentially a fancy FTP server with a bit of Times New Roman paragraphs in. That's why web-servers were originally called Internet _Information_ Services (IIS). Because it was designed to be essentially an online library.
Then of course commercial, social, political, and many other areas jumped on board. People found out that sales (if you was commercial), views (if you were political or social), and whatever you were aiming for essentially, magically increased if you made your website _look_ better. It's how humans have always worked.
This gave birth to an arms race where the weapon of choice was including increasingly advanced ECMAScript code into your website.
From this the modern web was born. (i'm simplifying a lot here, but that is generally the very quick overview as to how I experienced it over the last 2 decades).
The idea that browsing the modern web transfers "tens of kilobytes of data" is pessimistic. I think you can argue bandwidth constraints in the real-world are real. Improving the underlying stack is one thing and would obviously bring improvements, but browsing speed won't be one of them. If you make responses faster, they'll be able to stuff more garbage in those responses.
If you're thinking, "it's fast enough!" -- remember that a system's performance determines what you're able to build on top of it. If GPU designers had said "it's fast enough" ten years ago, for example, modern neural-net AI may never have happened. It's easy to imagine doing the same things faster, but it's harder to picture the new things that a lower-latency Internet would make possible.
A fair question might be whether that's an issue with the internet, or the way it's used. In particular, p2p chatting vs going through a central server comes to mind. And a point comes when speed is constrained by the speed of light (especially for latency sensitive applications).
No, but there are plenty of people from Comcast, Rogers, et al and, significantly more importantly, U.S. regulators who are busy telling us that everything is "fast enough" that we don't need competition.
Actually, I think ~10mbit is fast enough. You can easily use Hangouts/Skype with good quality video on that kind of link. The problems are elsewhere: it's not stable enough, and it's not responsive enough.
Anything faster is just a cherry on top. Sure, files download faster, you can stream 4k, etc. But I'd say that's luxury which you could choose. Lower speeds are "enough" for a lot of people.
This. If I had perfect QOS where I knew foreground tasks would dominate my bandwidth and connection would never be interrupted and latency would be low and packet-loss would be negligible? I would be perfectly happy with 10mbit. I'm not downloading images that often.
Videoconferencing is actually pretty awful on a high bandwidth link if the latency and jitter are high.
I can have an effective voice conversation with terrible quality audio if it's low latency. Extremely lifelike (high bitrate) audio is just uncanny (not helpful) if the latency and jitter are high.
That's like saying 640K ought to be enough for everyone. Once we have stable 1GBit connections on all landlines and mobile devices, we might eg stop hoarding data on our disks altogether. Apps (if they still exist) could be downloaded on the fly when the user chooses to start them. Lifelike VR/AR communications could be enabled by this. Teleworking could become a no-brainer, from any location imaginable (perhaps with telepresence). I will be able to run a dev machine on some EC2 instance and VNC into it with an unnoticeable lag, so I won't need serious CPU horsepower in my laptop anymore. That's what I could think of off the top of my head..
I don't think that comparable to 640k. Things you mention are are either what I define cherry on top (VR/AR meeting? Why? Teleworking is already present and completely doable on low bandwidth, mid latency - I'm doing it every day). VNC lag issues are mostly exactly what I mentioned. You already have enough bandwidth - it's the latency that affects you.
Besides, high detail remote desktop are a small, specialised segment, relatively speaking. If you're a developer, most of the time you work with text. If you're an office worker, most of the time you work with fairly static apps like office. Sure, you can't really work with remote blender at the moment, but we're getting into improvements for the long tail now - which is great. But once we're past 10mbps, improving latency will help more people than improving bandwidth.
> If GPU designers had said "it's fast enough" ten years ago, for example, modern neural-net AI may never have happened.
Right on the money. There is a deep synergy between AI and simulation. It's not just that they both run on GPUs, but simulation will become a major part of future AI. A robot needs to imagine scenarios before executing them. So they meet in the middle - gaming, VR, AI and robotics. Isn't it interesting that PacMan and other Atari games, that we used to play when we were kids, are now the playground of AI?
But is the problem here with slow hardware or slow deployment of better hardware? Also aren't we closer to hitting physical limits than the GPU people are? It's easier to add cores than to make faster ones.
I would say that the title "it's slow" is ridiculous because 1/30th of the fastest possible speed in the universe is insanely fast. Better to say "it's fast, but I think we can make it 3 times faster".
It's deployed in some places and working already. Citing from the webpage:
> SCION is the first clean-slate Internet architecture designed to provide route control, failure isolation, and explicit trust information for end-to-end communications.
Also it will reduce latency, increase throughput and more, as mentioned in the papers.
The project has really been getting traction in recent years, it may just become our new internet base layer.
Currently the people at ETHZ are working on verifying router hardware mathematically to guarantee SCION's properties.
That wouldn't help. If you go to https://foo, before the server can even redirect you to https://www.foo, it has to present a valid cert for foo without www.
Very interesting approach. I've read about SCION before. I believe, however, that its goal is primarily security. The reduced latency claim simply comes from the fact that they try to restrict routing in such a way that, for example, traffic with source and destination both in the US will never leave the US because of some weird routing policies.
I'm not sure about this. Somehow, it seems to be against the principles of a truly free internet.
it it really interesting but simply "ignore the technical challenge for now" makes the Whole discussussion pointless, as the problem here ARE the technical challenges that a zero latency (above the theoretical limit) network implies... Anyway it is good to know the numbers: in my opinion a 37x factor, in this case is not so bad
No mention of bufferbloat, it's in mainline linux since a few releases now. If all devices used these patches or applied the same logic, could it also work ?
People who care about how fast the internet is are not the same set as people who know statistics acronyms, and they don't show up in a simple web search. You know how else we can make the internet better and faster? Publishing articles with software and licenses that make it easy for people to improve and share your article.
If you are unfamiliar with basic statistical concepts it is hard to believe you will be able to provide any compelling contributions to making the internet faster.
Some classes of issues will be better solved if the solver understands stats. M/M/1, distributions, percentiles, etc, yes. If only I understood them...
By my local major London paper somehow needs 4MB of crap and >60s to display a 2 para story. I don't need anything as subtle as "stats" to tell them that they're holding it wrong and why I avoid their site like the plague.
Since the OP compared Internet latencies to the speed of light in glass...look up 802.1CM/IEEE1904.3 or "CPRI over Ethernet"/"Radio over Ethernet"! Those describe techniques for conveying LTE baseband signals (digital I/Q-samples) over Ethernet -- so the radios can live far away from the equipment that speaks the physical / MAC / radio-resource-control layers of LTE. There are strict latency/jitter requirements involved (the phone and the eNB run a very fast automatic-repeat-request protocol between each other, too much latency breaks the loop) -- and large (but predictable) data rates involved.
Even if you're not trying to send radio baseband data over ethernet networks -- there's lots of noticeable queuing going on, everywhere. It's not just the unmanaged and pathological "bufferbloat" queues (that occur when a device has a network link much faster than its other network link) -- there's little queues that are used for tasks like:
* frame aggregation
* holding onto data until a shared medium is idle
* for scheduled systems like DOCSIS or LTE, holding onto packets until an uplink grant has been given -- or holding onto packets until a station's downlink grant/timeslot becomes active
* inter-device communication (usually with ring buffers or the like)
* any processing/forwarding that isn't of the cut-through flavour usually involves queuing at least a single frame
* context switching / memory copying / interrupts
Retransmission mechanisms can introduce latency as well -- if there's no special channel for acknowledgements, they'll use up airtime, and if data needs to be retransmitted, it might induce delays for never-transmitted data that's waiting for its first transmit opportunity.
In general, unless you're actively being paid to stomp out every imaginable source of latency, there'll be little queues living everywhere in your system -- from TCP's queues right on down to the CPU's store buffers-- because queuing is the natural way to cope with subsystems that produce/consume at different rates.
If you are interested in bufferbloat and TCP, Google's BBR is a really interesting attempt at solving part of the problem. See http://queue.acm.org/detail.cfm?id=3022184
BBR is a sender-only modification to TCP that basically solves the problem of large buffers.
Because every time we get faster connections, we download more the client and force more client side processing. Angular and friends are just causing a worse user experience, not a better one.
We also don't take advantage of DNS enough. We should/could use it to pass along information about the client's ISP to locate a server one or two hops away from the client. DNS could easily solve the IPV4 with SRV records, but instead, we allow service location to happen at the TCP level.
How is angular making the web slower. An angular project can sit somewhere in the 130kb range, with lighter frameworks like vue sitting at 30kb. These are smaller than most images or gifs used on the web. So the trade-off is one image on your page, or a robust RIA experience, with much more maintainable code. If you build it correctly, you're decreasing the amount of bytes on the wire significantly when using client side frameworks, over re-rendering each and every page on the server for every interaction. I also maintain a large vanilla javascript application that was written before I arrived, and the javascript weighs in at almost 5MB, and we have a general no touch policy on it because of how fragile the vanilla javascript is. It was poorly written, but even a poorly written vue app, would come in at much less than the 5mb JS. I just don't buy this as the reason the web is slow.
> So the trade-off is one image on your page, or a robust RIA experience
If I had the choice, I'd take an additional image in that trade, thanks. The 'rich' 'experiences' I've been offered so far are inferior to bog-standard web pages. I'll grant you that it is friendlier to coders whose applications fit the model. Beyond that, they don't work without Javascript[1]. The "richness" is usually useless animation and similar, frequently employed because it is there, rather than actually adding any value (Anyone remember the Jquery animation explosion?). It breaks a lot of automation; see the JS comment. These are all things that are important to me.
I get that folks are fine with losing me as a user/customer, and that's their choice. But they should know why, thus my explanation.
[1] Which means I usually go elsewhere when I encounter it, because I default to leaving it off.
If I understand you right, your contention seems to be more with animation and 'fluff' rather than with MV* frameworks like Angular specifically. To which I'll simply say: in some cases animation is as important to the user experience as an additional image would be, and in some cases the additional image just contributes more 'fluff' than the animation or interactivity would. There are many dimensions to the problem (and the article only hints at some of them on the protocol side), and pinning JavaScript frameworks as the cause strikes me as unfair.
What you're really asking for is for the components being used, be they images, animations of frameworks, to be used with a deliberate purpose. Which I think is what everyone is asking for, and what good developers and designers strive for.
You're actually picking up the smaller of my two complaints. If everything else about Angular were sensible, I'd probably grumble about dumb overuse of trendy visual primitives, but that's about it. And I absolutely agree that, used sensibly, animations and whatnot are very useful. This complaint basically boils down to wishing all web designers were actually as good as a lot of them think they are.
You missed my complaints about the uselessness of Angular apps without a JS interpreter. That's important, because it means they're basically worthless for consumption by nonhumans. (Sure, I can run Chrome headless, but that's an entirely different can of worms that play poorly with pipelines, not to mention an enormous, absurd runtime for what should be a trivial file transfer.)
Web automation on a personal scale is enormously useful. Angular breaks the underlying assumptions that make it work for sites that don't go out of their way to accommodate it. I get that may be an unintended benefit to some people who want to be control-freaky about how their offerings are used , but it enormously reduces the value of the web.
A connection just hit me - it is similar-ish to way back when, when some misguided designers wanted to publish PDFs on the web instead of HTML. They wanted full layout control, at the cost of basically everything else. Angular is similar, in that doing anything the creator didn't anticipate is very difficult, despite complying with the letter of web standards.
And also, as I said, I default to browsing with JS off. When I hit a blank page, I curse "Angular" and go back to the search engine. So that's annoying, but I've yet to encounter an Angular site I can't live without.
If the 3x slowdown from the infrastructure were eliminated, each round-trip-time being 3x faster would affect all the protocols above, and we could immediately cut the latency inflation from ~37x to around 10x, without any protocol modifications.
The page this article is published on makes 87 separate network requests to 19 different domains. Even with a great deal of the content cached, it takes 7 seconds to reload over my WiFi today. This is because I'm using an ad blocker; without one, the page makes more requests to more domains and transfers more stuff, slower.
It seems likely that cutting bloat would have a much bigger impact on responsiveness than infrastructure upgrades. Cutting bloat would produce benefits even (especially) in times and places where signals or infrastructure are marginal. Cutting bloat could mean your old phone or tablet computer could browse the web tolerably instead of ending up in a landfill. Cutting bloat from a website today produces a benefit, for all visitors, worldwide, today. Improving infrastructure may be a good investment, but cutting bloat is a force multiplier.
The responsiveness of the web has been adjusted to optimize the number of eyeballs that see ads. If a site is too sluggish, people leave, but a site that's too fast is leaving money on the table. How many advertising, tracking, and affiliate domains would a web page like this connect to, if latency were cut by two thirds?
As much as ads are annoying, this has nothing to do with the article. One man's bloat is another man's content. No need for this nag to be top comment on HN for an article about why data isn't moving at the speed of light.
He's not making an argument for the elimination of ads, bloat comes in so many different forms. Loading entire libraries to solve trivial tasks, dragging in massive images where they don't belong, etc.
They don't need to cut advertisements. Certainly, they could have as many as 10 advertisements, and only make requests to two domains---the ad network, and their own domain.
Their page has a high number of requests primarily because they do not bundle their javascript, CSS, or icons.
I see 95 requests that I see without adblocking, and about 20 of those requests are javascript coming out of their own WordPress instance. They're using 2 different full icon libraries and adding at least 5 more icons not contained in either.
I think a large contributor to this trend is a side effect of JavaScript, which is to perform library inclusion at runtime inside the browser.
Think about it. If you include a gigantic library in a compiled language, but only use 3 of its features, the rest of the library doesn't make it into your final program. Only those three features that you used do, because that's the linker's job. It takes only the features of a given library that are actually used for space efficiency reasons, and removed anything unneeded.
This is possible for JavaScript, but common language usage patterns work against this goal. If you're going to use a clientside library that's fine, but you should ship only the small fraction of it that your code actually calls into, not the entire honking library, 90% of which goes untouched by the client for every user.
Point here is, I agree with you, but this is a difficult problem to solve. You're asking a large number of frankly inexperienced programmers to deviate heavily from most JavaScript tutorials, and worse, most example code included in the documentation of most large frameworks.
That's standard dead code elimination, and that's only true in static linking. Dynamic linking, which is far more popular, will load the entire library into memory. And then you get interesting hybrids like Java, where libraries are dynamically linked but only the classes that are actually used are loaded. [0]
The equivalent for dynamic languages is tree shaking, and is a harder or impossible problem depending on the language. When you can do something like the following in JavaScript, how do you determine what's dead or alive?
var fn = document.getElementById("function").value;
var input = document.getElementById("input").value;
var output = functions[fn](input);
document.getElementById("output").value = output;
[0] EDIT: But all the method and fields within a class are loaded, regardless of whether they are used. Which is why I called it a hybrid.
Language theory question: In the case of JS is there a safe, but still useful, subset of the language where dead code elimination could be improved?
Ignore if it can be detected or not, we'll pretend that the author has to certify that they followed your subset and didn't do X, Y, or Z. If they disobeyed your rules then all bets are off and the result is undefined.
I'm afraid it won't help much to restrict the language. For optimal dead-code elimination (aka tree shaking), you need human-level intelligence. Here's an example I posted yesterday in the thread about iOS app bloat: https://news.ycombinator.com/item?id=14618324
I agree - both problems can be improved independently of each other. I think "bloat" is less solvable centrally, though, and maybe just the natural consequence of making software more reusable and componentized.
It's not ads! Jquery.com, bootstrapcdn.com, cloudfare.com, cloudfront.net, google-analytics.com, fontawesome.com, Wordpress, Twitter, Facebook, Pocket, rating-widget.com, and typography.com are all used to put the content on this website, and none of them are ads.
Buddy I hate all that shit. I use uMatrix and block as much as I can while still seeing the real content. In fact that's how I know what the domains are.
The slowness that we experience is from delays caused by calling scripts that call scripts that call scripts, processing large pieces of javascript and network latencies. edit: and server latencies.
I disagree. The article claims that latency is a problem because, as a main example, users dislike slow page load times (citing Google and Bing). So it a very fair response that we can have a much bigger impact of user-perceived latency by reducing the number of requests our pages make and the size of the page.
What has always pissed me off is the global bandwidth overhead that ads have while not reducing the actual cost of connectivity to the average internet customer.
What percentage of my cellular data-consumption is specifically ads?
I need an app that tracks all data connections and tells me what percent went to which advertisers and a mechanism to block them or bill them to subsidize the cellular bill I pay for data, but that payment has a sizeable chuck allocated to my device displaying their ads.
Does anyone not recall the impetus behind the original paid cable tv model was that "you pay for the content of cable TV, thus we won't show you commercials"
The. They found out they could say "fuck you" to consumers, play commercials, hike up rates and also take in billions of government subsidies for infra upgrades that were never performed.
And companies wonder why some people want vigilante justice on such companies.
The page is 2.3kB on the wire, and the single other request it makes (for the image) adds another 70kB. Taken together, this is a two-order-of-magnitude decrease in page size, with exactly the same content.
While keeping it a PNG? I hit that thing with pngcrush and scaled it to half the size of the original article: what's your magic to get it down to 28k?
Total page weight is now 15kB, 0.2% the size of the original page. Incidentally, that ratio is about the same as the ratio between the original page and the entirety of the game Overwatch.
Someone posts these links every time the discussion comes up on HN. The down voters have likely forgotten that there are many new people who haven't seen these websites yet. It looks like the down votes have been reversed.
In the spirit of these repeated posts, I'll repeat the typical critique. "The white background is harsh on eyes, and there is nothing wrong with images and color to help improve aesthetics."
I loaded a page the other day that took several minutes to load, over 2,000 connections and constantly rising, and over 20mb. Just to open the home page and then sit there.
I agree website bloat is a big problem, but I'm too excited to hear someone talking seriously about latency to care.
For years all I've wanted is, say, 6Mbps & 5ms ping, but nearly everyone seems to focus on bandwidth.
It might lead to more ads on webpages. But it would also dramatically improve VPN and all "realtime" apps, i.e. VoIP, Skype, remote desktop, sometimes ssh, etc.
"Slow" internet is not so bad (especially when it is not really THAT slow). Limitations in connectivity force designers and developers (therefore large companies) to optimise things and save resources. Internet speed growth rate could be 5% (compounding) would be enough in order to provide a friendly environment for new frameworks, technologies in the field of network and web to benefit all.
163 comments
[ 3.7 ms ] story [ 164 ms ] threadSpeed of propagation in typical cable is around 66% of c. That is not too bad. More latency is probably caused by buffering.
Speed of light is just too low. We should get a lobby-group working on it and the limiting laws of physics.
The timing calculation approximation we used had no term for 'c' in it at all. The simple approximation is just an RC timing curve: total capacitance of the wire and gates that you need to change, through the on-resistance of the driving FET. The more complex version treats each wire as a transmission line and incorporates its inductance, but ultimately for electrical signals travelling in a medium near a ground the important factor is the dielectric, not the speed of light.
The other massive limiting factor in processor design is heat conduction.
With neutrino-based signalling you eliminate both the lower propagation speed and the suboptimal path.
Basically, lightning causes ripples in the Earth's electromagnetic sphere. Those ripples travel across the surface of the earth at an apparent speed that's faster than light, because the actual path is through the earth.
It's possible as far as the physics go but also impractical given the particle accelerator and detectors needed. And the post-processing the scientists had to do to tease out the timing information also would negate any latency advantage.
An accelerator- or reactor-based neutrino experiment can detect whether the source is on or off, so in principle you can send binary information. This has been demonstrated using NuMI/MINERvA [1]. It's more of a novelty than anything practical.
[1] https://arxiv.org/abs/1203.2847
https://www.scientificamerican.com/article/china-shatters-ld... http://spectrum.ieee.org/telecom/security/two-steps-closer-t...
You also get more hops thanks to some backbone networks abandoning MPLS in favour of native routing/packet labeling.
In Romania, as I understand, networks are largely free of L3 switching overhead thanks to large portion of networks running pure L2
L2 switching is faster than IP routing because even cheap "smart" L2 hardware come with hardware acceleration, but a typical non-core router for a mid-tier ISP is usually a consumer grade, PC hardware based router.
>100ms
Under load with anymuch sizeable routing table?
Linux is able to handle about 5 Gbps of traffic of small packets (64 bytes) with one core. This gives a latency of 100ns to keep the pace. You need to find a Linux router 10000 time slower than this to get a 1ms latency.
Add these lines to your nginx config file:
It reduced our page load time by around 75%, and more for people accessing the site from the other side of the world.It seems that you've followed [1] by the similarity of what that suggests to what you've suggested. tcp_nodelay seems to force it to not wait 0.2 seconds, which nginx does so that it doesn't send lots of really small packets. I can see this increasing speed by 200ms (a lot) but increases network traffic as a cost.
tcp_nopush seems to be about optimising each packet sent, reducing the total size of them.
Interesting stuff though!
[1] https://t37.net/nginx-optimization-understanding-sendfile-tc...
Of course you'll have to check your own site for your own performance issues, but while travelling from Toronto to Vilnius I found our site much slower and investigated why. We have a webapp running Ember with mix of largish assets, like images, and smallish assets, talking to a JSON API standard API written in rails and proxied through nginx (responses are usually around 1kb of JSON, but this gets compressed with HTTP2).
In reality waiting 200ms is an enormous cost and carries a hidden cost: Larger packets are easier to lose. If you're going mostly to browsers that is more and more often going through wifi or cell tower networks with at least 1% packet loss and when the resend happens you're stuck with that 200ms delay again.
That's my understanding, but the real truth is "it just works for me when testing around the world with real-world use cases, try testing it out yourself and please let me know if you learn something new".
The problem with webapps is a compounding effect of many requests.
a) dependency chains (asset A loads B loads C) mean the browser only knows to load C once B has been loaded, so the latencies (including nagle) add up. http/2 push is supposed to help with that.
b) statistics. your 95th percentile latency is irrelevant if you're loading hundreds of assets and want to know when the site has finished loading.
https://en.wikipedia.org/wiki/HTTP/2#Encryption
RTT hurts in my world.
Variation in page load times far outweighed any difference the config change might have brought.
So, YMMV.
From a theoretical standpoint I agree http/2 should help (although in practice I didn't measure any difference). I can't see why tcp_nodelay would help except in extremely niche applications (sending tiny responses with lots of pauses?)
Indeed, given that HTTP/2 forces TLS (for any mainstream browser) which forces an extra RTT, for light pages my evidence is that HTTP/2 makes things marginally worse...
http://www.earth.org.uk/note-on-carbon-cost-of-CDN.html
Will wait for something else.
Why would you use nginx for security? I see over 100 CVEs for nginx.
This isn't exactly unexpected. Nginx is an incredibly complicated piece of software written for performance in C. That's basically the trifecta of security badness.
If you want security, why not use a (possibly slower) simpler product written in a safer language?
Also, lots of CVEs indicate only one thing: that lots of people are checking it.
Doesn't it also mean they're finding lots of problems with it?
Also that it has lots of vulnerabilities.
Instead, you could use a product that's secure by design.
Of course, it doesn't support HTTPS or HTTP/2, so... there's that.
[0] http://filed.rkeene.org/
That's astonishingly good. It's great that they think they can do better but bloody hell.
It's indistinguishable from magic.
Many car engines have an efficiency of around 20% for example, as compared to the maximum theoretical efficiency of 67%. If car engines performed only well enough to meet your standard of amazingness, your gas costs would be 7 or 8 times higher. Or if you used a modern Toyota engine for comparison, something like 14 times higher.
Obviously I took an example from a different sphere for comparison... if you really find this to be an astonishing result can you elaborate?
But in true there are production cars that pass 430 km/h, resulting in a factor of about 2.5 millions. A lot less than 10 millions.
https://en.wikipedia.org/wiki/Production_car_speed_record
sun -> mj-PV -> battery -> electric motors run circles around those.
Says the person who can't even photosynthesize!
As a trite comparison, it's a similar to arguing the theoretical maximum speed that a person can run. Interesting, but doesn't tell you anything about the maximum speed that a person can move.
The speed of light in a vacuum, though, is qualitatively different. It's not a local maximum, it's the global maximum.
Anyway, I reserve the right to be impressed. I spend enough of my life being jaded and cynical. Sometimes I see things like this and it makes me think about stuff that I take for granted.
Then of course commercial, social, political, and many other areas jumped on board. People found out that sales (if you was commercial), views (if you were political or social), and whatever you were aiming for essentially, magically increased if you made your website _look_ better. It's how humans have always worked.
This gave birth to an arms race where the weapon of choice was including increasingly advanced ECMAScript code into your website.
From this the modern web was born. (i'm simplifying a lot here, but that is generally the very quick overview as to how I experienced it over the last 2 decades).
Anything faster is just a cherry on top. Sure, files download faster, you can stream 4k, etc. But I'd say that's luxury which you could choose. Lower speeds are "enough" for a lot of people.
I can have an effective voice conversation with terrible quality audio if it's low latency. Extremely lifelike (high bitrate) audio is just uncanny (not helpful) if the latency and jitter are high.
Besides, high detail remote desktop are a small, specialised segment, relatively speaking. If you're a developer, most of the time you work with text. If you're an office worker, most of the time you work with fairly static apps like office. Sure, you can't really work with remote blender at the moment, but we're getting into improvements for the long tail now - which is great. But once we're past 10mbps, improving latency will help more people than improving bandwidth.
Right on the money. There is a deep synergy between AI and simulation. It's not just that they both run on GPUs, but simulation will become a major part of future AI. A robot needs to imagine scenarios before executing them. So they meet in the middle - gaming, VR, AI and robotics. Isn't it interesting that PacMan and other Atari games, that we used to play when we were kids, are now the playground of AI?
It's deployed in some places and working already. Citing from the webpage:
> SCION is the first clean-slate Internet architecture designed to provide route control, failure isolation, and explicit trust information for end-to-end communications.
Also it will reduce latency, increase throughput and more, as mentioned in the papers.
The project has really been getting traction in recent years, it may just become our new internet base layer.
Currently the people at ETHZ are working on verifying router hardware mathematically to guarantee SCION's properties.
They also don't implement any security headers: https://observatory.mozilla.org/analyze.html?host=scion-arch...
I don't understand what this has to do with a free internet, routing doesn't have any affect on that
People who care about how fast the internet is are not the same set as people who know statistics acronyms, and they don't show up in a simple web search. You know how else we can make the internet better and faster? Publishing articles with software and licenses that make it easy for people to improve and share your article.
Some classes of issues will be better solved if the solver understands stats. M/M/1, distributions, percentiles, etc, yes. If only I understood them...
By my local major London paper somehow needs 4MB of crap and >60s to display a 2 para story. I don't need anything as subtle as "stats" to tell them that they're holding it wrong and why I avoid their site like the plague.
Good one.
Read https://drive.google.com/file/d/0B6Xurc4m_PVsZ1lzWWoxS0pTNVE... for a general introduction about latency in Ethernet/IP networks and http://www.ieee802.org/1/files/public/docs2016/cm-chen-front... for an introduction to the "radio over ethernet business"
Even if you're not trying to send radio baseband data over ethernet networks -- there's lots of noticeable queuing going on, everywhere. It's not just the unmanaged and pathological "bufferbloat" queues (that occur when a device has a network link much faster than its other network link) -- there's little queues that are used for tasks like:
* frame aggregation
* holding onto data until a shared medium is idle
* for scheduled systems like DOCSIS or LTE, holding onto packets until an uplink grant has been given -- or holding onto packets until a station's downlink grant/timeslot becomes active
* inter-device communication (usually with ring buffers or the like)
* any processing/forwarding that isn't of the cut-through flavour usually involves queuing at least a single frame
* context switching / memory copying / interrupts
Retransmission mechanisms can introduce latency as well -- if there's no special channel for acknowledgements, they'll use up airtime, and if data needs to be retransmitted, it might induce delays for never-transmitted data that's waiting for its first transmit opportunity.
In general, unless you're actively being paid to stomp out every imaginable source of latency, there'll be little queues living everywhere in your system -- from TCP's queues right on down to the CPU's store buffers-- because queuing is the natural way to cope with subsystems that produce/consume at different rates.
BBR is a sender-only modification to TCP that basically solves the problem of large buffers.
We also don't take advantage of DNS enough. We should/could use it to pass along information about the client's ISP to locate a server one or two hops away from the client. DNS could easily solve the IPV4 with SRV records, but instead, we allow service location to happen at the TCP level.
The internet _could_ be fast, but it's not :/
If I had the choice, I'd take an additional image in that trade, thanks. The 'rich' 'experiences' I've been offered so far are inferior to bog-standard web pages. I'll grant you that it is friendlier to coders whose applications fit the model. Beyond that, they don't work without Javascript[1]. The "richness" is usually useless animation and similar, frequently employed because it is there, rather than actually adding any value (Anyone remember the Jquery animation explosion?). It breaks a lot of automation; see the JS comment. These are all things that are important to me.
I get that folks are fine with losing me as a user/customer, and that's their choice. But they should know why, thus my explanation.
[1] Which means I usually go elsewhere when I encounter it, because I default to leaving it off.
What you're really asking for is for the components being used, be they images, animations of frameworks, to be used with a deliberate purpose. Which I think is what everyone is asking for, and what good developers and designers strive for.
You missed my complaints about the uselessness of Angular apps without a JS interpreter. That's important, because it means they're basically worthless for consumption by nonhumans. (Sure, I can run Chrome headless, but that's an entirely different can of worms that play poorly with pipelines, not to mention an enormous, absurd runtime for what should be a trivial file transfer.)
Web automation on a personal scale is enormously useful. Angular breaks the underlying assumptions that make it work for sites that don't go out of their way to accommodate it. I get that may be an unintended benefit to some people who want to be control-freaky about how their offerings are used , but it enormously reduces the value of the web.
A connection just hit me - it is similar-ish to way back when, when some misguided designers wanted to publish PDFs on the web instead of HTML. They wanted full layout control, at the cost of basically everything else. Angular is similar, in that doing anything the creator didn't anticipate is very difficult, despite complying with the letter of web standards.
And also, as I said, I default to browsing with JS off. When I hit a blank page, I curse "Angular" and go back to the search engine. So that's annoying, but I've yet to encounter an Angular site I can't live without.
The page this article is published on makes 87 separate network requests to 19 different domains. Even with a great deal of the content cached, it takes 7 seconds to reload over my WiFi today. This is because I'm using an ad blocker; without one, the page makes more requests to more domains and transfers more stuff, slower.
It seems likely that cutting bloat would have a much bigger impact on responsiveness than infrastructure upgrades. Cutting bloat would produce benefits even (especially) in times and places where signals or infrastructure are marginal. Cutting bloat could mean your old phone or tablet computer could browse the web tolerably instead of ending up in a landfill. Cutting bloat from a website today produces a benefit, for all visitors, worldwide, today. Improving infrastructure may be a good investment, but cutting bloat is a force multiplier.
The responsiveness of the web has been adjusted to optimize the number of eyeballs that see ads. If a site is too sluggish, people leave, but a site that's too fast is leaving money on the table. How many advertising, tracking, and affiliate domains would a web page like this connect to, if latency were cut by two thirds?
Their page has a high number of requests primarily because they do not bundle their javascript, CSS, or icons.
I see 95 requests that I see without adblocking, and about 20 of those requests are javascript coming out of their own WordPress instance. They're using 2 different full icon libraries and adding at least 5 more icons not contained in either.
Think about it. If you include a gigantic library in a compiled language, but only use 3 of its features, the rest of the library doesn't make it into your final program. Only those three features that you used do, because that's the linker's job. It takes only the features of a given library that are actually used for space efficiency reasons, and removed anything unneeded.
This is possible for JavaScript, but common language usage patterns work against this goal. If you're going to use a clientside library that's fine, but you should ship only the small fraction of it that your code actually calls into, not the entire honking library, 90% of which goes untouched by the client for every user.
Point here is, I agree with you, but this is a difficult problem to solve. You're asking a large number of frankly inexperienced programmers to deviate heavily from most JavaScript tutorials, and worse, most example code included in the documentation of most large frameworks.
The equivalent for dynamic languages is tree shaking, and is a harder or impossible problem depending on the language. When you can do something like the following in JavaScript, how do you determine what's dead or alive?
[0] EDIT: But all the method and fields within a class are loaded, regardless of whether they are used. Which is why I called it a hybrid.Ignore if it can be detected or not, we'll pretend that the author has to certify that they followed your subset and didn't do X, Y, or Z. If they disobeyed your rules then all bets are off and the result is undefined.
The code in tracking scripts varies between "short and elegant" to "massive and slow code". There is also a piece of json where the tracker thinks it is necessary to call 10 other trackers: See for example http://ib.adnxs.com/async_usersync?cbfn=AN_async_load : AN_async_load([ {"url":"http://cm.g.doubleclick.net/pixel?google_nid=appnexus&google..., "tagtype":"img"}, {"url":"https://ib.adnxs.com/getuid?https%3A%2F%2Fcm.g.doubleclick.n..., "tagtype":"img"}, {"url":"http://c.bing.com/c.gif?anx_uid=xxxx&Red3=MSAN_pd", "tagtype":"iframe"}, {"url":"http://odr.mookie1.com/t/v2/sync?tagid=V2_4265&src.visitorId..., "tagtype":"img"}, {"url":"http://match.adsrvr.org/track/cmf/generic?ttd_pid=appnexus&t..., "tagtype":"img"}, {"url":"http://pixel.rubiconproject.com/tap.php?v=4894&nid=1986&put=..., "tagtype":"img"}, {"url":"http://sync.mathtag.com/sync/img?mt_exid=13&mt_exuid=xxxx&re..., "tagtype":"img"} , {"url":"http://p.rfihub.com/cm?in=1&pub=345&userid=xxxx", "tagtype":"img"}, {"url":"http://t.mookie1.com/rsp?dnv=[TIMESTAMP]&rurl=//ib.adnxs.com..., "tagtype":"img"}, {"url":"http://t.wayfair.com/a/vendor_sync/user?vendor_id=1&uid=xxxx..., "tagtype":"img"} ]);
The slowness that we experience is from delays caused by calling scripts that call scripts that call scripts, processing large pieces of javascript and network latencies. edit: and server latencies.
What percentage of my cellular data-consumption is specifically ads?
I need an app that tracks all data connections and tells me what percent went to which advertisers and a mechanism to block them or bill them to subsidize the cellular bill I pay for data, but that payment has a sizeable chuck allocated to my device displaying their ads.
Does anyone not recall the impetus behind the original paid cable tv model was that "you pay for the content of cable TV, thus we won't show you commercials"
The. They found out they could say "fuck you" to consumers, play commercials, hike up rates and also take in billions of government subsidies for infra upgrades that were never performed.
And companies wonder why some people want vigilante justice on such companies.
The page is 2.3kB on the wire, and the single other request it makes (for the image) adds another 70kB. Taken together, this is a two-order-of-magnitude decrease in page size, with exactly the same content.
Every byte is sacred! This webpage infuriates me.
Convert it to a 32 color 8-bit version and it looks identical. Then use ImageOptim (or like) to compress it down to less than 16 KiB.
advpng -4 -z -i 15
http://www.advancemame.it/doc-advpng.html
http://motherfuckingwebsite.com http://bettermotherfuckingwebsite.com
In the spirit of these repeated posts, I'll repeat the typical critique. "The white background is harsh on eyes, and there is nothing wrong with images and color to help improve aesthetics."
"I would've even made this site's background a nice #EEEEEE if I wasn't so focused on keeping declarations to a lean 7 fucking lines."
http://www.webdirections.org/blog/the-website-obesity-crisis...
Using ublock origin, Ghostery on Safari with 2015 MacBook Pro 15"
For years all I've wanted is, say, 6Mbps & 5ms ping, but nearly everyone seems to focus on bandwidth.
It might lead to more ads on webpages. But it would also dramatically improve VPN and all "realtime" apps, i.e. VoIP, Skype, remote desktop, sometimes ssh, etc.