Jittery Back Off To Speed Up

November 21, 2018 by Kerry Scharfglass 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.

Arduino SPI Library Gains Transaction Support

August 1, 2014 by Edward Becker 32 Comments

To prevent data corruption when using multiple SPI devices on the same bus, care must be taken to ensure that they are only accessed from within the main loop, or from the interrupt routine, never both. Data corruption can happen when one device is chip selected in the main loop, and then during that transfer an interrupt occurs, chip selecting another device. The original device now gets incorrect data.

For the last several weeks, [Paul] has been working on a new Arduino SPI library, to solve these types of conflicts. In the above scenario, the new library will generate a blocking SPI transaction, thus allowing the first main loop SPI transfer to complete, before attempting the second transfer. This is illustrated in the picture above, the blue trace rising edge is when the interrupt occurred, during the green trace chip select. The best part, it only affects SPI, your other interrupts will still happen on time. No servo jitter!

This is just one of the new library features, check out the link above for the rest. [Paul] sums it up best: “protects your SPI access from other interrupt-based libraries, and guarantees correct setting while you use the SPI bus”.

Pumping 1080p Video Out Of An FPGA

March 8, 2013 by Mike Szczys 14 Comments

fpga-pumping-1080p

[Hamster] admits this 1080p HDMI hack for an FPGA doesn’t put a signal that’s fully up to specifications. But as you can see in the image above it does output a 1920×1080 image at 60 Hz, which is the size and frequency of full HD video. It falls just short due to some jitter, which may be just fine if this is only being used for early prototyping and will be replaced with a dedicated encoder later in the design process.

Here he’s chosen a Pipistrello board but thinks that any device which has a Spartan 6 chip with the differential pairs connected to an HDMI socket will work. The difficulty of the task comes in serializing four output channels at 1500 Mb/s each. Because of this just coding your logic isn’t going to work. After roughing out the design [Hamster] went back in and chose to manually place some of the components to ensure that data from each channel arrives at the same time.

While you’re messing with HDMI you may also want to give this overlay hack a try.