here is quick update... Even if I did take a break, I believe I still have residual effects of the program.
I did a small change. In fact, I had no idea if it would have any positive effect on the system performance. My expectations were very low. It was more like an experiment to perform for the sake of completeness so that I check a mark beside this idea in the list of things that I have tried to improve the system performance.
Concretely, the idea is that inside my event loop, the thread is blocking and the kernel is setting its state to sleeping. When stuff happens, the kernel change back the thread state to running and set it back in the list of processes to schedule. Even if my thread is configured to be Real-Time and have the highest scheduling priority, simply putting the task to sleep and make a context switch to make it run again when events are available appears to have a very high overhead.
The experiment was to configure the thread to create a busy loop. It is loop without never blocking. The trade-off of doing so is that you use more the CPU to essentially doing nothing and this increase the electricity consumption of the machine... but you skip the context switch overhead when something to do happens...
I got a big surprise. That must be the best single improvement that I have done so far to improve the system reaction time. I must have reduced the reaction time by about 20% with this single change...
Next time crypto markets experience a bumpy period, I should get better execution rate with this...
this is cool!
I did a small change. In fact, I had no idea if it would have any positive effect on the system performance. My expectations were very low. It was more like an experiment to perform for the sake of completeness so that I check a mark beside this idea in the list of things that I have tried to improve the system performance.
Concretely, the idea is that inside my event loop, the thread is blocking and the kernel is setting its state to sleeping. When stuff happens, the kernel change back the thread state to running and set it back in the list of processes to schedule. Even if my thread is configured to be Real-Time and have the highest scheduling priority, simply putting the task to sleep and make a context switch to make it run again when events are available appears to have a very high overhead.
The experiment was to configure the thread to create a busy loop. It is loop without never blocking. The trade-off of doing so is that you use more the CPU to essentially doing nothing and this increase the electricity consumption of the machine... but you skip the context switch overhead when something to do happens...
I got a big surprise. That must be the best single improvement that I have done so far to improve the system reaction time. I must have reduced the reaction time by about 20% with this single change...
Next time crypto markets experience a bumpy period, I should get better execution rate with this...
this is cool!
