Ok, so to prove a point I wrote an ascom driver simulator in Visual Studio c#.
It allows various permuations based on frequency of request from a client app, time taken to process call by controller, a throttling feature etc.
It takes around10 milliseconds minimum for a controller to respond to a isMoving request. Other calls can be longer as there is more data being sent at 9600bps and maybe some maths involved. Get temp could be as long as 1/2 second or longer
Log files by popular client apps lcan issue hundreds of calls for get posision and ismoving and temperature every second. I have seen logs where calls are lesss than 3ms and even 1ms apart at times. I have seen up to 15 isMoving calls one after the other in less than 10ms
Now if a controller takes a minimm of 10mS to respond to a simple request - and calls are arriving 3ms or less apart - it dont take a rocket scientist to do that the math that this is impossible.
Imaging you are driving a car. Your passenger is screaming at you all the time, turn left, turn right, go straight, turn around, and that this is NONSTOP, one after the after, hell, u aint even finished the first turn left and they are all the way up to turn around - what do you think should be happening?
What we have seen over the last couple of years is client app developers going multithreaded. But they have not serialized the command queue, channelling this through a worker thread, meaning that the apps now have multiple threads firing off controller commands each not knowing what the other is doing. Hence app thread1 fires off a get ismoving, threasd2 goes oh I want to know temp, fires that off, thread3 wants to know ismoving because it is thinking about autofocus, fires off an ismoving - all of this happening in the space of a 2-3 milliseconds. There is zero corrordination in the client threads, its just spaghetti code with zero structure handling the comms side. Is it that bad. Hell yes and more so. Logs do not lie.
Most ASCOM developers try to handle this with throttling. What that means is do some calls, return a cached copy for other calls. We are trying to stop the controller from falling over due to what is happening on the client side. What has become apparent with the recent updates to the some recent apps is this has become worse, much much worse. To the point that even throttling is starting to fail. This is because there now appears to be timers placed into these updates that work like this - send an move command - send ismoving command - if I dont get a change in about 10ms or so I assume the controller is stuffed. Can you begin to see the problem here. These apps are failiy to understand how drivers work and that they need more time to respond.
So, to prove a point I wrote a little ascom client simulator (standalone) that lets one play with requests coming from a client app, what the throttling feature is, time taken to process a call by the controller, and it runs a timer firing off requests - when told to stop it displays a siummary.
I will post it here.
But first - pic1 shows where the client app is sending a request to the driver every 5ms, the driver is doing throttling based on 10ms (10ms must elaspe between same calls before a command is sent to the controller - or just return a cache copy) - note that every request is passed to the controller and that there are 6 DROPPED calls which cannot be responded to because the controller is just too busy.
Next pic2 - the client app is still firing off requests every 10ms now, but throttling has been set to 60ms which mean basically one 1 in 6 is being sent to the controller and the other 5 using cached copies. The resut now is 0 missed calls.
So throttling works - BUT the issues we now have to resolve is the expectation by the client app developers that when they have an expectation that something is meant to change - such as issue move, check for ismoving, that it is unrealistic to expect this change to happen immediately, it is unrealistic that think its going to happen in 10ms and not try and set arbitary limits on when it should change (<10ms).
I totally lost it. Apologies. Its been a rough week.
That’s the best rant I’ve seen this year , well done Robert.
James Wood
Sent from my iPhone
Ok, so to prove a point I wrote an ascom driver simulator in Visual Studio c#.
It allows various permuations based on frequency of request from a client app, time taken to process call by controller, a throttling feature etc.
It takes around10 milliseconds minimum for a controller to respond to a isMoving request. Other calls can be longer as there is more data being sent at 9600bps and maybe some maths involved. Get temp could be as long as 1/2 second or longer
Log files by popular client apps lcan issue hundreds of calls for get posision and ismoving and temperature every second. I have seen logs where calls are lesss than 3ms and even 1ms apart at times. I have seen up to 15 isMoving calls one after the other in less than 10ms
Now if a controller takes a minimm of 10mS to respond to a simple request - and calls are arriving 3ms or less apart - it dont take a rocket scientist to do that the math that this is impossible.
Imaging you are driving a car. Your passenger is screaming at you all the time, turn left, turn right, go straight, turn around, and that this is NONSTOP, one after the after, hell, u aint even finished the first turn left and they are all the way up to turn around - what do you think should be happening?
What we have seen over the last couple of years is client app developers going multithreaded. But they have not serialized the command queue, channelling this through a worker thread, meaning that the apps now have multiple threads firing off controller commands each not knowing what the other is doing. Hence app thread1 fires off a get ismoving, threasd2 goes oh I want to know temp, fires that off, thread3 wants to know ismoving because it is thinking about autofocus, fires off an ismoving - all of this happening in the space of a 2-3 milliseconds. There is zero corrordination in the client threads, its just spaghetti code with zero structure handling the comms side. Is it that bad. Hell yes and more so. Logs do not lie.
Most ASCOM developers try to handle this with throttling. What that means is do some calls, return a cached copy for other calls. We are trying to stop the controller from falling over due to what is happening on the client side. What has become apparent with the recent updates to the some recent apps is this has become worse, much much worse. To the point that even throttling is starting to fail. This is because there now appears to be timers placed into these updates that work like this - send an move command - send ismoving command - if I dont get a change in about 10ms or so I assume the controller is stuffed. Can you begin to see the problem here. These apps are failiy to understand how drivers work and that they need more time to respond.
So, to prove a point I wrote a little ascom client simulator (standalone) that lets one play with requests coming from a client app, what the throttling feature is, time taken to process a call by the controller, and it runs a timer firing off requests - when told to stop it displays a siummary.
I will post it here.
But first - pic1 shows where the client app is sending a request to the driver every 5ms, the driver is doing throttling based on 10ms (10ms must elaspe between same calls before a command is sent to the controller - or just return a cache copy) - note that every request is passed to the controller and that there are 6 DROPPED calls which cannot be responded to because the controller is just too busy.
Next pic2 - the client app is still firing off requests every 10ms now, but throttling has been set to 60ms which mean basically one 1 in 6 is being sent to the controller and the other 5 using cached copies. The resut now is 0 missed calls.
So throttling works - BUT the issues we now have to resolve is the expectation by the client app developers that when they have an expectation that something is meant to change - such as issue move, check for ismoving, that it is unrealistic to expect this change to happen immediately, it is unrealistic that think its going to happen in 10ms and not try and set arbitary limits on when it should change (<10ms).
Point made.
Last edit: brownrb 2018-04-17