Wow: Intel unveils 1 teraflop chip with 50-plus cores - <AUTHOR> http://seattletimes.nwsource.com/html/technologybrierdudleysblog/2016775145_wow_intel_unveils_1_teraflop_c.html <comment><USER2> "Wow?" This is actually disappointingly low raw TFLOPS performance.

Intel's Knights Ferry GPGPU ASIC is not yet available, but already outperformed by 2-year-old chips from AMD and Nvidia who have both been selling GPU ASICs breaking the 1 TFLOPS barrier (single precision) for over _two years now_. The AMD Radeon HD 5870 and HD 6970 both reach 2.7 TFLOPS, and AMD makes a dual-ASIC PCIe card HD 6990 reaching 5.1 TFLOPS. Nvidia's mid- level GTX 275 (1.01 TFLOPS) was released in April 2009.

In fact, Knights Ferry evolved from the Larrabee GPU project, which disappointed Intel so much in terms of performance that they decided to forgo the GPU market (as it was clearly not going to be competitive), and to remain focused only on the GPGPU market by evolving Knights Ferry from Larrabee.

The one strong advantage of Knights Ferry is not performance, but x86 compatibility, as it would theoretically make it easy to port programs to. Although one would still have to rewrite the app to use the LRBni instruction set (512-bit regs) to fully exploit the computing performance... or else one would be limited to a quarter of its potential with SSE (128-bit regs.)

Another relative advantage of Knights Ferry is that each of the 50+ cores will probably be able to execute 50 unique instructions every clock cycle, making it very flexible. (Compared to, say, the HD 6970 which has 384 "cores" or VLIW units only able to execute 24 unique instructions: the ASIC is organized in 24 SIMD engines of 16 VLIW units each, the 16 VLIW units in each SIMD engine execute the same instruction in 16 different thread contexts, for a total of 384 threads.)

 _Edit:_ my bad, it looks like Intel claims 1 TFLOPS in double precision, which would put it up to the level of upcoming AMD chips (HD 7970 rumored to provide 4.1 SP TFLOPS or 1.0 DP TFLOPS in early 2012.)

<comment><USER3> A few problems in your comment:

1) The article text is wrong (and doesn't match the pics of the slides). The chip demonstrated today is Knights Corner which is a new part, not the older Knights Ferry SDV.

2) When counting flops we need to distinguish between single precision flops and double precision flops. You're comparison isn't valid -- Knights Corner was shown sustaining over 1TF on a double precision code. Nvidia's most recent flagship GPU has a theoretical peak of 515GF/s but sustains less than 225GF/s on the same DGEMM operation. Knights Corner is sustaining 4-5x that, and this implies that it's theoretical peak is higher again. AMD's GPUs also cannot touch this with a single chip. Their dual chip 6990 has what looks like the same theoretical peak but far lower practical performance due to being more of a graphics part than a compute part (e.g. look at the cache structures).

You are correct that these are real cores, each with a wide vector unit. If we wanted the equivalent of GPU "cores" we should multiply out by the vector width per core.

<comment><USER4> This Intel chip has a theoretical max performance of 1TF/s actual benchmarks are clearly going to be lower than that. The only thing slightly interesting about this is x86 but considering the large vector unit and anemic cache your not going to be able to port high performance code to this without massive changes anyway. And while comparing new chips vs existing chips is always a tradeoff, looking at the Radeon HD 6970 released in Dec 15, 2010 which had 2.7 TFLOPs Single Precision and 683 GFLOPs Double Precision this is a relatively minor jump in single chip double precision performance and unless there releasing it next week it would probably still be far slower than it's competitors.

That's also raw performance, considering this is a brand new architecture it's likely to have some significant bottlenecks limiting it's performance for the next 2-3 product cycles.

PS: Considering so few details where provided it's hard to look at this as anything but Intel saying "Please don't port your code we will have competitive x86 chips out at some point in time."

<comment><USER3> It's doing 1TF sustained and no one ever sustains 100% of their theoretical peak, so we know the peak is higher than 1TF. Consider also the sandbagging of number of cores as "50+". How big is the "+"? In reality the design will have a larger number that is then binned by yield and so forth to give a range of SKUs, as usual.

Next, you're comparing a sustained number on DGEMM with theoretical peaks on other machines. Nvidia sustains <225GF on DGEMM with Fermi so this is 4-5x. Last I looked, AMD were sustaining ~500GF with Cayman, so this is 2x, and a much easier machine to sustain perf on for other codes compared to Cayman. If you consider a potentially sandbagged 2x sustained perf to be "relatively minor" then so be it.

There are few public details provided but many of us have been programming with the Knights Ferry SDV kit in preparation for this part. So we have experience with the tools, with the use of lots of similar cache coherent x86 cores, etc. I can tell you this -- it's much easier to work with this than GPUs, and I've written a ton of code on all kinds of whacky machines, production compute code on GPUs included.

<comment><USER5> I don't see any mention of this chip doing DGEMM at 1TF. Just that it's sustaining 1TF performance, but you can write assembler code that get's within 1% of theoretical peak flops if your not trying to get anything done but, if you have a source feel free to give it. (Not that that even means much, AMD's getting 80% of theoretical max FLOPS on that benchmark and I assume Intel would pick the optimum benchmark for it's chip even if they had to design the chip around the benchmark.)

Also, I don't see anything that suggests it's anywhere close to a production chip. _More important, Knights Ferry chips may help engineers build the next generation of supercomputing systems, which Intel and its partners hope to delivery by 2018._ Not to mention your comparing a preproduction chip with a year old chip that's running on a 2 year old process when AMD, Intel, and Nvidia are about to do a die shrink.

<comment><USER3> Sustaining 1TF on DGEMM was explicitly mentioned by Intel in the presentation/briefing.

It's also mentioned in the press release:

