The thing is that mining bitcoins is not really a supercomputer task. It is an "embarassingly parallel" problem - you could get some PCs and connect them over 9600bps serial ports, and it would hardly be any different to using the fastest network to connect them together. There is not that much communication needed between the parts of the cluster. A true supercomputer usually has fast, specialized interlink hardware between the compute nodes so it can work on problems which are somewhat less parallelizable, requiring more communication between the nodes. That is why it is expensive, and expensive to hire computing time on it, and yet it doesn't perform any better at bitcoin mining than a simple-minded farm of commodity hardware. (And for bitcoin mining, either of those will be blown out of the water by specialized ASICs.)

+1, accurate.

One of my peeves with IPv6 is that in v4 I had over 16 million legal loopback addresses out of only 4 billion addresses; now in v6 I have exactly one out of a much larger pool. It is not often useful, but it isn't always useless to use more than one of the loopback addresses on a host.

I would have preferred loopback to be a /64 rather than a /128 in IPv6: it's not like the address-space is too small to afford it.

I don't think market cap is a good measure of size. If it were, then during the dotcom boom various online pet food suppliers, etc, which had barely any assets, employees or customers, would have counted as 'bigger' than more boring companies with a much greater footprint in the real world. Similarly, a large company may head towards bankruptcy and as it does so its market cap heads towards zero. But even if it is sold for a nominal price of one dollar, it is still a big company by any reasonable measure.

There's no issue getting 3840x2160 resolution with any even half-recent video card. I drive a T221 (3840x2400) from a five year old Dell laptop; these displays first appeared a decade and a half ago when PCs were much slower than today. Admittedly, if your new monitor takes Displayport you will need a video card capable of outputting that. Now, if you want to play games at 3840x2160 at 60Hz refresh, you're going to need some pretty serious hardware. But that has nothing to do with using the display for programming or office tasks. 30Hz refresh is quite comfortable for that.

Yeah, but you need the lower level frames (link layer) to implement the higher level protocol (TCP) so that you can encapsulate another lower-level protocol within it; you can't implement TCP without any link-layer underneath it, is what I was trying to say. Note the "only" using TCP in the post.

What I'm really saying is that thunderbolt is like a transport layer protocol, and pci-e, Ethernet, video, etc. are all protocols layered on top of this transport protocol. It's very like the OSI stack, in as much as there's a link-level protocol and service-level protocols building on that basic transport.

I have no experience with PC motherboards so I'm not *sure* what they're doing, but I suspect that they are exposing any pci-e level protocol traffic as hot-plug pci-e (as does the Mac), and that the OP is misunderstanding what the author of the HTML page he linked to is saying.

Thunderbolt itself is a lower-level protocol, but one that can be addressed directly which can be useful for particular applications. One example is raw dma, so any thunderbolt device can dma into any other device without the CPU getting involved (modulo the conditions I mention above).

I thought the spec comment was a bit odd as well, but I think he might be referring to the fact that the spec (and the hardware) has changed over time. There are several revisions...

Dude, I'm just describing what I see. I have the docs too, for both protocol and controller chips, and I have the code and measurements to prove it.

There's a clear difference in the time taken to process packets once the kernel gets involved, and (within experimental error), that time difference is nicely quantized.

I can't say it any clearer, when the kernel doesn't need to get involved (see above for criteria), it just doesn't - at least on a Mac. Perhaps the bios's Greg is using are not implemented well, I don't know (I have no experience there) but the Mac does it intelligently.

I don't see how you can implement a lower-level protocol (eg: raw thunderbolt DMA) using a higher-level abstraction of that protocol (eg: pci-e traffic). That's like saying you'll implement Internet-layer frames only using TCP. Similarly, I don't see how you can expose something that doesn't conform to anything remotely like pci-e as a hot plug pci-e device - the latency tolerances to remain in spec are way different for a start.

I too have implemented a driver, from a high-end FPGA to the Mac, and the OSX kernel does not get involved unless you're traversing controllers within that Mac, or the route cannot be expressed within a single transaction, or if the destination is local. It just doesn't. These are to my knowledge the only 3 reasons for the local CPU to get involved:

[1] If you have a machine with devices (1,2,..) on multiple thunderbolt controllers (say A and B), it's possible to have a route like A2 -> A1-> A0 -/-> B0 -> B1, and of course the kernel is involved then because the individual controller chips A and B are not bridged together in any other way. The kernel has to route between A0 (local) and B0 (also local).

[2] The initial spec for thunderbolt allowed a lot of flexibility with source-defined routing tables, but it wasn't taken advantage of, and the later chips from Intel removed some of that functionality (or, more likely, just reassigned the chip real-estate to something more useful). There are now potentially valid routes that can't be expressed within a single frame, and the kernel has to be involved at that point as well, to make sure packets get to their correct destination. It is, however, unlikely that users will see these routing issues in real-world scenarios, you have to have a lot of devices on multiple busses before it's an issue.

[3] The destination is the local machine. Of course, the kernel has to get involved then.

I have a lot of diagnostic code that monitors bandwidth, packet lifetime and routing, and latencies. I've run massive stress tests on multiple machines and devices connected via thunderbolt, and so far, the above 3 reasons are the only ones that an OSX machine enters the kernel for any thunderbolt-related cause. It is quite clear when the kernel does get involved compared to when it doesn't, so I'm confident that if it doesn't have to get involved, there is no interaction.

Thunderbolt has only a passing acquaintance with pcie. It most certainly is not just a pcie bridge over wires rather than on board connectors. Thunderbolt is a switched packet network transport, and can route data packets of many types (including video, pcie, raw thunderbolt dma, etc.)

In addition, every thunderbolt port is a switch, using source-embedded routing to decide whether the packet ought to be forwarded n hops or whether it's destination is local - so the local CPU only gets involved if you're traversing thunderbolt controller chips, or if the packet is for the local machine.

There's a lot more to thunderbolt than just pcie, so if linux just treats it as pcie then linux is getting it wrong.

I'm not sure you got the point of the article - they were trying to match the specs of the capabilities in the Mac using commodity parts. The GPUs in the Mac Pro are the same as those firePro parts that cost a small fortune, and even a couple of R9 290x's wouldn't keep up because of a lack of VRAM (6GB of DDR5 vs 4GB on the 290's)

I'm not saying you need those gpu's, but if you're trying to match specs, those are the ones to choose. I think it's also clear that Apple are pushing gpu-based computing at the high end (they designed OpenCL after all), so high-load gpu code is likely to be common in the pro-apps. Those GPUs will be used on a mac.

In Windows it works better if you stick to an exact multiple of 100%. In other words your choices are 100% or 200%.

Why on earth would you choose to base your product (something that presumably companies will use for many, many years) on something that will have no security support in just 4 months?

You wouldn't. You based it on something that would be supported for several years when you made the decision back in 2006. It's just that schedules being as they are, it has taken that long to develop the product and get it to market.

In the land of dinosaurs, where Big Companies do Stupid Things, it is fairly common for new products to be launched and then the whole platform end-of-lifed soon after. It's nobody's fault in particular, just how decisions get made.

Perhaps racist behaviour should be punished independent of any mindless "free speech" worship.

Simon

Yeah, thanks.

The difference being that I'd legally lock the shitbags up and let them die in prison. I'd not go out and kill someone *else* to make my point.