Day: November 21, 2018

Creating Black Holes: Division By Zero In Practice

November 21, 2018 by 31 Comments

Dividing by zero — the fundamental no-can-do of arithmetic. It is somewhat surrounded by mystery, and is a constant source for internet humor, whether it involves exploding microcontrollers, the collapse of the universe, or crashing your own world by having Siri tell you that you have no friends.

It’s also one of the few things gcc will warn you about by default, which caused a rather vivid discussion with interesting insights when I recently wrote about compiler warnings. And if you’re running a modern operating system, it might even send you a signal that something’s gone wrong and let you handle it in your code. Dividing by zero is more than theoretical, and serves as a great introduction to signals, so let’s have a closer look at it.

Chances are, the first time you heard about division itself back in elementary school, it was taught that dividing by zero is strictly forbidden — and obviously you didn’t want your teacher call the cops on you, so you obeyed and refrained from it. But as with many other things in life, the older you get, the less restrictive they become, and dividing by zero eventually turned from forbidden into simply being impossible and yielding an undefined result.

And indeed, if a = b/0, it would mean in reverse that a×0 = b. If b itself was zero, the equation would be true for every single number there is, making it impossible to define a concrete value for a. And if b was any other value, no single value multiplied by zero could result in anything non-zero. Once we move into the realms of calculus, we will learn that infinity appears to be the answer, but that’s in the end just replacing one abstract, mind-boggling concept with another one. And it won’t answer one question: how does all this play out in a processor? Continue reading “Creating Black Holes: Division By Zero In Practice” →

3D Printer Warning: Heating Plastic To High Temps Is Not Healthy

November 21, 2018 by 42 Comments

If you’ve ever tried to cut a piece of acrylic with a tool designed to cut wood or metal, you know that the plastic doesn’t cut in the same way that either of the other materials would. It melts at the cutting location, often gumming up the tool but always releasing a terrible smell that will encourage anyone who has tried this to get the proper plastic cutting tools instead of taking shortcuts. Other tools that heat up plastic also have this problem, as Gizmodo reported recently, and it turns out that the plastic particles aren’t just smelly, they’re toxic.

The report released recently in Aerosol Science and Technology (first part and second part) focuses on 3D printers which heat plastic of some form or other in order to make it malleable and form to the specifications of the print. Similar to cutting plastic with the wrong tool, this releases vaporized plastic particles into the air which are incredibly small and can cause health issues when inhaled. They are too small to be seen, and can enter the bloodstream through the lungs. The study found 200 different compounds that were emitted by the printers, some of which are known to be harmful, including several carcinogens. The worst of the emissions seem to be released when the prints are first initiated, but they are continuously released throuhgout the print session as well.

Perhaps it’s not surprising that aerosolized plastic is harmful to breathe, but the sheer magnitude of particles detected in this study is worth taking note of. If you don’t already, it might be good to run your 3D printer in the garage or at least in a room that isn’t used as living space. If that’s not possible, you might want to look at other options to keep your work area safe.

Thanks to [Michael] for the tip!

Jittery Back Off To Speed Up

November 21, 2018 by 6 Comments

In systems where there are multiple participants who need to interact with a shared resource some sort of concurrency protection is usually appropriate. The obvious technique is to use locking (and fun words like “mutex”) but this adds a constant performance hit as every participant needs to spend time interacting with the lock regardless of the number of other participants. It turns out this is actually a Big Problem that garners original research, but there are techniques that can yield great effect without a PhD. Years ago [Marc] posted a great walkthrough of one such method, exponential backoff with jitter, to Amazon’s AWS blog which is a great introduction to one such solution.

The blog post was written specifically to deal systems using a specific technique called optimistic concurrency control (OCC) but that doesn’t mean the advice isn’t generally applicable. OCC refers to a method where each writer checks for a write collision only after performing the write (but before committing it), which works well in scenarios where writes are relatively uncommon. [Marc] observed that even in systems where this is a safe assumption things bog down significantly when there are too many writers clamoring for attention all at once.

The traditional solution to such a problem is for each writer to pause for an exponentially increasing amount of time before trying again, but as writers come back in big groups the same problem can recur. He provides a discussion of simple modifications to that strategy which result in significantly reduced wait times for writers.

Problems like this are not especially relevant for single Arduino sensor networks, but even small groups of systems can have concurrency trouble and it’s nice to see such an accessible write up with solutions which are viable even for simple systems. Bonus points to [Marc] for posting source to his test tool online. It doesn’t require anything outside of your computer to run (no AWS required) so if you have any brainwaves about speeding up multi-writer environments it might make a nice test environment! Maybe don’t mention the blog post in your PhD applications though.