[http://newsroom.intel.com/community/intel_newsroom/blog/2011...](http://newsroom.intel.com/community/intel_newsroom/blog/2011/11/15/intel- reveals-details-of-next-generation-high-performance-computing-platforms)

"The first presentation of the first silicon of "Knights Corner" co-processor showed that Intel architecture is capable of delivering more than 1 TFLOPs of double precision floating point performance (as measured by the Double- precision, General Matrix-Matrix multiplication benchmark -- DGEMM). This was the first demonstration of a single processing chip capable of achieving such a performance level."

Does it mean much? It means something to me, and is a great first step for those of us running compute intensive codes. They really wouldn't get far if they designed the chip only around being able to do this.

As I mentioned elsewhere in the thread, the article text is incorrect. The chip we're discussing is Knights Corner not Knights Ferry. The latter has been in early user hands for quite some time now and I've spent plenty of time hacking on it. Knights Corner is the new chip that is working it's way to production via the usual process with ship for revenue in 2012.

The 2018 target is for an exascale machine, not shipment of initial MIC devices. TACC have already announced they'll be building out a 10 petaflop MIC based system next year to go operational by 2013.

Yes, I'm comparing a chip that has not shipped, but given the perf advantage, given the tools and productivity advantage, given the multiyear process advantage Intel is sustaining, this is not a chip to be ignored. Knights Corner is shipping on 22nm. Other vendors have notoriously had difficultly on previous processes, depend on fabs like TSMC who are doing 28nm for them, and will be later to 14nm etc.

<comment><USER5> Thanks for clearing that up, my google foo is weak when they use the wrong names.

Still, it looks like they really do design for benchmarks: "Xeon E5 delivers up to 2.1* times more performance in raw FLOPS (Floating Point Operations Per Second as measured by Linpack) and _up to 70 percent more performance using real-HPC workloads compared to the previous generation of Intel Xeon 5600 series processors._ " 110% on benchmark = 70% in real world apps.

Granted, if this works out great, I have seen Intel blow to many new 'high performance' chips to expect much still they might just pull this one off. Unlike say the <http://en.wikipedia.org/wiki/Itanium> etc

PS: I always look at what Intel get's x86 to do much like how Microsoft could develop software, it's not that the capability is awesome so much as watching a mountain of hacks dance. They have a huge process advantage and can throw piles of money and talent at the process but they are stuck with optimization's made when computers where less than 1% as powerful.

<comment><USER3> We should distinguish between designing for a benchmark and designing for a set of workloads. Everyone choices representative workloads they care about and evaluate design choices on a variety of metrics from simulating execution of parts of those workloads.

Linpack is a common go-to number because, for all the flaws, it's a widely quoted number. E.g. used in the top500 ranking. It tends to let the cpu crank away and not stress the interconnect, and is widely viewed as an upper bound on perf for the machine. In the E5 case it'll be particularly helped by the move to AVX enabled cores, and take more advantage of that than general workloads. Realistic hpc workloads stress a lot more of the machine beyond the cpu. Interconnect performance in particular.

People like to dump on x86 but it's not that bad. There are plenty of features no one really uses and we still have around, but those features will often end up being microcoded and not gunking up the rest of the core. The big issue is decoder power and performance. x86 decode is complex. On the flipside, the code density is pretty good and that is important. Secondly, Intel and others, have added various improvements that help avoid the downsides. E.g. caching of decode, post-decode loop buffers and uop caches etc. Plus the new ISA extensions are much kinder..

<comment><USER4> The problem with x86 is when you scale the chips to N cores you have N copy's of all that dead weight. You might not save many transistors by say dropping support for 16 bit floats relative to how much people would hate you for doing so. However, there are plenty of things you can drop from a GPU or vector processor and when you start having 100's of them it's a real issue.

Still with enough of a process advantage and enough manpower you can end with something like the i7 2600 which has a near useless GPU and a ridiculous pin count and still dominates all competition in it's price range.

<comment><USER3> Is there a cost? Of course. But arguably it's in the noise on these chips. Knights Ferry and Corner are using a scalar x86 core derived from the P54C. How many transistors was that? About 3.3 million. By contrast, Nvidia's 16-core Fermi is a 3 billion transistor design. (No, Fermi doesn't have 512 cores, that's a marketing number based on declaring that a SIMD lane is a "cuda core", if we do the same trick with MIC we start doing 50+ cores * 16 wide and claiming 800 cores).

How can we resolve this dissonance? Easy -- ignoring the fixed function and graphics only parts of Fermi, most of the transistors are going to be in the caches, the floating point units and the interconnect. These are places MIC will also spend billions of transistors but they're not carrying legacy dead weight from x86 history -- the FPU is 16 wide by definition must have a new ISA. The cost of the scalar cores will not be remotely dominant.

I'm not sure why you are concerned about the pin count on the processor, except perhaps if you are complaining about changing socket designs which is a different argument. The i7 2600 would fit in a LGA 1155 (i.e. 1155 pins) whereas Fermi was using a 1981 pin design on the compute SKUs. The sandy bridge CPU design is a fine one. The GPU is rapidly improving (e.g. ivy bridge should be significantly better, and will be a 1.4 billion transistor design in the same 22nm as Knights Corner).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I see questions about why this is better than a GPU for anything. Two main things:

1\. The double-precision floating point performance is a lot better.

2\. Unlike GPUs which have baroque memory access restrictions and many performance cliffs, this is a much more familiar SMP architecture with a unified coherent cache hierarchy.

<comment><USER7> 1\. It's estimated to come out a year later than AMD's Radeon part which will boast similar double-precision floating point performance. Both could be delayed, though if Southern Islands comes out on time & Knights Corner gets delayed, by the time KC sees the light of day AMD or nVidia might have another part out by then that will offer even higher DPFP performance.

2\. I am not sold that modeling the cores after x86/SMP means special care won't be needed to feed the Intel MIC architecture properly. I'd like to see some real world numbers on purchasable hardware.

</comment></comment><comment><USER8> Heh. Article is nearly incoherent:

> If you're building a new system and want to future-proof it, the Knights > Ferry chip uses a double PCI Express slot. Chrysos said the systems are also > likely to run alongside a few Xeon processors.

</comment><comment><USER9> The memory bus must be saying "Great. Another 50 mouths to feed".

You have to design your program very carefully if you don't want the cores to starve.

</comment><comment><USER10> So it doesn't run the general x64 system architecture? Then how is this different from GPGPU? I thought NVIDIA broke a teraflop on a dual slot a while back (dunno if it was single GPU.) Slot based coprocessors have always been a _very_ niche kind of thing.

Basically, if I can't hook it up to my SSD array and also my GPU, then it's not a "real" computer -- like the reporter was talking about a laptop. And if I can't rent it by the hour from Amazon, then it's not really a good investment (Amazon already has GPU instances.)

Or, you know, maybe this time it will work, when every time before, a co- processor platform has failed...

</comment><comment><USER11> AMD Radeon HD 6990 already has over 1 TFLOPS performance double-precision, and there's no problem buying it, Intel is too late.

<comment><USER12> Yes there is no problem buying it, but have you ever tried programming in OpenCL? Complexity aside, GPGPU hits a big bottleneck when dealing with large datasets. There just isn't enough memory available on the GPU, and transfers to and from the device are costly.

<comment><USER13> There are AMD video cards with 4GB of memory these days and special cards have up to 16GB I understand.

<comment><USER12> 16GB isn't adequate for the work I've done on them. Genome assembly ( an O(n^2k^2) process ) generally has 100GB of data, each segment of which needs to be compared against each other segment ( O(n^2) ), and when comparing two segments each datum needs to be compared to each other datum ( O(k^2) ).

So while you can just transfer 4GB of data to the card at a time, it really doesn't cut it.

<comment><USER11> I'm sure Intel won't cut it either, PCI Express speed is limited, and RAM woudn't catch up with simple computation speed. Find a better algorithm.

</comment></comment></comment></comment></comment><comment><USER14> I'll be very interested to see how this does with raytracing.

</comment><comment><USER15> This was to be expected. In a classic disruptive innovation fashion, Intel is starting to move upmarket, where the profits are higher, and in a few years they'll be leaving the mobile and notebook/PC market to ARM.

</comment><comment><USER16> These aren't x86 cores, are they?

I mean 50 atom cores would be downright silly.

50 i3 cores, well then you might have something.

<comment><USER17> Yes, these are x86 cores. Actually quite a bit like the Pentium (p55c) with a 512-bit vector unit bolted on.

</comment></comment><comment><USER18> What is the significance of this over standard GPUs that can already do over a teraflop?

See table: <http://en.wikipedia.org/wiki/Northern_Islands_(GPU_family)>

<comment><USER3> The AMD 6990 has ~1.37TF double precision, but uses 2 GPU chips to do it, where this chip is that perf level.

It is difficult to get good performance out of the GPUs for a very wide range of highly parallel programs. Effectively, you are programming a part that is trying to give you mainly a graphics part, since that is where the volume is, with enough compute compromises to try to grow that market. MIC is designed to be a compute processor from the get go. How about this for a difference: it can boot linux all on its own! You can ssh into it and run programs. You can even run 'reverse offload' programs that call out to code on the CPU! Trying doing any of that with a GPU.

BTW, this MIC chip has a large number of cores (50+), these are real cores, and they're not doing the GPU marketing trick of counting SIMD lanes as "cores". You could multiply 50+ * 16 to get the equivalent number of GPU "cores". Each core is cache coherent, with a decent memory hierarchy designed for compute. There's no graphics tax on here.

I have much more expectation that Intel can leverage their massive process advantage to keep MIC ahead on compute performance each generation. It'll be a relief to have compute parts rather than repurposed GPUs.

</comment></comment><comment><USER19> I should probably get one of these for my laptop.</comment>


A parable about concurrency (demonstrated with comical cartoons) - <AUTHOR> http://www.smashcompany.com/technology/a-parable-about-concurrency-demonstrated-with-comical-cartoons <comment><USER2> The terminology in that article is avowedly nonstandard; I found it off- putting. "Parallelism/Concurrency is good when... Parallelism/Concurrency is bad when...".

The author cites feedback received in an interview to this effect, and then ignores it. I respectfully urge the author to reconsider this approach. Technical words have precise meanings, you can't go Blubbing[0] up at more technically precise language than you care to use and expect to communicate effectively.

For comparison, here's Concurrency and Parallelism explained by two Robs (with a bonus cartoon Gophers as well).

Rob Pike: Concurrency is not Parallelism [http://blog.golang.org/concurrency- is-not-parallelism](http://blog.golang.org/concurrency-is-not-parallelism)

Robert Harper: Parallelism is not Concurrency [https://existentialtype.wordpress.com/2011/03/17/parallelism...](https://existentialtype.wordpress.com/2011/03/17/parallelism- is-not-concurrency/)

Open each link in a new window and tile them, close them both when you finish reading/watching: that's concurrency.

Manage to read the article while watching the video at the same time: that's parallelism. :)

[0] I mean to dismiss something in the same manner as described in the Blub Paradox.</comment>


Is MSN Messenger Down? - <AUTHOR>

Adium isn't connecting to MSN, nor is Meebo. login.live.com is getting Service Unavailable errors.<p>Edit: looks like it's back up... ish. <comment><USER2> Yeah...maybe Microsoft shut down finally.</comment>


I Found Myself in a Command Line vs. GUI Meeting - old-gregg https://gravitational.com/blog/command-line-vs-gui/ <comment><AUTHOR> The article title suggests some sort of tension or comparison of "command line interfaces" vs "GUI interfaces".

It is not that at all.

The article seems more like a product sales pitch disguised as a tense "discussion" about an SSH client offering a new web based terminal.</comment>


JsLinux: This time with an EXT2 local storage Block Device - <AUTHOR> http://stud.hro.nl/0814604/jslinuxdemo/

<comment><USER2> This is pretty cool. What are the potential use cases?

</comment><comment><USER3> Nice! Little strange that there is no mention of the release of the code on Fabrice Bellard's site.

</comment><comment><USER4> Cool, but what is the username/password?

Welkom bij JS/Linux

JS/Linux login:

<comment><USER5> 'root', no password.

</comment></comment><comment><USER6> would be interesting to implement a tun/tap interface that use websocket.

<comment><USER7> As awesome as JSLinux is, until it gets networking i/o, there's little real- world use for it. Once it does though, the floodgates of awesome will open up.

<comment><USER8> <http://www.youtube.com/watch?v=MEsmgHrKQYM></comment></comment></comment>


Real-world HTTP/2: 400GB of images per day - <AUTHOR> https://99designs.com.au/tech-blog/blog/2016/07/14/real-world-http-2-400gb-of-images-per-day/ <comment><USER2> Founder of NuevoCloud here. If I read this right, you guys used Cloudflare for http 2. So let me ask you this, when you did your comparison, were all of the images cached (ie: x-cache: hit) at the edge?

The reason I ask is because cloudflare, last I checked, still hasn't implemented http2's client portion. So when a file is not cached, it does this:

client <\--http2--> edge node <\--http 1.1--> origin server.

Http2 is only used for the short hop between the client and edge node.. then the edge node uses http 1.1 for the connection to the origin server, which may be thousands of miles away.

In other words, in your test, depending on the client location and the origin server location.. your test may have used http 1.1 for the majority of the distance.

If you guys want to rerun this test on our network, we use http2 everywhere... your test would look like this on our network:

client <\--http2--> edge node (closest to client) <\--http2--> edge node (closest to server) <\--http2--> origin server.

So even if your origin server doesn't support http2, it'll only use http 1.1 over the short hop between your server and the closest edge node.

You're welcome to email me if you want to discuss details you don't want to post here.

Edit: I should also mention, that we use multiple http 2 connections between our edge nodes and between the edgenode and origin server... removing that bottleneck. So only the client <\--> edge node is a single http 2 connection.

<comment><USER3> To the best of my knowledge you are correct about how CloudFlare works. For context this data was collected over the period about a month on real production pages with significant traffic.

The edges were well and truely primed.

<comment><USER2> although cloudflare doesn't manage caches on a per account basis. Each PoP has a single LRU cache that's used for all customers. In other words, even if you've primed it, your files may have been pushed out of the cache by a larger customer.

In order to know this hasn't occurred, you really have to check the hit rate cloudflare is reporting (for static files that rarely change, this should be near or at 100%)... and when you're doing side-by-side comparisons (like the speed index), you have to actually check the x-cache headers to verify that a cache miss hasn't occurred. Otherwise, you wouldn't actually know that a significant portion of traffic isn't being sent over http 1.1 (because of cache misses).

<comment><USER4> >Each PoP has a single LRU cache that's used for all customers.

Is this true for all tiers of paid accounts? Can someone from CF chime in here?

<comment><USER5> As recently mentioned by a CloudFlare employee in this post ([https://news.ycombinator.com/item?id=11439582](https://news.ycombinator.com/item?id=11439582)):

> We cache as much as possible, for as long as possible. The more requested a > file, the more likely it is to be in the cache even if you're on the Free > plan. Lots of logic is applied to this, more than could fit in this reply. > But importantly; there's no difference in how much you can cache between the > plans. Wherever it is possible, we make the Free plan have as much > capability as the other plans.

This does not confirm the exact statement but at least points in this direction.

</comment></comment></comment></comment></comment><comment><USER6> I did not do any real tests and I might be completely wrong etc. but it seems to me that http2 is going to perform poorly over wireless links like 3g.

With http1 one had N tcp connections, and with the way tcp slowly increases the bandwidth used, and rapidly decreases it when packet is lost, even if any packet were dropped (which will happen quite a lot on 3g) other tcp streams were not delayed, or blocked, and can even utilize the leftover bandwidth, yielded by the stream that lost the packet.

With http2 however there's one tcp connection, so dropped packets will cause under-utilization of the bandwidth. On top of that dropped packets will cause all frames after them, to be delayed in kernel receiving buffer until the dropped packet is retransmitted, while in http1 case they would be available at the app level right away.

HTTP2 being implemented on top of TCP always seemed like a weird choice. It should have been UDP, IMO. That's why network accelerators like PacketZoom make so much sense. Note: I work in PacketZoom, I did not do any in-depth research on HTTP2, and this is my opinion, not necessarily of the company.

<comment><USER7> This is a real worry, but as with all things the actual behaviour of H2 on lossy networks is more complex than that.

TCP's congestion control algorithms don't work that well when you have many TCP streams competing for the same bandwidth. This is because while packet loss is a property of the _link_ , not an individual TCP stream, each packet loss event necessarily only affects one TCP stream. This means the others don't get the true feedback about the lossiness of the connection. This behaviour can lead to a situation where all of your TCP streams try to over- ramp.

A single stream generally behaves better on such a link: it's getting a much more complete picture of the world.

However, your HOL blocking concern is real. This is why QUIC is being worked on. In QUIC, each HTTP request/response is streamed independently over UDP, which gets the behaviour you're talking about here, while also maintaining an overall view of packet loss for rate limiting purposes.

<comment><USER8> > _can lead to a situation where all of your TCP streams try to over-ramp. ... > A single stream generally behaves better on such a link: it 's getting a > much more complete picture of the world_

Multiple HTTP connections work better for exactly this reason, because they are 'stealing' bandwidth from streaming video by 'not playing fair'. For example, 6 connections ramping back up bandwidth at 6x the rate of a single connection or sometimes only scaling back on 1/6th of the streams at once.

...which is fine because multiple parallel HTTP connections is usually a browser doing so for short-lived data transfers for active users and it is not the bulk of the data on the network.

</comment></comment></comment><comment><USER3> Hey all, I'm the author of that blog post. I'll be floating around for a while, happy to answer any questions.

<comment><USER3> I'm out y'all. Thanks for all the support. Feel free to follow up on Twitter at @xzyfer

</comment></comment><comment><USER9> I don't think that the server is in charge of priorisation here. The server can do it, but there is no reason to push this responsibility onto the server when the browser can do it much better (for example the server can't know what's in the viewport).

I expect this will be quickly sorted out by more mature HTTP/2 implementations in browsers. Downloading every image at once is obviously a bad idea, and I expect such naive behaviour will soon be replaced by decent heuristics (even just downloading eight resources at once should be better in nearly all cases)

<comment><USER10> I think the real solution hear is for the browser to be able to communicate some sort of priority to the server, without having to download a limited number of files at once.

<comment><USER3> Browser do currently do this. H2 has two types of prioritisations: weighted, and dependency.

All browsers implement weighted resource prioritisation and weigh resources by content type. This is a hold over from what they do for HTTP/1 connections.

Firefox has dependency resources prioritisation. [https://bitsup.blogspot.com.au/2015/01/http2-dependency- prio...](https://bitsup.blogspot.com.au/2015/01/http2-dependency-priorities- in-firefox.html)

The spec purposely leave how these heuristics should work to the implementor. Things will change and implementations will diverge over time.

The server ultimately being in control means we can tell the server what resources are important for specific pages with absolute knowledge of the page.

<comment><USER10> Oh wow, that's cool. Do you know if servers currently support this? Would this mostly be useful on a network level or do you think it would also be useful for like trying to be more intelligent about scheduling?

<comment><USER3> It's hard to say for sure. Server implementations can vary wildly, make sure to test any implementation closely. I know from talking to CloudFlare that their implementation respects browser hints. Their implementation is also open source.

</comment></comment></comment></comment></comment><comment><USER11> One way to "solve" the time to visual completion would be to make all the images, but especially the larger images, progressive scan. For very large images, the difference in visual quality between 50% downloaded and 100% downloaded on most devices isn't noticeable, so the page would appear complete in half the time.

<comment><USER12> If there's a way to tell it not to render until x% downloaded, sure. Otherwise slower connections see the low-q versions for a while and it can disconcerting. Either to some users or some PMs.

<comment><USER3> This is correct. Visually completion will not be achieved until the entirety of the images within the viewport are downloaded.

However progressive jpegs could improve initial paint times. These are dynamic so each page would have it's own unique (although related) profile.

</comment></comment></comment><comment><USER13> This seems to bode badly for CDNs versus own tuned servers, unless there's a way for origin websites to provide hints on response ordering?

<comment><USER14> damn, CloudFront already doesn't expose many tunables, so yeah, this isn't going to work.

Starting to wish Appcache _manifest_ actually was made to work and that could use used as a queue somehow to prioritise important assets on a Webpage.

<comment><USER15> ServiceWorkers are the app cache done right. [https://github.com/w3c-webmob/ServiceWorkersDemos](https://github.com/w3c-webmob/ServiceWorkersDemos)

<comment><USER14> My point is that you can't map Service Workers onto a simple manifest, i.e. a list of resources the httpd needs to push as a priority.

You "kindof" can with a Appcache "manifest". Stretch of the imagination, I know.

</comment></comment></comment></comment><comment><USER16> Did I read this right that http1 was with cdn A (unnamed?) and http2 was with cdn B (cloudflare)?

If so, you really can't draw any conclusions about the protocol difference when the pop locations, network designs, hardware and software configurations could easily have made the kinds of differences you're seeing.

<comment><USER3> You read it correct.

By not moving our render blocking assets like CSS, JS and fonts over to the http/2 we rule out performance changes due to improvements to head of line block.

Our images were always on a separate hostname so the DNS lookup over is the same. We also did some initial benchmarking and found the new CDN to be more efficient than the old one.

</comment></comment><comment><USER17> Comparing two protocols using different providers, isn't that a bit comparing pears and apples? And i have a doubt, which could be bad assumption, but that it is on hardware you control or own and what exactly runs on it, and potentially which other parties use it.

</comment><comment><USER18> Great writeup, and interesting seeing where http2 performed worse. Definitely going to refer to this as I update my backend to http2.

<comment><USER3> Thanks mate, really appreciate it.

</comment></comment><comment><USER19> I'm really looking forward to see how much HTTP/2 will increase performance for my Bitcoin payment channel server: [https://github.com/runeksvendsen/restful-payment-channel- ser...](https://github.com/runeksvendsen/restful-payment-channel-server/)

Just now I finished separating the front-end and back-end - by a RESTful protocol - and this roughly halved performance compared to using a native library (from ~2000 payments/second on my laptop to ~1000). I expect HTTP/2 to make a greater percentage-wise difference here, although I admit I really have no idea how much, say, ZeroMQ would have reduced performance, compared to cutting it in half using HTTP/1.x.

I expect HTTP/2 to make a much greater difference in high performance applications, where overhead becomes more important, which static file serving doesn't really hit. So I think RESTful backend servers will see a much more noticeable performance increase, especially since, if you use Chrome at least, as an end-user you already get many of the HTTP/2 latency benefits through SPDY.

<comment><USER20> Aren't there more performant options than restful these days? Any particular reason why you didn't choose those?

Would that be a good case for websockets?

<comment><USER19> There are definitely more performant options. I considered ZeroMQ for a while, and almost decided on it, but went for HTTP/REST because of the built-in error handling, and request-response style (as far as I can see, I would have to implement all of this if I chose to use ZeroMQ).

I also chose HTTP because, at the end of the day, I still get almost ~1000 payment per second after the change (on a laptop). VISA handles 200k payments/second at peak, so that's peak VISA levels on 200 MacBook Pros.

I see I might have misspoke when I said "front-end". It's really the front-end (logic part) of the backend server, which now comprises two parts: stateless logic ("front-end") and database (stateful) backend. So I haven't considered Websockets.

</comment></comment></comment><comment><USER21> Some solutions:

\- Serve less data. The best speedup is when there's no more data to download and if the throughput for clients is maxed out, then decreasing page weight helps.

\- Use async bootstrap JS code to load in other scripts once images are done loading or other page load events have fired.

\- Load less images in parallel, use JS to load one row of images at a time.

\- Use HTTP/2 push (which CloudFlare offers) to push some of the images/assets with any other response. Push images with the original HTML and you'll start getting the images to browser before it even parses the HTML and starts any (prioritized) requests.

<comment><USER22> Wouldn't the standard solution of lazy loading images (and prioritizing critical css) help. Since they are now trying to load everything on a big page, they should only be trying to load everything above the fold.

<comment><USER21> Yes, the basic approach is the same. There's limited bandwidth and they have too many image assets going through the pipe at the same time. They can easily control this by just loading a few at a time, whether that's the first page or row or whatever (probably based on testing to see what "feels" the fastest).

It's a tried and tested approach and much better than just sending everything in the HTML in a single blast. There are hundreds of image-based sites out there, they all do this as an optimization.

</comment></comment></comment><comment><USER23> We've recently moved to Google Cloud Storage from AWS because of http/2\. We had a bottleneck of the browser waiting when serving multiple large (8+files * 10mb+each).

I'm wondering if 99designs looked at any sort of domain sharding to get around the timing issues. If I understand correctly, wouldn't this get around the priority queue issue? Your js,fonts, etc. coming from a different address than your larger images, would create completely separate connections.

I'm not completely sure this would get around the issues mentioned, but I'm curious if it was looked at as a solution.

<comment><USER3> The priority queue isn't the issue. In fact the priority queue is what kept our first paint times tanking because browsers prioritised render blocking resources instead of images.

The issue was due to the variance of image size. An image that is significantly larger than the page average will be loaded slower since all images get an equal share of bandwidth (priority). Adding sharding wouldn't help since the client only has a fixed amount of bandwidth to share and all images would still get the same share of it. Sharding could help if the bandwidth bottle neck was at the CDN but that's rarely going to be the case.

</comment></comment><comment><USER24> Excellent and in-depth article. Thank you for sharing!

Hopefully we'll see a follow up with future changes and tweaks both from webservers and browsers.

<comment><USER3> Thanks mate, glad you enjoyed it.

</comment></comment><comment><USER25> I thought that HTTP/2 didn't fix head-of-line blocking and this was why QUIC ([https://www.chromium.org/quic](https://www.chromium.org/quic)) existed.

From the project page:

Key features of QUIC over existing TCP+TLS+HTTP2 include

* Dramatically reduced connection establishment time

* Improved congestion control

* Multiplexing without head of line blocking

* Forward error correction

* Connection migration

<comment><USER26> IMHO HTTP/2 solves HOL blocking partly. It will allow other streams to proceed if one stream is blocked due to flow control (receiver doesn't read from the stream). E.g. if you have multiple parallel downloads over a single HTTP/2 connection one blocked/paused stream won't block the others.

However it doesn't have abilities that will allow individual streams to proceed if some packets are lost that only hold information for a single stream.

</comment></comment><comment><USER27> Thanks for posting your findings - very useful data. It would be interesting to see the Webpagetest waterfalls in greater detail if you're able to share that.

You planning to use your resource hints to enable server push at CDN edge?

<comment><USER3> Server push at the edge is problem atm. Current push semantics require the HTML document say which resources to push. That's an issue if you're serving assets off a CDN domain.

Asset domains make less since with h2 from a performance perspective but there are still security concerns that need to addressed.

<comment><USER27> Good point if you're using push for page content that varies, like images in the the 99designs portfolio and gallery. That gets into dynamic caching territory.

As a first step, I'm focused on using push to cut latency between TTFB and processing of render-blocking static assets. Serving those from same domain as the base page, it should be easy for origin to supply edge with the list of resources push. Either in the HTML or with the `link` response header. It also means my critical assets are not longer behind a separate DNS lookup.

In the design gallery, this type of push approach could help you regain control of loading priority and get your fonts loading before that wall of images.

<comment><USER3> The priority queue isn't the issue. In fact the priority queue is what kept our first paint times tanking because browsers prioritised render blocking resources instead of images.

The issue was due to the variance of image size. An image that is significantly larger than the page average will be loaded slower since all images get an equal share of bandwidth (priority).

We could further improve first paint times by pushing render blocking resources but we'd need to be serving those resources off the 99designs domain (with current push implementations). This opens us up to a class security issues we avoid by having an asset domain i.e. types of reflected XSS and serving cookies on assets.

For now we'll wait for the webperf working group to address the limitations with server push semantics.

<comment><USER27> Interesting note on the impact of image size variation on queue, thanks for elaborating.

Serving those resources from the 99designs domain is worth a look. I considered the cookies and security trade offs as well. I found H2 compressed cookies enough to perform better than a separate cookieless domain for static assets, due to the DNS savings. DNS times can be bad at high percentiles. Reflected XSS addressed with a Content Security Policy. But I'm fortunate to have user base that supports CSP well.

</comment></comment></comment></comment></comment><comment><USER28> we also did a far less sophisticated HTTP/2 reality check: [https://blog.fortrabbit.com/http2-reality- check](https://blog.fortrabbit.com/http2-reality-check)

about the same result: real world performance boost was not soooo big.

</comment><comment><USER29> And still no OpenSSL 1.0.2 nor ALPN on most distros such as Debian Jessie... kinda sucks

<comment><USER30> It's available in jessie-backports since 2016-07-02, see [https://packages.debian.org/jessie-backports/libssl- dev](https://packages.debian.org/jessie-backports/libssl-dev)

Given that jessie is stable, OpenSSL will not be updated to a newer version, only security updates will be made available.

What I'm trying to say: you're never going to get it on jessie, unless you enable backports, at which point you'll have it readily available.

Hope that helps

<comment><USER29> oh nice, thanks for the hint. didn't check the jessie-backports within the last two weeks :-)

</comment></comment></comment><comment><USER31> This is petty and inconsequential, but I really wish they used a section header called "Conclusion" instead of "Take Aways".

<comment><USER32> You're right.</comment></comment>


Subliminal Ad Sears BMW's Logo Into Your Mind's Eye - <AUTHOR> http://www.fastcodesign.com/1662910/subliminal-ad-sears-bmws-logo-into-your-minds-eye <comment><USER2> In case you're interested, there was much discussion when this was submitted yesterday:

<http://news.ycombinator.com/item?id=2011302></comment>


1952 Hoffmann: The Worst Car Ever Built - <AUTHOR> https://www.youtube.com/watch?v=Y16ObVRvgOE <comment><AUTHOR> I've watched this video at least have a half dozen times over the last few months and it always cracks me up.</comment>


End of Windows XP support puts ATMs at risk - <AUTHOR> http://www.ft.com/cms/s/0/300c8788-abcd-11e3-90af-00144feab7de.html#axzz2wWuzScG0

<comment><AUTHOR> I've read that ATMs use Windows XPe (for embedded systems) and that the end of support is for standard XP.

Anyone can confirm this with some source?</comment>


In India, Prism-like Surveillance Slips Under the Radar  - <AUTHOR> http://cis-india.org/news/time-world-anjan-trivedi-june-30-2013-in-india-prison-like-surveillance-slips-under-the-radar <comment><USER3> India has a very complicated relationship with censorship that's compounded by underlying communal and religious tension. It looks idiotic when you hear about people being arrested for tweets and likes, but what gets lost is the fundamentalist barbarianism that underlies it: the grim truth that people might die otherwise. That unemployed youth will take to the streets and violently protest at every imagined slight to their <insert religious ideal / figurehead / motto / policy here >. That leaders will tacitly encourage the violence and terrorism that their own minions commit.

We don't care too much about privacy rights yet because we haven't got that far on whatever pyramid diagram of priorities you'd judge by. A majority of the population lives in poverty, is hungry and thirsty, does not have access to non-toxic food and water. The urban population is still very concerned with making ends meet, putting their kids through college and hoping that their dreams will be fulfilled through the lives of their offspring.

Those with money, influence and clout don't care. They can either simply buy their way out of this kind of monitoring or laugh at it over dinner.

Besides, we really don't have the capability to pull this off well enough to be a danger to anyone.

<comment><USER4> Countries have never morphed from oppressive regimes into democratic wonderlands without violent overthrows in between. The idea that you would oppress now while you are poor so you can be free later on is bizarre.

<comment><USER5> Fact is, in India, the poor are _already_ oppressed, just nobody realizes it. They have no real rights, they have no food and they have no prospects. The only thing they have is votes, which are a sham, because they are given away willingly to the politician that makes the most encouraging promises, which, of course, are never fulfilled. However, when your constant concern is "where's our next meal coming from", keeping track of empty promises is probably pretty low on your list of priorities.

So, the real choice is being oppressed and desperately poor... or being oppressed and making progress. I personally believe democracy is not suited to India at the moment because (or so it seems to me at least) politicians spend all their efforts in fighting amongst themselves to stay in power (and on the side, siphoning away money for themselves), while no real progress ever happens.

The rich get richer, the middle class continues along in blissful ignorance, and the poor get poorer.

On the other hand, in China (or so, again, it seems to me) politicians do engage in corruption for selfish reasons, but the rest of the time they are focused on _bringing their country ahead_ , and I believe that's in a big part because they don't have to worry about staying in power.

I, for one, would welcome an "oppressive" regime if it meant progress. Oppression is not a good thing, but when your alternative is half a billion people starving every night, I don't think it's all that bad.

<comment><USER6> >I personally believe democracy is not suited to India at the moment

(I don't know which oppressor you want to hand over the country to.)

People vote along lines of caste and religion. People vote for money and liquor. But people vote. They throw parties out of power when they want to. A benevolent, even if he promises to turn India back into a golden bird, will not want you to vote.

Democracy is often a mess, but is better than the rightless life under a benevolent. India is in a mess, lets not make it any worse. There are alternatives if you look close. You can educate people, unite instead of divide people. You can contest elections or vote for the voices of sanity. There will be difficulties and we will always be a work in progress, but we will have to try. Democracy is not a panacea, you still have to work to make it better. Giving away all of your rights and responsibilities, hoping some benevolent oppressor will save you is not the way to do it.

Many of my friends have been saying the same thing. Indian messageboards are overflowing with hate. A certain benevolent has been identified as well. One who has proven his credentials. The chanted name has divided a state successfully, and I fear permenantly, across religious lines. The bet is to do the same thing across the country. If you don't feel the poisonous atmosphere, it is because you are wilfully ignoring the obvious and concentrating on the made up.

How long should we continue living as people of a certain religion or caste? How long should we continue hating people who are of a certain religion or caste, knowing that the other person had as little a choice in selecting their religion/caste as we had in selecting ours?

Xenophobia has never been India's big problem, but we know it simmers in most households, in one form or the other. We take pride in what our ancestors did and forsake everything to maintain that pride. We close our eyes trying to fit in, not believing that this life may be the only life we get. That there may be no rebirth or afterlife. That love is its own reward and hate its own punishment.

</comment></comment></comment></comment><comment><USER7> A lot of people here saying that the India govt is too incompetent to do this.

This is naive thinking. The indian govt might be slow and corrupt but rest assured when it comes to implementation they are actually quite decent. See the amount of work that has gone into computerization of various things like personal tax, property tax, education etc. Other governments can move much more quickly because they only have 1% of India's population. India has so much paper records and most of them lost. For example, can you imagine what it takes to move the property tax system online? Most land records don't exist on paper with the goverment. This is not just a data entry and technology problem anymore.

No, what I am worried about is that if they pull if off, you cannot keep the politicians off this. And it's guaranteed to be misused. It's dangerous to build a monitoring system because a security hole in such things endangers everyone. If the richest companies in the planet like apple, google, sony cannot build secure governments, I highly doubt government can.

</comment><comment><USER8> This is particularly bad for a country like India where the police already has too many powers: they don't need a warrant for many things. By "need", I mean it's not that the Constitution doesn't require them to, but it's not enforced. So much so, if you are a "no-one" (means you don't have any "political connections"), the police can come to your place, search it, and arrest you and put you in lockup. All without requiring a warrant. Good luck complaining. (Of course the police requires a warrant when dealing with politicians, since they can't touch them.)

Now given the police state India already is, this is more dangerous. Why? Because the police has too many powers, they don't need warrants and now the state has the capability to spy completely on its citizens. I can only see glaring human rights violation coming out of this.

<comment><USER9> Rightly said. If citizens don't raise such issues soon enough, politicians and other bad guys will make India fall.

</comment></comment><comment><USER10> This makes all the difference:

"Yet India's Central Monitoring System, or CMS, was not shrouded in secrecy"

Doesn't make collecting all that data ok, but the fact that it's not all cloak and dagger means that people know what the government is doing in their name and they can vote for a change if they disagree.

<comment><USER11> India has a very bad history in dealing with such issues esp when they involve technology. Remember when they asked Google, Facebook, Twitter et. al. to preemptively delete undesired messages?

<comment><USER10> To clarify again, I am not saying this is a good thing. I was just pointing out what seemed to be a major point of difference between this and the US situation.

A lot of the unrest and anger here is because mass surveillance was approved to be carried out in secret and the companies were not even allowed to talk about what type of data they were providing to the government.

<comment><AUTHOR> The Government is trying to do the same thing with similar tactics as the US counterpart. They don't make any noise, or put any effort into making people aware of what is actually going to be done to them. As a result, there is virtually no media coverage, and only a couple of vigilant people who care about it are even aware of this.

They just barely mention it in passing, is ambiguous and can be interpreted however they want it to: [http://pib.nic.in/newsite/erelease.aspx?relid=70747](http://pib.nic.in/newsite/erelease.aspx?relid=70747), like: "Hey, we are going to monitor every aspect of your life, and keep the records forever, and will be used against you for the interests of various corrupt people; in effect, shutting you up. No big deal :)"

</comment></comment></comment></comment><comment><USER12> Not exactly on this topic, but somewhat relevant when I see articles like these from Indian media.

Media in India is weird in how it feels the need to emulate American events etc and draw parallels to illustrate their case. It's like they need a reinforcement framework to validate what they are saying. And for this, they love to look up to everything American (it's a complement to USA I guess, but also shows the insecurity india has towards modernisation). For example.. media routinely labels controversies as 'something-gate' when Watergate had nothing to do with india, and indeed most people in India probably don't know anything about it. The mumbai terrorist attacks are referred to as 26/11\. Now their government surveillance is 'PRISM-like'.

India is insecure like this and looks for validation by trying to find 'standard' versions of what they are talking about, in the form of an American parallel. It's regular enough that I thought it worth pointing out.

India used to be like this before too, with British parallels. I guess the colonial hangover in India has proven to be a very long one. Be more confident in your own ways India; to improve and to progress, you don't always need to emulate.

</comment><comment><USER13> The real problem is, recently there are lot of instances in India where government is trying to enforce restrictions around social media more or less to protect its own interests. There are no clear guidelines regarding how you'll classify something as free speech or hatred speech. Most politicians are too ignorant about internet, social media and the emerging crowd power, and they are very anxious about the same. Giving such a system for a set of people who don't really understand what it is and how it can be used, is the real danger. They'll always use it to protect their interests.

</comment><comment><USER14> India's media is the only one allowed to openly lie on television. True stories are never shown. And me, who laughed on conspiracy theories like "Illuminati" as childish imagination, I know how foreigners are ruling India even today. To keep control over the population you have to first monitor their activities! This is what they do

<comment><USER15> > India's media is the only one allowed to openly lie on television.

USA's FOX News sued in court for the right to lie... and they won.

</comment></comment><comment><USER16> I am really not too worried about this because - I know that corruption and incompetence will ensure this system never comes into place effectively.

On the few occasions that the government has tried to ban certain URLs - <USER2> almost always been simple DNS filters that can be bypassed by using Google DNS.

</comment><comment><USER17> can the indian govt can do anything? I haven't seen it can execute anything. so, don't worry about such programs, they will build something, which will be so useless, it will be only used to bill the govt.

<comment><USER18> yes they can do anything. Anything to protect their interests.</comment></comment>


Twitter Turns Ugly Over PR Person's Idiotic Tweet - <AUTHOR> http://mashable.com/2013/12/20/justine-sacco/

<comment><USER2> wow! usually I try very hard to steer clear of stereotypes but... woman? check blonde? check vapid? check limited vocabulary limited to inane comments? check

she works as a PR? you don't saaaaaaaaaaaaay

a cache of her twitter shows this was not isolated but just the latest in a pattern

[http://webcache.googleusercontent.com/search?q=cache:rVzMZz0...](http://webcache.googleusercontent.com/search?q=cache:rVzMZz0Qy30J:https://twitter.com/JustineSacco+&cd=4&hl=en&ct=clnk)

<comment><USER3> Your comment is pretty offensive.

<comment><USER2> Stephen Fry put it better than I could:

It's now very common to hear people say, "I'm rather offended by that", as if that gives them certain rights. It's no more than a whine. It has no meaning, it has no purpose, it has no reason to be respected as a phrase. "I'm offended by that." Well, so fucking what?'

</comment></comment></comment><comment><USER4> It's totally fair for people to go crazy and "turn ugly" on her on Twitter, she has cultivated her entire professional image via Twitter and other social media.

Live by the Twitter, die by the Twitter.

</comment><comment><USER5> Interesting world and times we live in. Somehow, though, I can't shake the feeling that it's all manufactured, however unlikely that may be. I mean, how could someone be SO out of touch?

On the plus side, it's bringing awareness to a real issue that's often brushed under the rug by most.</comment>


2038: Only 21 years away - <AUTHOR> https://lwn.net/SubscriberLink/717076/4c3593aa4cad8e66/ <comment><USER2> This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.

<comment><USER3> My retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.

<comment><USER4> Yes, I know some of us will never retire. 8000 years in the future career planning is an interesting thing to think of though. 8000 years ago the only thing that was going on was some neolithic agriculture. Domestication of the Jungle Fowl (modern day chicken) in India and the beginning of irrigated agriculture in Sumeria were probably the biggest news items of that millennium. I guess someone from 8000 years ago could have said he'd be raising chickens or doing irrigated agriculture in 8000 years and wouldn't have been wrong had he lived that long. Makes me think of F.H King's book "Farmers of Forty Centuries" about how Chinese agriculture has been farming the same fields without artificial fertilizer for 4000 years.

<comment><USER5> There was almost certainly some forms of relatively advanced seafaring 8000 years ago possibly including skin boats, sails and paddles, ropes, sealants and astronomy. Also, fairly sophisticated metallurgy was widespread with at least silver/iron/gold, possibly bronze. Writing was known to some cultures. Horses, camels and water buffalo were likely all domesticated. Use of drying/smoking for preservation and curing of meat. Yogurt may have been known in some areas. Advanced pottery. Probably nontrivial herbalist / medicinal / architectural / construction knowledge. Plus of course trapping, fishing, textiles, stonework, etc.

<comment><USER6> I can believe seafaring, astronomy, and metallurgy. But yogurt? Now you're just pulling my chain.

<comment><USER7> I don't know how much you know about yogurt, so I apologize in advance if this sounds condescending; but yogurt has been eaten since at least the 5000s BC, and is easy to produce, probably even by accident. It's obtained by controlled souring of unpasteurized milk; clabber, which is almost too sour to be edible but is safe to eat if you can stand the taste, comes from spontaneous souring.

Fernand Braudel (in _The Structures of Everyday Life_ ) talks of how it was the staple food of the poor in Turkey, and I think in Persia. US commercial yogurt is weak and sugary; the Eastern variety is much more lifelike.

</comment></comment></comment></comment></comment></comment><comment><USER8> Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

<comment><USER9> Think about how much entropy will build up in systems over 292 million years. Systems thousands of years old will be underneath newer systems hundreds of years old.

The AI's will be scrambling to fix the problem.

<comment><USER10> the scenario from "accelerando" is more plausible, where an AI rebuilt itself from scratch to eliminate a thompson "trusting trust" hack.

<comment><USER11> Man, the plot summary of Accelerando sounded so good but I couldn't get past the _writing_. That dense name dropping of random tech terms was a bit much in particular.

<comment><USER10> i found the writing very fun to read, but it's definitely a matter of taste.

</comment></comment></comment></comment></comment><comment><USER12> This is not a problem for 20 years from now, I've already had to find and fix 2038 bugs ... there was an openssl bug (now fixed) in which cert beginning and ending date math was done in 32-bits ... certs with an end date from a little after 2038 would fail when compared with the current time.

Fortunately for me there was already a fixed OpenSSL already available once I'd found the bug in it.

</comment><comment><USER13> > statx() will serve as the year-2038-capable version of the stat() family of > calls

Does this seem horrible to anyone else? Why not fix stat()? Does this syscall have to be so highly preserved even when it will be broken?

One of the advantages of the OpenBSD approach of being able to make intrusive changes saw their time_t made 64-bit in the 5.5 release in 2014.

[https://www.openbsd.org/55.html](https://www.openbsd.org/55.html)

Admittedly this is much harder for Linux as they can't make the change an verify in a single place due to the separation of kernel and userland/ the fact Linux has many distros.

<comment><USER14> In Linux kernel land, the golden rule is to never break the userspace ABI. Yes, it might happen, but it's _never_ intentional, unless there's no other choice (glaring security issue for instance).

<comment><USER13> I know and understand the reasoning for this, I just don't like it. I am a BSD fan, so I indulge in a land where such ABI breaks are possible. In a fantasy land I would like to see the Linux community coming up with a way to deal with ABI breaks. Not that I think such breaks are to be taken lightly but they are sometimes necessary. Such as this case.

<comment><USER15> The problem is because Linux is just a kernel (not an entire system like BSDs) _the syscall ABI is the actual kernel API_. If you break it, you break the world.

On BSDs, or Window, or most every OS, there's a base "userland" library (e.g. libc) which serves as the kernel API and hides whatever ABI specific syscalls use, Linux doesn't have that.

<comment><USER16> That only moves the problem outwards; instead of having to keep compatibility within the syscall ABI, you have to keep compatibility within the "base userland library" ABI, which is probably much larger (for instance, printf is not a syscall).

<comment><USER15> > That only moves the problem outwards

It also moves it to a place where you can have somewhat abstracted types (so chances are the client will work with just a recompile as it picks up the updated typedef), you can much more easily prepare the transition by e.g. using various flags or even trying alternatives beforehand (for instance OSX originally added a stat64 call before before rollbacking that choice and using macros to transition stat to 64b), and you are able to stop before a completely mangled syscall is actually attempted (by checking for some version symbol which must be set if you compiled for the 64b version of the various syscalls).

</comment></comment></comment></comment></comment></comment><comment><USER17> Is there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596).

64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe came into existence, but instead the UNIX time format is shackled to be within ~68 years of 1970.

<comment><USER18> If you told the original UNIX developers that there was even the slightest chance their system might still be in use in 2038, they probably would have called in some large, friendly men in white coats to haul you away.

Add to that the fact that memory was very much _not_ cheap at the time. Memory for the PDP-7 (the first computer to run UNIX) cost $12,000-20,000 for 4kB of memory. In 1965 dollars. In 2017 terms, that means that wasting four bytes had an amortized cost of _three hundred to six hundred dollars_. And that's for _each_ instance of the type in memory.

<comment><USER19> The year 2038 problem is actually younger than unix.

The first definition was 60th of seconds since 1970-01-01T00:00:00.00 stored in two words (note that a word is 18 bit on a PDP-7!). That definition was later changed.

Also Linus could have defined `time_t` to be 64 bit when he started linux.

[https://en.wikipedia.org/wiki/Unix_time#History](https://en.wikipedia.org/wiki/Unix_time#History)

[http://aaroncrane.co.uk/2008/02/unix_time/](http://aaroncrane.co.uk/2008/02/unix_time/)

<comment><USER20> I'm not even sure there was a standard 64-bit type for C in 1991... Or how well compiles on PC would support that.

<comment><USER21> There wasn't - the largest minimum integer size from C90 (ANSI C) was long, with at least 32 bits. "long long" was agreed upon at an informal summit in 1992 as an extension 64 bit type on 32 bit systems until it was standardised in C99 (but already existed in several compilers at that point, including GCC).

So GCC _may_ have had 'long long' already when Linus started working on Linux.

</comment></comment></comment></comment></comment><comment><USER22> Let's move to Urbit's 128 bit system: [https://github.com/urbit/urbit/blob/master/include/vere/vere...](https://github.com/urbit/urbit/blob/master/include/vere/vere.h#L762)

        /*  Urbit time: 128 bits, leap-free.
        **
        **  High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012)
        **  Low 64 bits: 1/2^64 of a second.
        **
        **  Seconds per Gregorian 400-block: 12.622.780.800
        **  400-blocks from 0 to 0AD: 730.692.561
        **  Years from 0 to 0AD: 292.277.024.400
        **  Seconds from 0 to 0AD: 9.223.372.029.693.628.800
        **  Seconds between 0A and Unix epoch: 18.104.22.168
        **  Seconds before Unix epoch: 9.223.372.091.860.848.000
        **  The same, in C hex notation: 0x8000000cce9e0d80ULL
        **
        **  New leap seconds after July 2012 (leap second 25) are ignored.  The
        **  platform OS will not ignore them, of course, so they must be detected
        **  and counteracted.  Perhaps this phenomenon will soon find an endpoint.
        */

</comment><comment><USER23> I wonder how much attention this will get from the general public and non- technical managers? After all, programmers predicted doom for Y2k, and then "nothing happened".

This is almost the same situation, except I assume slightly less understandable to a non-programmer (you have to understand seconds-since-1970 and why we'd do that instead of storing the date as text, powers of 2 and the difference between 32 and 64-bit).

<comment><USER24> Yeah, I worry that between the less obvious failure mechanics and the sense that Y2K was overblown (probably, ironically, because it was effectively mitigated), the epochalypse may not be all that nice.

</comment></comment><comment><USER25> Speaking of the 2038 bug, I'm impressed with Paul Ryan's rhetoric [0]

"I asked CBO to run the model going out and they told me that their computer simulation crashes in 2037 because CBO can't conceive of any way in which the economy can continue past the year 2037 because of debt burdens," said Ryan.

I love politicians.

[0]-[http://www.cnsnews.com/news/article/ryan-debt-track- hit-800-...](http://www.cnsnews.com/news/article/ryan-debt-track- hit-800-percent-gdp-cbo-cant-conceive-any-way-economy-can-continue-past)

</comment><comment><USER26> I Wonder how DRM anti-circumvention laws will mix with this; You have a locked-down device you use, depend on, and know is defective, but you are not allowed to hack the device to fix it.

</comment><comment><USER27> Meh, we'll just redefine time_t as (signed) seconds since 2000 or so and subtract 30 years in seconds from all timestamps ... ;-)

<comment><USER28> No, you make it time_t (unsigned) seconds since the epoch. That pushes the problem out 70+ years and doesn't break any binary APIs.

<comment><USER29> Changing from signed to unsigned is very much an ABI break.

<comment><USER28> Yes, it is an ABI break.

But if you took code that was compiled with each version, the binary data that they will produce/consume for dates between the epoch and 2038 is bit for bit identical.

</comment></comment></comment></comment><comment><USER30> Despite the cause being the end of the UNIX epoch in 2038, problems will become apparent a much sooner. Like the Y2K issue - in ~2031 (or sooner), systems that track expiration dates or contract terms will start to run into dates past 2038. As 2038 approaches, more systems will be affected (there are relatively fewer expiration dates 7 years out vs. 5 or 3).

The effects of this problem are closer than they seem - only 14 years away or less

</comment><comment><USER31> Is 2038 the end of a signed int? If so, can't we just make it unsigned and buy ourselves another 70 years or so? I don't know how much of an issue not being able to represent time before 1970 is, but for timestamps that doesn't seem like it would be an issue.

<comment><USER32> That would break systems that relies on time stamps earlier than 1970 though.

      int main(void)
      {
          time_t epoch = -100;
          printf("%s", asctime(gmtime(&epoch)));
      }

The above would for example print a time in 1969.

</comment></comment><comment><USER33> > BSD-based distributions have the advantage of being able to rebuild > everything from scratch, so they do not need to maintain user-space ABI > compatibility in the same way.

I don't understand, not knowing much about BSD. Is this an LTS/support thing? Can someone explain?

<comment><USER34> Generally people build BSD packages from source instead of installing binaries. (I think; I've not used BSD.)

<comment><USER35> OpenBSD user since 2009. I have _never_ compiled a package from source.

But they can break the ABI because they do not want to maintain compatibility with old proprietary binaries. It's a source world, in the sense that any software can and will be recompiled if and when needed. That doesn't mean every user has to compile their own system.

</comment></comment></comment><comment><USER36> Newton (Apple's old PDA) had a similar problem in 2010 [0]. In short, while the base system and C++ interfaces used 32-bit unsigned ints with a base of 1904-01-01, NewtonScript uses 30-bit signed ints, with a working base of 1993-01-1, overflowing in 2010. The fix was a binary patch that changed the time bases.

0: [http://40hz.org/Pages/Newton%20Year%202010%20Problem](http://40hz.org/Pages/Newton%20Year%202010%20Problem)

<comment><USER37> It's interesting to see that Apple's... shortsightedness/planned obolescence is nothing new. The Apple Lisa, released in 1983, was apparently not designed to survive beyond 1995:

[http://www.macworld.com/article/2026544/the-little-known- app...](http://www.macworld.com/article/2026544/the-little-known-apple-lisa- five-quirks-and-oddities.html) (scroll down)

</comment></comment><comment><USER38> Surprisingly, when Googling for 2038 & FreeBSD, the 2nd highest recommended search result was:

2038年問題 freebsd

I do not speak, write, or search for things using Chinese characters. Seems as though this problem must have been heavily Google'd for by Chinese speakers - why else would it have popped up in my search recommendations?

Btw: Google Translate tells me 年問題 means "year problem"

Perhaps this information was important for ensuring the safety of Kylin, which started out as a sort of Chinese DARPA-style project to get the state off of MS Windows. Kylin was announced in 2006. It was supposedly based on FreeBSD 5.3.

Strange thing is, Kylin later became known to use the Linux kernel (with a Ubuntu influence). - Google search recommendations, which should be based on a recent volume of searches, if they did suggest anything about Kylin development, should yield "2038年問題 linux" rather than "2038年問題 freebsd" \- Maybe some of those FreeBSD-Kylin systems are still being heavily used.

Or perhaps there are a lot of embedded systems being produced in China which use FreeBSD.

</comment><comment><USER39> On a side but related note, I don't understand why many programming languages and databases don't have a positive and negative infinity date placeholder/token value that is standardized and cross platform. Negative infinity date is "past", positive infinity date is "future". This would solve the common problem of what date to use when you are trying to talk about unknown date in the future or unknown date in the past, rather than using weird placeholders like 9999-12-31 or 1900-01-01 or other magic numbers.

<comment><USER40> There are lots of scenarios where you need to represent an unknown/indefinite date, but this can be done with null; are there any reasonably common scenarios where you need to distinguish between unknown past and unknown future in the same context?

<comment><USER39> I agree, null is often chosen as an option. But null is also not a value by definition so then it becomes hard to do a range check when using say, a start and end date. Also, what is the difference between a date in the future and null? Semantics I think-a token future date has an explicit value, whereas if you use NULL, the use of that as a future date has a new implicit value that depends on context.

I know maybe it sounds pedantic or perhaps out there but I think that token dates that are fixed and specified as positive or negative infinity gives a mathematical value that can then be reasoned with formulaically, just like we do with calculus. We keep running into finite limits which is what keeps causing problems such as Y2K, Y2K38, the beginning of Unix time (1970-1-1) - maybe if we treated the beginning and end of time as infinity some new method of reasoning about dates would become more apparent. I'm not sure as I haven't gone all the way down the rabbit hole with this idea yet.

<comment><USER39> Another thought - if you treat a date as a relative variable related to a frame of reference (example, what if you defined the future to be a token value of today + N days, which means it is always calculated as a dynamic future date ahead of today), maybe we could reason about relative past and present using relative variable dates? Or maybe this is just crazy talk.

</comment></comment></comment></comment><comment><USER41> More gravy for Initech!

</comment><comment><USER42> Using a 64 bit unsigned integer with nanosecond resolution gives us 585 years (2^64/1e9/60/60/24/365) after 1970 to come up with a new format. This, combined with using some other format to describe dates before 1970, seems like a sensible solution to me.

</comment><comment><USER43> The problem is not with developers or tech savvy people. Everyome will know about this by then and solutions will be applied. The problem is with end users, who will only realize this after the shit hits the fan and their fridge will go crazy or there will be a car crash.

<comment><USER44> This assumes that any of today's technology will survive 21 years...

<comment><USER45> My jeep is 27 and has an intel CPU.

so.... yep.

</comment></comment></comment><comment><USER46> So what are we calling this one, Y2K38?

I've heard people talk about the risk to cars, but what other kinds of embedded systems will still be in use after 20 years? Maybe certain industrial machines?

</comment><comment><USER47> [https://news.ycombinator.com/item?id=7678847](https://news.ycombinator.com/item?id=7678847)

</comment><comment><USER48> This maybe a stupid question, but could we not use Bignum as a datatype to solve this? or would it be too computationally expensive?

</comment><comment><USER49> This is a good reason to run anything but Linux, particularly on 32bit hardware.

All BSDs have, as far as I'm aware of, solved this years ago.

<comment><USER50> only netbsd and openbsd, still an issue on freebsd.

</comment></comment><comment><USER51> Fortunately, my retirement system has a project active right now to address this, and I will be retired in late 2032.

</comment><comment><USER52> Y2K didn't cause any serious blips on the stock market, so 2038 will probably pass without many even noticing.

</comment><comment><USER53> As a layman here, can someone explain this what the significance of the year 2038 is to me?

<comment><USER54> [https://en.wikipedia.org/wiki/Year_2038_problem](https://en.wikipedia.org/wiki/Year_2038_problem)

Short summary: Many systems (including Unix) store time as a signed 32 bit int, with the value 0 representing January 1st 1970 00:00:00. This number will overflow on 03:14:07 UTC on 19 January 2038.

<comment><USER53> So a more serious Y2K?

<comment><USER54> It is Y2K-ish; it's "different" so I'm not sure about seriousness. I'm thinking it simultaneously could be easier and more difficult, the standard "it depends" type answer. :)

Y2K is more of a formatting / digit representation problem than a pure data type overflow. The solution for Y2K was to switch the _representation_ of year from 2 to 4 digits, along with coding and logic changes to go along with this.

For Unix / Linux, the solution for the 2038 problem involves changing time_t from 32 bits to 64 bits. At a higher level (eg what's in your C++ code), instinctively I don't think this in itself would involve as many code changes (maybe some data type changes, but probably less logic changes than Y2K, that's my guess). I believe several platforms have already moved towards 64 bit time_t by default... some support this by default even on 32 bit systems, such as Microsoft Visual C++ -- [https://msdn.microsoft.com/en- us/library/3b2e7499.aspx](https://msdn.microsoft.com/en- us/library/3b2e7499.aspx)

Since this involves a data type overflow issue, though, we're dealing more with platform specific / compiler / kernel type issues. I don't know, for instance, how easily 32 bit embedded type systems could handle a 64 bit time_t value. I understand that there are some technical issues with Linux kernels (mentioned in some of the comments) that prevent them from moving to a 64 bit time_t irregardless of platform (time_t should always be okay on 64 bit platforms, it's the 32 bit platforms that will have the issue...)

The good news is we have 21 years to think about it...

</comment></comment></comment></comment><comment><USER55> My retirement, only 18 years away. I'm real sorry I'm gonna miss this mess, NOT!

</comment><comment><USER56> for the others curious, seems javascript handles dates with 64-bit floating points, which have a maximum of 9007199254740991.

The highest date I could make with node+chrome was 'Dec 31 275759', which cozies-up pretty close to that (8639977899599000)

<comment><USER57> I wanted to figure out the importance of that value you found, so I went and did some further research. It turns out the greatest date you can create in Javascript is Date(8640000000000000). Interesting!

From the ECMAScript Spec [1]:

 _The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC._

[1] [http://ecma-international.org/ecma-262/5.1/#sec-184.108.40.206](http://ecma- international.org/ecma-262/5.1/#sec-220.127.116.11)

</comment></comment><comment><USER58> Can someone ELI5 this please? The only thing that seems comparable that I know of was the "Y2K bug" \- but reading through this it seems like this is actually a big problem - as opposed to the techno-illiterate panic of Y2K.

 _That work, he said, is proceeding on three separate fronts_

I can't read that without thinking of the turbo encabulator.

<comment><USER59> I'll let somebody else handle the explanation but Y2K wasn't a "techno- illiterate panic", a ton of people worked a ton of hours to fix and update the code for Y2K and it's a testament to their labor that there were no major issues.

<comment><USER60> It was a combination of both. I still remember my dad coming home from a talk that he considered the "best yet" on the Y2K issue.

The speaker warned that traffic lights would stop working. Maybe someone more techno-literate than me can explain why that would be a genuine concern, but from my perspective at the time it seemed like the guy was making money from fear mongering.

</comment></comment></comment><comment><USER61> Is software written in Go (that uses "time" package) going to be affected?

<comment><USER48> No, [https://golang.org/pkg/time/#pkg- constants](https://golang.org/pkg/time/#pkg-constants) Not unless you explicitly use the Unix method

</comment></comment><comment><USER62> Hey guys! I just invented a new form of music! :D Epochalypso!

</comment><comment><USER63> What about NTP epoch which has 2036 problem?

</comment><comment><USER64> Here I thought it was a post on the singularity. It might be ironic if all the AI starts running into all sorts of 2038 bugs and this ends up being a huge issue.

</comment><comment><USER65> With any luck I'll be dead by then.

</comment><comment><USER66> We should stock up on IBM 5100's

</comment><comment><USER67> (Does anybody remember that time traveler?)

</comment><comment><USER68> And IPv6 penetration will have hit 20%.

<comment><USER69> You jest, but global IPv6 penetration is at ~16%. It rose ~6% last year, so if linear growth is presumed (and it's actually been growing closer to exponentially, as would be expected) we should hit 20% late this year. I'm hopeful that we'll see some decent pickup of it since AWS _finally_ started offering it.

This is global adoption; some countries, including the United States, have already hit 20%.

[1]: [https://www.google.com/intl/en/ipv6/statistics.html](https://www.google.com/intl/en/ipv6/statistics.html)

<comment><USER70> What's up with that huge weekly variation?

<comment><USER71> It looks like it's correlated with the weekend. I guess workplace computers are more likely to use IPv4? It makes sense on the surface. Workplaces have little to no incentive to use IPv6 since they either have a huge block of IPv4 space or run NAT or both. Also they tend to rely more on enterprise network appliances which have bad IPv6 support in my experience. IPv6 is more of a boon to consumer applications since carrier-grade NAT is a nuisance and otherwise you need an IP per customer.

<comment><USER69> Every employer except one that I've worked for had IPv4 only. None of them had public IP blocks; they were all NAT'd.

> _Also they tend to rely more on enterprise network appliances which have bad > IPv6 support in my experience._

This I would believe.

> _IPv6 is more of a boon to consumer applications since carrier-grade NAT is > a nuisance and otherwise you need an IP per customer._

It would have been a slight boon at work, too. HR perennially makes me grab documents/data off my home machine, and I cannot wait for the day when I can just `ssh` to a domain name. My .ssh/config aliases are getting pretty good, but it still adds considerable latency to pipe everything through a gateway. (Alternatively, I could run SSH on non-standard ports, but I've yet to get to mucking around with the port-forwarding settings for that.)

There were also times when we needed to do stuff like employee laptop-to- laptop communications, and the network just wouldn't deal with it. I was never sure if this was NAT, or just that Corp Net liked to drop packets. (It seemed rigged to drop basically anything that didn't smell like a TCP connection to an external host. ICMP wasn't fully functional, which of course makes engineering more fun when you're having your personal desktop at home do pings or traceroutes for you, but that doesn't help if the problem is on your route.)

</comment></comment></comment></comment></comment><comment><USER72> Will be 70 and happily oblivious.

</comment><comment><USER73> Y2K round 2

</comment><comment><USER74> Y2K

</comment><comment><USER75> Call me stupid, but I think computing will be much different to worry about this. ( single chip os or iot to the level that each hardware component is separate, or something else...)

<comment><USER55> > Call me stupid,

Well I won't say you are stupid. But do you realize we are talking about a time format "designed" 40+ years ago. And some cpus are still compatible with chips from 80's 90's. To imagine all that will go away and be solved in 20 years is not logical.

Also, the problem isn't with PCs (which will be upgraded) but the billions of IoT, industrial controls, and other embedded devices that lack easy upgrade paths. Things like elevators, pressure release valves, cars.

<comment><USER76> I'd add trains to your list. There are locomotives in use in UK that use electronics (I admit not microprocessor based and not running an actual operating system) dating from 1980s. The ones currently being designed may have similar active service times.</comment></comment></comment>


PG&E responsible for three Northern California wildfires, Cal Fire alleges - <AUTHOR> http://www.sacbee.com/latest-news/article211958659.html <comment><USER2> I initially feared that PG meant Paul Graham did this.</comment>