Boeing Starliner

[Peter B]

To pull things back onto topic, can I point out a couple of Scott Manley videos in the last week, covering launch failures by a couple of new companies - Astra and Firefly (I assume you've all seen the sideways lift-off of the Astra). Which just goes to show that it's not just well-established companies that can suffer from rookie errors...

[jfb]

To pull things back onto topic, can I point out a couple of Scott Manley videos in the last week, covering launch failures by a couple of new companies - Astra and Firefly (I assume you've all seen the sideways lift-off of the Astra). Which just goes to show that it's not just well-established companies that can suffer from rookie errors...

I'm still amazed at the Astra's ability to recover; that could have been a wrecked pad.  The guidance and control guys deserve a case of beer over that. 

[Peter B]

To pull things back onto topic, can I point out a couple of Scott Manley videos in the last week, covering launch failures by a couple of new companies - Astra and Firefly (I assume you've all seen the sideways lift-off of the Astra). Which just goes to show that it's not just well-established companies that can suffer from rookie errors...

I'm still amazed at the Astra's ability to recover; that could have been a wrecked pad.  The guidance and control guys deserve a case of beer over that.

Agreed! I was so struck by what I saw that I showed the video to my kids. I explained to them that there are videos of spectacular rocket failures from the 1950s and 1960s where engine shutdowns straight after launch resulted in pretty much complete loss of control and big explosions close to the ground. Even they (after their fashion) were impressed by the Astra recovery - and laughed at Manley's "flamey-end down, pointy-end up" comment.

Having said that, as one commenter pointed out: just as well it wasn't the opposite-side engine that failed, otherwise the rocket would have slid sideways into the launch tower...

And regarding the Firefly launch, I was surprised the rocket survived its tumbling motion as long as it did. I thought rockets travelling other than straight ahead disintegrated quickly.

[cjameshuff]

I guess we've wandered way off topic from the thread's original subject, but I think the most outstanding piece of optimisation I've ever seen, and which still blows my mind, is the Fast Inverse Square Root.  The code looks like complete nonsense but gives a result within a percent or two of the actual value, and back in the days when Pentium processors were top of the range it was huge performance improvement, especially for graphics processing where 1/sqrt(x) is used a lot.  Even today it's still faster than general-purpose processors or libraries can achieve.

A good article on it is - https://medium.com/hard-mode/the-legendary-fast-inverse-square-root-e51fee3b49d9 - see if you can figure out how it works before reading the explanation   
(Warning - code contains sweary word...)

Most general purpose processors now have square root or reciprocal square root instructions that are considerably faster and more accurate. x86 has had such instructions for over two decades now. This algorithm is mainly only of significance today for historical interest or small embedded processors. (And in those, even the Cortex M7 I'm writing code for now has a VSQRT instruction.)

[molesworth]

I guess we've wandered way off topic from the thread's original subject, but I think the most outstanding piece of optimisation I've ever seen, and which still blows my mind, is the Fast Inverse Square Root.  The code looks like complete nonsense but gives a result within a percent or two of the actual value, and back in the days when Pentium processors were top of the range it was huge performance improvement, especially for graphics processing where 1/sqrt(x) is used a lot.  Even today it's still faster than general-purpose processors or libraries can achieve.

A good article on it is - https://medium.com/hard-mode/the-legendary-fast-inverse-square-root-e51fee3b49d9 - see if you can figure out how it works before reading the explanation   
(Warning - code contains sweary word...)

Most general purpose processors now have square root or reciprocal square root instructions that are considerably faster and more accurate. x86 has had such instructions for over two decades now. This algorithm is mainly only of significance today for historical interest or small embedded processors. (And in those, even the Cortex M7 I'm writing code for now has a VSQRT instruction.)

Good point - hardware FPUs are a lot better nowadays, and GPUs are just mind-bogglingly fast.  I guess I've spent too much time working on what are really low-performance processors recently, not on more widely used systems... 

However, even as a historical artefact the algorithm is a great example of brilliant optimisation and ingenuity.

[jfb]

To pull things back onto topic, can I point out a couple of Scott Manley videos in the last week, covering launch failures by a couple of new companies - Astra and Firefly (I assume you've all seen the sideways lift-off of the Astra). Which just goes to show that it's not just well-established companies that can suffer from rookie errors...

I'm still amazed at the Astra's ability to recover; that could have been a wrecked pad.  The guidance and control guys deserve a case of beer over that.

Agreed! I was so struck by what I saw that I showed the video to my kids. I explained to them that there are videos of spectacular rocket failures from the 1950s and 1960s where engine shutdowns straight after launch resulted in pretty much complete loss of control and big explosions close to the ground. Even they (after their fashion) were impressed by the Astra recovery - and laughed at Manley's "flamey-end down, pointy-end up" comment.

Having said that, as one commenter pointed out: just as well it wasn't the opposite-side engine that failed, otherwise the rocket would have slid sideways into the launch tower...

And regarding the Firefly launch, I was surprised the rocket survived its tumbling motion as long as it did. I thought rockets travelling other than straight ahead disintegrated quickly.

Yeah.  I don't remember if it was Manley or someone on another forum, but they had a comment to the effect that was a sign the stage was a bit over-engineered and could afford to shed some weight. 

[JayUtah]

Publicly held companies can still take risks, try to reach new markets or start projects that let them improve their capabilities. Boeing used to do so, even as recently as the Delta IV which they initially had commercial ambitions for...

Good point. I worked on the Delta IV payload interface.  That was back when Boeing still had some of the original impetus.

They make commercial satellite busses, but they're content with minor variations on what they've done before. They no longer seem interested in developing new products or capabilities of their own initiative.

Okay, yes, that's a convincing argument that it's not just fiduciary conservatism.  The notion that the new Boeing does stuff on the cheap has been well explored.  But a more recent problem is the plundering of assets that many American corporations seem to suffer.  The shareholders want short-term profits, which is not consistent with a ten-billion-dollar investment in a ten-year development project that may or may not pay off.  Incremental improvements to existing products would seem to produce more profits consistently in the short term, but would not lead to a sustainable company.

[JayUtah]

Optimizing a spin-delay function?

Yeah, that hits close to home.  We make a signal aggregator for telemetry that can capture up to 512 channels of data at 30 KS/s.  So its cycle time is just over 33 microseconds.  A lot of filtration and aggregation has to happen, so we absolutely cannot rely on a fixed execution time or a constant execution path.  I think it does use SIMD instructions on the Intel, though.  And yes, it has ASICs and FPGAs in it too.

One of the Easter eggs in it is that the error code it sends to the downstream recorder, in the event it falls behind and has to drop data, is numerical "1202."  I'm constantly amazed at how far ahead of its time the AGC seems to be.

And in general, you can usually make a much bigger difference by a change of approach at a higher level than you can in micro-optimizing every little piece of code. Implementing a more appropriate data structure or algorithm can make a bigger difference than any amount of time spent optimizing a search of an unsorted list.

All the guys who work on that signal aggregator used to be games programmers.  Some of them go back to cartridge game days, where everything was limited and you really had to know your stuff at all levels.  I love listening to these guys talk about all the innovative crazy stuff they had to do back in the day.

[cjameshuff]

One of the crazier things I've seen is a firmware-based Gigabit Ethernet implementation on an XCore processor. There was a bare minimum of hardware to support the physical interface, and one 8-core "tile" devoted to handling Ethernet processing. One core was dedicated to TX, just moving data between the serdes and RAM and doing initial CRC calculations. There was no time for jump instructions or evaluating loop conditions, so there was just a long block of output, load, and CRC instructions sized for a maximum-sized packet. The transmit code just jumped in at the appropriate spot for the actual packet size:
https://github.com/xmos/lib_ethernet/blob/b2ab6c876feae4f179a90e74e0202dfb51eb97d5/lib_ethernet/src/rgmii_tx_lld.S#L194

RX was more complicated. I never really had to dig into it, but it somehow involved two cores taking turns pulling in data with similarly unrolled loops, and two more dedicated to managing buffers and communications with the first two.

[molesworth]

All the guys who work on that signal aggregator used to be games programmers.  Some of them go back to cartridge game days, where everything was limited and you really had to know your stuff at all levels.  I love listening to these guys talk about all the innovative crazy stuff they had to do back in the day.

Oh, I could tell you lots of stories from those days   The analysis and debugging tools weren't that great so you needed a good understanding of how the hardware worked, and the compilers weren't as good as currently so hand-optimisation at assembler level wasn't unusual.  I think that's why (older) games developers fit in well in aerospace tech jobs.

[jfb]

Once again, I am grateful to have been nothing but a dumb applications programmer.  I've rarely had to deal with any kind of hardware weirdness, and that was only to address portability issues, not speed.  Speed issues were dealt with by using the proper algorithms (or lookup tables), but not to the level of "I must be able to reliably execute this task in X +/- Y ms" kinds of precision. 

I have seen glimpses of that world and want nothing to do with it. 

[molesworth]

Not good news for Boeing/Starliner :

NASA moves two astronauts off delayed Boeing missions to SpaceX in rare reassignment

NASA moved a pair of astronauts off Boeing’s first two crewed missions to a SpaceX mission next year, in a rare reassignment as the aerospace giant’s Starliner capsule remains delayed in development.

The U.S. space agency announced Wednesday that astronauts Nicole Mann and Josh Cassada will be the commander and pilot, respectively, of SpaceX’s Crew-5 mission in fall 2022.

[raven]

Ooh, Boeing, that's got to feel like a kick where the gods split 'em. Still, given how things have been, can we really be surprised?

[Zakalwe]

"If it's Boeing then you ain't going".

[jfb]

Today is the day.  Probably.

Starliner is on the Atlas, Atlas is on the pad, valves are purged, potential water ingress points are sealed and/or covered, weather looks pretty good. 

As much fun as it has been to bag on Boeing, this test really needs to succeed and not reveal any more significant problems; now that Soyuz flights are pretty much off the table ... forever, we need that dissimilar redundancy for manned flights.  Awesome as SpaceX has been, they're not infallible. 

Ars has another article making the case that Boeing is the reason the commercial crew program was allowed to exist; had it just been SpaceX and other NuSpace players, Congress wouldn't have approved and funded the program.  It's only because Boeing decided "what the hell, we do space good, we'll play" that the program exists.