Jigsaw daytradr “Refresh Rate” – Faster than the human eye?

In this article, we’ll discuss the way Jigsaw daytradr gets information in front of your eyeballs as quickly as possible whilst avoiding performance issues when the market “speeds up”. The speeding up of a market is most obvious when news hits but there are other shorter-term increases in pace when (for example) stops get hit. Both have to be considered when developing a trading platform. 

Unfortunately – the reason we are doing this is partly because a certain trading educator has been and continues to spread some bizarre (and technically perplexing) rumors about Jigsaw and other retail trading platforms. For the sake of keeping it short AND classy – we’ll not name names, we’ll just refer to this vendor as “Sheila”. Sheila’s subscribers pay to attend monthly meetings where a decent proportion of the time is spent disparaging Jigsaw. The claim being made is that daytradr and other retail platforms “Have a refresh rate that is too slow for this type of trading”.  It’s a claim that’s popped up on a few forums since – this post is partly to put the rumors to bed but also – to inform on how we keep the display up to date without melting your CPU. 

So what is the refresh rate in Jigsaw daytradr? 

There isn’t one. There is no refresh rate in daytradr. We’ll explain how the screen gets updated in a second – but it does not “refresh” like an old Disney cartoon. 

As you likely know – old cartoons were a series of drawn images that were shown at high speed. The brain filled in the gaps, giving the appearance of movement. In the iconic “Steamboat Willie”, there were 24 frames per second, so the refresh rate was 24 times per second or 24Hz. The screen you are reading this on is probably somewhere between 60-144 frames per second or 60Hz-144Hz.

Steamboat Willie was released in 1928. Almost 100 years ago. Each of those 24 frames per second contained a new image of the entire screen. Hence the term “refresh rate” – the entire screen is being refreshed – 24 times a second. Or roughly every 50ms. But why 50ms? Well – if it was 200ms, the cartoon would appear “jerky” and the transitions would not be smooth. It could be 10ms – BUT the human eye would not notice any difference between that and 50ms (although this is much debated by movie nerds).  10ms would require 5x as many drawings from Mr Disney and 5x the labor costs. So – at 24fps – you get the benefits of tricking the human eye/brain to perceive movement, at the lowest cost.

It’s basic eyeball science – and it’s used a lot in software – like the gaming industry, video production, etc. 

So if we don’t use refresh rates, what do we use?

The human eyeball is analog. It does not work in “frames”. In daytradr’s Depth & Sales (the part of Jigsaw Sheila is disparaging) – we update the screen pixel by pixel as data comes in. We update only the pixels that are changing – more in line with the analog mode of the eyeball than a “refresh all” Steamboat Willie cartoon. If a new trade (level 1/time and sales) comes in, then we’d update 3 “cells” on Depth & Sales…

As a new trade comes in, we have to update the “current trades” column (yellow arrow) but also, we need to update the inside bid (red arrow). After all, if the inside bid WAS 46, then 26 traded – the bid is going to be reduced by 26 (red arrow). Then finally, we update the LTQ column (green arrow). The trigger for these updates is the data coming in. So as data comes in, the data triggers the update to your screen. No timers or refresh rates are controlling the frequency of updates but there is overload detection. Refreshing the entire screen is unnecessary as the technology allows us to update any area of the screen, at any time we want at low-cost CPU/GPU-wise.

So how do we stop extreme scenarios from causing lags?

Historically, there have always been two types of data feed. Filtered and unfiltered. Filtered feeds omit some messages – you would not normally notice this with the naked eye but it does result in trades occasionally being reported on the wrong side as we move from one price to another. The leading professional trading platform’s data does this (yes, that one). You may be using a filtered feed and see no difference between that and an unfiltered feed – until news or stops hit. The filtering is there to ensure you are up to date on price (so you know where the market is) at the expense of some data that is getting updated so frequently that you wouldn’t see it anyway. It is mostly L2 messages that are filtered out. If you are a screen trader – filtered feeds are great. If you are an HFT – probably not so much – as you likely want to be examining every l2 update. In our case, we don’t have to handle peaks in filtered feeds as often as unfiltered. We don’t care which it is – but just be aware that some performance handling/peak prevention is done data-side. 

In a stop run, thousands of trades can occur in the same instant. Imagine a scenario where 1000 Sell market orders exist at a price and they get triggered. Within a millisecond or possibly two (forget latency for a second) – we’ll have received the messages.  That’s 1000 sell market orders, 1000 updates to the inside bid, 1000 updates to LTQ column. In addition, as we’ll likely be ticking down – we also refresh every bid and offer as they all step down AND do some cleanup where data once sat to show it’s no longer there. Let’s say it’s a conservative 4,000 pushes to the UI from that 1 millisecond burst of data.  What do we do? Do we push each of those 5000 updates individually one by one to your screen? No – because you would not see them anyway. There are 2 reasons for this:

• Remember Steamboat Willie updating every 50ms/24Hz? Well – if we updated 5000 times in 1 millisecond, we’d be at 5 million times per second or 5,000,000Hz. I think we all know that this is well outside the range of what the human eye/brain can perceive.
• Most of you are running with a monitor that has a refresh rate of 60-144Hz or 60 to 144 times per second. So if we go higher than that in the app – the hardware can’t go higher. 

Stop runs are unique in that they occur in an instant – but then are over in an instant. Overloads also occur when news hits – but it’s a different type of overload. It’s usually a case of a moderate amount of orders hitting the market over a longer period (but still often just seconds) – but with a LOT of movement in price because of a lack of liquidity (bids/offers). It’s a slightly different case and a slightly different way to handle overloads. Like stop runs – it’s an exception, not the norm.

All trading platforms need to handle peaks in data without locking up. It makes little sense to update the screen more frequently than 144Hz (144 times per second) right now as that’s a hardware limitation. On the other hand, it’s not as simple as implementing a 144Hz refresh rate (once every 6.9ms). So the design considers:

• A human eyeball that has no refresh rate (it’s analog) – but that is “fooled” by refresh rates of 24fps
• Display hardware running at 144Hz
• A CPU running at 2,000,000,000 Hz

Without giving out design information – our solution is to detect AND resolve overloads at timeframes well below those that fool the human eye. While it is hard to perceive CPU timeframes – billions of cycles per second, it’s easy to comprehend that 144Hz is extremely sluggish relative to CPU speeds. So the key is to use CPU speed to detect a potential issue with screen updating.

And that’s where the “trick” is with throttling – it’s off by default and might kick in every few hours. When it does kick in – it’s happening at timeframes below human perception – all made possible by the fact that modern CPUs run millions of times faster than the human eye can see.  

For more on the science of the human eye and refresh rates – click here