Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Putting out the hardware dumpster fire

dl.acm.org

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Putting out the hardware dumpster fire

#81

Post by loup-vaillant »

rcxdude wrote: post #74
zackmorris wrote: post #22

I've noticed the trend of ever-increasingly complex hardware with little or no change in performance since the 90s, and ranted about it extensively since I joined HN. I think we're past considering the problem from a technical perspective and need to look at the conspiratorial forces involved. To me, the problem is one of monopoly and corporate thinking. When Intel and AMD make most of the chips, we end up with a Cok…

FPGAs will never be mainstream for replacing CPUs or GPUs: the performance overhead of an FPGA compared to dedicated silicon is huge and not going down, regardless of how open or closed they are. FPGAs have their uses in niches, but I don't think they'll ever be something the average user has in their device, and certainly they won't be the only thing in there. Anyone wishing to disrupt the way mainstream compute is…

The point of FPGA is not to make competitive CPUs. It’s to _prototype_ them. Give wide access to that, and more people will be able to design cores, and experiment with different design trade-offs, or even computing models.

Granted, a softcore on FPGA is at high volumes much more expensive and much less capable than a corresponding ASIC. At low volumes however it’s the only affordable alternative, and that’s make them the gateway to hardware design by the people (and increasingly, for the people as well).

By the way I recently purchased a Tillitis key¹, a security dongle with a RISC-V soft core (PicoRV32) running on the iCE40 Ultra Plus FPGA. I absolutely love their approach, where you can run arbitrary programs on that key, and each program gets an independent secret seed (derived from the key’s secret and a hash of the program). Sure this FPGA soft core is much less powerful than an equivalently priced hard core would have been, but I’m not sure they could have done such an open design without it.

Especially the upcoming unlocked version, which will allow customers to customise the "hardware" itself. I personally can’t wait, I’d like to experiment a couple optimisations.

[1]: https://tillitis.se/

Re: Putting out the hardware dumpster fire

#82

Post by topspin »

derefr wrote: post #45
topspin wrote: post #26

Earlier quoted context omitted.

> or even kernel daemons run on the efficiency cores When (not if) the kernel scheduler locks up while the fans are slow/stopped at the same moment some scheduled user process begins driving 250W+ through a CPU the isolated fan controller (not to mention isolated thermal throttling logic, also independent of the OS) has great value. > If this doesn’t happen—why doesn’t it? Hardware evolves faster than operating syste…

You don’t seem to be paying attention to the words “vertically integrated” in my question — which were the whole point of my question. Apple creates both the OS and the hardware for their phones. So why shouldn’t the hardware microcontroller firmware for the hardware they create (or commission and constrain the design of), run as one or several RTOS blobs that ship as part of the OS on one or several shared MCUs? Let…

> You don’t seem to be paying attention to the words “vertically integrated” in my question

That's because vertical integration doesn't actually solve the core problems.

Re: Putting out the hardware dumpster fire

#83

Post by hedgehog »

AnthonyMouse wrote: post #56
jrockway wrote: post #28

Earlier quoted context omitted.

If I'm ever going to get on the conspiracy theory bandwagon, it will be on two topics: 1) Return to office. 2) Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. Manufacturers say "no, we have a super secret secret sauce that nobody else could possibly improve upon". Uh huh, sure.

> Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some…

My guess is because flash chips are quirky and not very interchangeable. The error correction, wear leveling, etc all probably needs to be configured and calibrated to the specific chips used in a way that only can really be done by the manufacturer or a really big OEM like Apple.

Re: Putting out the hardware dumpster fire

#84

Post by FridgeSeal »

hoosieree wrote: post #50
srcreigh wrote: post #47

Earlier quoted context omitted.

In my city office buildings are being converted to residential housing. 3 buildings recently in an area of population size 250k.

What part of the world? I've heard that the cost of converting office spaces to residential is more than building new.

People keep telling me this too, so I’d be super interested to know if it wasn’t the case, because it really feels like a weak/overinflated reason.

Re: Putting out the hardware dumpster fire

#85

Post by KennyBlanken »

> Indeed, these cores and their firmware usually explicitly sandbox Linux on a corner of the chip (the “application cores”), preventing it taking any meaningful role in managing and securing the platform. On an Android phone, Linux is effectively an application runtime.

The reason Linux is sandboxed into a corner of the system on an Android phone is because the phone is more interested in not trusting you than it is not trusting the SIM chip's processor, cellular radio, etc.

Google don't want you:

* getting unrestricted access to digital content they or others sell and make available on the platform. Hollywood won't let them sell movies on Play Store if Google can't guarantee you won't be able to make a copy of the files on the device, or output HDMI to a recording device. Ditto for Netflix. Ditto for record companies/RIAA. Ditto for magazines and newspapers. The list goes on. Your smartphone, no matter what anyone tells you otherwise, is primarily designed as a media consumption device. Its secondary purpose is a cloud services consumption device (Google or Apple) and last on the list is "a device for you to use however you want." For example, on iOS, the Files app and any file save dialog always defaulting to your iCloud folder, and the inability to set a default save location, is not even remotely an accident. Apple forces you to, every single time, select somewhere else if you don't want to save to iCloud.

