This is my biggest complaint of Linux being where bare metal should. For whatever reason my car takes multiple seconds on startup between starting the music and registering my inputs to lower volume or pause. Older cars didn't have that problem.
That said, cars have 12v batteries. If the pi was better (again another gripe, choose better products not just what everyone else uses) you could put the thing to sleep. Even a good low power Linux machine can go years off one of those (quick math says like 100 years, so negligible draw). Or you could cut yourself off if the level gets below a threshold for too long. Plenty of solutions.
That specific problem sounds like you just have bad software in your car. My car takes a second for the infotainment system to boot, but it doesn't start blaring anything until it's ready to process input.
I have reverse camera connected to SBC with Allwinner H6. It easily saves around 5 seconds compared to Pi (their closed bootloader takes ages to even start loading kernel). I considered early booting the system when opening the door, but really it is fast enough already.
Not too terribly sure, but NXP puts out power consumption numbers and they get pretty low in sleep modes with self refreshed DDR and whatnot. I think it's just something the market hasn't demanded enough. I'm not really a SBC person, usually just uC, where it's trivial to get microamps of sleep current. I'm sure there's an SBC out there that allows for it.
Interesting design choice. One alternative would be to not send any output to speakers until the controls work? I would wonder what else is wrong that isn't immediately obvious.
I think the article brings up a great point about how they pivoted. So many companies start out strong then resort to "the original" to try and get sympathy? Nostalgia? Idk who falls for that or why. Or they sell out to someone that'll gut them. These guys knew that their first success wasn't a GPS locator. It was a PNT device that met an unserved market. In that regard they haven't pivoted at all. I respect that immensely.
My preferred one for EE folks is that reportedly the first Arduino boards (now 20 years old?) had a mistake in their eCAD where the second pair of headers was 0.05 instead of 0.1" apart. But it was too late by the time they caught it. And now, 20 years later, even high end microcontroller boards ship with that same gap to be compatible.
Also incredible how difficult it was for me to find how to see it. No links to a video, just a newscast. I scrubbed through it until maybe the 4:30 mark when they highlight a portion. Could've been a gif or something idk.
I know we're brain rotten from short form media but on the other hand just show me the part of the video I care about. Then discuss it.
Can the second analyzer software not do the same measurement as the first? Coming from a point of ignorance here: I lucked into some higher and DLAs (though not 5v compatible so they wouldn't directly help here) and their softwares allow both decode and measurements
Yes, but only in hindsight - and you have to take the "part 1" into account too.
An oscilloscope is able to show analog values. If you have no clue what a signal is, it is your best bet to start with. In this case it turned out to be a simple digital serial signal, but it could've just as well been a 0V-5V analog one or perhaps an open drain bus with pullups like i2c.
Logic analyzers only really work for binary values. You are able to set a single threshold: everything above becomes a 1, everything below becomes a 0. Great if you've got a purely digital signal, useless if it has analog components.
In the first part the author had to start with an oscilloscope to begin exploring. They could've probably switched to the logic analyzer before the first step of part two, but there isn't really a strong reason to do so - and there would still be a nonzero chance of analog components playing a role. Seeing that it was a simple digital "one wire TX, one wire RX" probably gave enough confidence to assume it was something like serial uart and move on.
Maybe I wasn't clear enough, I meant cutting out the gtkwave step. Oscilloscope is great, pulseview great, but what's gtkwave doing here that the others can't?
I'll say this because it's possible to go from my username to name anyway: I share a name with this language. And usually that's fine because it's not very widely used. But seeing this headline was certainly a surprise on an otherwise calm Sunday morning.
Like most AI things, my issue with the bot isn't that it exists, it's that they force it at the top of the list with no way to remove it. I've accidentally opened it a few times from the years of muscle memory that the first result is the person who just messaged me.
This coupled with them popping up a people-you-may-know the majority of times I open the app with no way to turn it off (again like most tech these days) gives me 0 sympathy.
Understanding that there's inherent bias by them being competitors of the other companies, but still this article seems to make some stretches. If you told me you had an 8% core defect rate reduced 100x, I'd assume you got to close to 99% enablement. The table at the end shows... Otherwise.
They also keep flipping between cores, SMs, dies, and maybe other block sizes. At the end of the day I'm not very impressed. They seemingly have marginally better yields despite all that effort.
I think you're missing the point. The comparison is not between 93% and 92%. The comparison is between what they're getting (93%) and what you'd get if you scaled up the usual process to the core size they're using (0%). They are doing something different (namely: a ~whole wafer chip) that isn't possible without massively boosting the intra-chip redundancy. (The usual process stops working once you no longer have any extra dies to discard.)
> Despite having built the world’s largest chip, we enable 93% of our silicon area, which is higher than the leading GPU today.
The important part is building the largest chip. The icing on the top is that the enablement is not lower. Which it would be without the routing-to-spare-cores magic sauce.
And the differing terminology is because they're talking about differing things? You could call an SM a core, but it kind of contains (heterogeneous) cores itself. (I've no idea whether intra-SM cores can be redundant to boost yield.) A die is the part you break off and build a computer out of, it may contain a bunch of cores, a wafer can be broken up into multiple dies but for Cerebras it isn't.
If NVIDIA were to go and build a whole-wafer die, they'd do something similar. But Cerebras did it and got it to work. NVIDIA hasn't gotten into that space yet, so there's no point in building a product that you can't sell to a consumer or even a data center that isn't built around that exact product (or to contain a Balrog).
I think I'll still stand by my viewpoint. They said:
> On the Cerebras side, the effective die size is a bit smaller at 46,225mm2. Applying the same defect rate, the WSE-3 would see 46 defects. Each core is 0.05mm2. This means 2.2mm2 in total would be lost to defects.
So ok they claim that they should see (46225-2.2)/46225 = 99.995%. Doing the same math for their Nvidia numbers it's 99.4%. And yet in practice neither approach got to these numbers. Nowhere near it. I just feel like the whole article talks about all this theory and numbers and math of how they're so much better but in practice it's meaningless.
So what I'm not seeing is why it'd be impossible for all the H100s on a wafer to be interconnected and call it a day. You'd presumably get 92/93 = 98.9% of the performance and, here's the kicker, no need to switch to another architecture. I didn't know where your 0% number came from. Nothing about this article says that a competitor doing the same scaling to wafer scale would get 0%, just a marginal decrease in how many cores made it through fab.
Fundamentally I am not convinced from this article that Cerebras has done something in their design that makes this possible. All I'm seeing is that it'd perform 1% faster.
Edit: thinking a bit more on it, to me it's like they said TSMC has a guy with a sledgehammer who smashes all the wafers and their architecture snaps a tiny bit cleaner. But they haven't said anything about firing the guy with the sledgehammer. Their paragraph before the final table says that this whole exercise is pretty much meaningless because their numbers are made up about competitors and they aren't even the right numbers to be using. Then the table backs up my paraphrase.
There is nothing inherently good about wafer scale. It's actually harder to dissipate heat and enable hybrid bonding with DRAM. So the gp is entirely correct that you need to actually show higher silicon utilization to be even considered as being something worthwhile.
There's also the inertia problem where it's harder to accelerate mass that's further away from you. The classic spinning ice skater demo. This feels physically disadvantageous. Hopefully I'm wrong though, the more competition in spaces the better.
But here that mass is the driving force: the further away from the center you put your magnets, the less force (the less magnet) you need for a given amount of Newtonmeters. When you move that mass away from the center, you need less mass, changing at the same factor as rotational inertia changes. So no improvement or drawback in terms of rotational inertia, but improvement in terms of total mass (and improvement in terms of unsprung mass when comparing to a wheel motor in the hub).
In a way this is a transfer of semiconductor miniaturization to motors: when your power transistors can switch fast enough, you can replace fewer bigger coils with more smaller coils (that switch more often per rotation) and moving it all rimward gives you more torque per Newton. That ice skater effect? It's on your side.
That said, cars have 12v batteries. If the pi was better (again another gripe, choose better products not just what everyone else uses) you could put the thing to sleep. Even a good low power Linux machine can go years off one of those (quick math says like 100 years, so negligible draw). Or you could cut yourself off if the level gets below a threshold for too long. Plenty of solutions.
reply