Notices by Vertigo (vertigo@mastodon.social), page 10

@jjg @haitch While I agree with you, not having to worry where the next rent check is coming from is singularly liberating when it comes to creative endeavors. :-)

One of the biggest challenges I'm facing right now is how to convey packets of data across an asynchronous serial link without imposing too heavy an overhead.

PPP framing can potentially bloat packets up to 50% overhead (e.g., sending a block of 256 $7E bytes will result in 512 bytes being sent over the wire, as those need to be escaped).

Looking at CRC-framing at the moment. But, this comes with its own challenges. :/

Spent all day evaluating ByteLink versus RapidIO, and I've come to the conclusion that I can't really do much better than RapidIO.

Hat's off to the RapidIO development folks. This is a *wickedly* well-designed protocol stack.

I still might not end up using it for the #Kestrel3 only because of LUT limitations in the FPGA, but hot dang, if I had a bigger chip to play with, I'd be using it right out of the box.

@luigithirty That is awesome. Maybe some day you can get back into the project, if for no other reason than just making it a hobby.

The 68000 family is my all-time favorite CISC architecture. It's a pity that it hasn't yet been extended into supporting 64-bit integers and addresses yet. The so-called 68070 supports 64-bit SIMD lengths, but that's it.

@luigithirty For clarification, asynchronous here means in the same sense that RS-232 or RS-485 are asynchronous. AS/DTACK style asynchrony is a bit different; my "BackBone" backplane idea had that (being based on Wishbone interconnect), but I rejected that as well -- just too expensive to implement for the performance that I would have gotten.

Packet/message-based "buses" are definitely the way forward.

The #kestrel3 may have just gotten significantly more powerful without me realizing it. All because one person asked an excellent and deeply introspective question right here on Mastodon.

I have to be careful; I feel like I'm still in that excited high one gets when having an epiphany. But I *really* like the outcome of that discussion, though it took as long as it did for me to finally post that article.

So very, very glad I got that blog article done when I did.

Just in the nick of time, too. Looks like I have some thinking to do on ByteLink (which will now fragment into two technologies: one for RS-232-ish serial interfaces, and one for 4-bit connections).

Which is just as well; I never liked the name "ByteLink" anyway; it should rightfully be called "NybbleLink", and that's just what's going to happen going forward.

@Aerdan Cat's right. Cats are always right. The error is you think the cat shouldn't think it's his throne. 😉

I was asked, close to three weeks ago now, why I had desired an asynchronous backplane.

Turns out, it's not such a good idea after some thinking on it, but not for the reasons you might think.

I wrote a long-form article about it, and along the way, realized that I'd made an error in how to implement the #kestrel3 .

So, from one humble question came a lengthy soul-searching exercise, and hopefully, new ideas for the Kestrel.

http://chiselapp.com/user/kc5tja/repository/kestrel-3/wiki?name=Ruminations+on+Expanding+the+Kestrel-3

attn @jond

@haitch @jjg Note that I'm not bitter at all; I'm merely delineating the reason why my progress is so slow with the Kestrel. :-) If there's ever a time when I seem angry or bitter, it's usually the case that I'm angry at myself for my lack of productivity. But, I also have to remember, when working commercially just three years ago, I almost drove myself to suicide from clinical levels of burn-out too.

I may be slow in progress, but hopefully I'll still be alive when I'm done. ;)

@haitch @jjg I'm the first person in the world to recommend people look at other alternatives until the #kestrel3 is ready for real-world deployment. I've already recommended Raspberry Pi computers to friends and family on numerous occasions, perhaps to their dismay. But they weren't willing to wait for "when it's done."

Unless someone is willing to fund development full-time for two years straight at San Francisco Bay Area rates, the Kestrel will always be on a "when it's finished" schedule.

@haitch @jjg I have no particular HPC experience at all. I have spent many years in a data center building and racking servers, repairing them as they go down, etc., but from an operations or programming experience, I know nothing more about HPC than what I can read on Wikipedia.

That said, I know technologies like RapidIO and Infiniband are big with large HPC clusters precisely because of their peer-to-peer nature, allowing them to break the limitations imposed by hierarchical I/O systems.

@jjg @haitch @enkiv2 @alcinnz As VPNs show, "layer 1" is definitely not always a physical layer.