* disabling the methods they use to track you or opting out of the data collection they perform wholescale and continuously.

* disabling the methods application publishers use to track and collect data about you.

Re: Putting out the hardware dumpster fire

#86

Post by AnthonyMouse »

rjsw wrote: post #69
AnthonyMouse wrote: post #56

Earlier quoted context omitted.

> Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some…

Why offload it to the host? If the CPU on the NVMe card is well documented then run the flash software on that. The same goes for network offload features in ethernet controllers, make it an open architecture that you can write your own firmware for.

The host CPU is faster, which lowers access latency, and modern machines have large numbers of generally idle cores. It also reduces the cost of the drive.

Meanwhile you could also have drives with offload engines, in the same way that some network cards have offload engines and some don't. But the ones that do are more expensive.

Re: Putting out the hardware dumpster fire

#87

Post by AnthonyMouse »

hedgehog wrote: post #83
AnthonyMouse wrote: post #56

Earlier quoted context omitted.

> Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some…

My guess is because flash chips are quirky and not very interchangeable. The error correction, wear leveling, etc all probably needs to be configured and calibrated to the specific chips used in a way that only can really be done by the manufacturer or a really big OEM like Apple.

I'm trying to imagine why wear leveling would depend on the chips. The number of writes you can get out of them would, but the optimal wear leveling algorithm should be to spread the writes around as much as possible regardless of that, shouldn't it?

Likewise, some chips could require more error correction because they expect more errors. But the amount of error correction is a tunable in the algorithm; it's a space vs. resilience trade off. Where to set the dial shouldn't be hard to derive from the manufacturer's specifications, or empirical testing if the spec is worthless.

Re: Putting out the hardware dumpster fire

#88

Post by BlueThoughts »

ForOldHack wrote: post #18
imiric wrote: post #13

Earlier quoted context omitted.

> He makes a very compelling case for greatly expanding the concept of an operating system into all of the hardware in a given computing environment. I haven't watched the presentation, and just glanced at the paper, but while I see how this would be an improvement, I'm not sure if giving operating systems all that power would be an absolutely good idea. While I certainly don't trust the firmware that runs on my devi…

"Dumpster fire?" You are too kind. It's a cesspool, and a leaky one a that. Mostly Microsoft fault, and it has been now known to be getting worse.

I asked a friend about why their company could not keep their devices up to date for more than two or three years.

Basically, they did not have long-term maintenance agreements in place for the underlying subcomponents. The subcomponents were filled with vendor coded firmware blobs. There was some desire to fix this going forward for marketing purposes, but little desire to go back in time to fix old devices that were short on support.

Re: Putting out the hardware dumpster fire

#89

Post by AnthonyMouse »

dezgeg wrote: post #60
AnthonyMouse wrote: post #56

Earlier quoted context omitted.

> Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some…

For starters, I doubt that acting as a NVMe device is something you can do with a off the self "inexpensive RISC-V" with any kind of acceptable performance. A NVME engine would almost certainly be something that the flash controller would have implemented in fixed function hardware. Also NAND flash practically requires some sort of error correction system - another thing that fixed function logic in a custom ASIC is…

The basic function of transferring data between the flash chips and the PCIe bus shouldn't be a bottleneck.

Dedicated silicon for error correction might be more efficient, but when there are already fast idle CPU cores it may not matter, and ECC algorithms can already be accelerated by SIMD instructions. Or for high performance machines add the dedicated silicon to the host CPU.

Re: Putting out the hardware dumpster fire

#90

Post by hedgehog »

AnthonyMouse wrote: post #87
hedgehog wrote: post #83

Earlier quoted context omitted.

My guess is because flash chips are quirky and not very interchangeable. The error correction, wear leveling, etc all probably needs to be configured and calibrated to the specific chips used in a way that only can really be done by the manufacturer or a really big OEM like Apple.

I'm trying to imagine why wear leveling would depend on the chips. The number of writes you can get out of them would, but the optimal wear leveling algorithm should be to spread the writes around as much as possible regardless of that, shouldn't it? Likewise, some chips could require more error correction because they expect more errors. But the amount of error correction is a tunable in the algorithm; it's a space…

Wear leveling: Just search Google Scholar for "wear leveling" to get an idea for how deep that rabbit hole goes. At minimum think about the difference between placing an infrequently written logical sector vs a frequently written one, and what the optimal strategy would be given physical blocks with varying write life left on them. Then how do you partition between regions you treat as SLC vs MLC? And on and on and on.

Error correction: Not just amount. What block size? Interleaving? How do you trade overhead due to more ECC vs overhead due to more spare blocks (have to decide how many to allocate up front)? What is the behavior vs temperature and what are you running the thing at?

There has been an ongoing push to standardize NAND interfaces but the controller still needs to know a fair amount about the specific chips it's talking to. I don't know how it will resolve but hopefully the integration becomes more like DRAM where things are a bit more consistent. Then again, if you care a lot about reliability you qualify specific DRAM modules too...

Post reply on HN