I know this is repeating from the general discussion thread, but a zero latency bus system would be good.
I would have thought this is possible from a technical perspective, at least in some cases of a simple bus with no loops, etc.
If it can be done between racks by dragging racks onto other racks (i.e. between threads), it should be possible for the buses as well.
I suppose it might be a limitation of Delphi ?
Simon.
zero latency bus system
Curious thought, as multi-core processing and the handling of threads. I think I remember each rack then is on it's own thread. So I assume the primary track thread has priority of sending out before the auxiliary semaphore pushes the data to the rack with another thread. I assume this is where latency arrives. I have no clue what threading is done, but maybe if a separate thread was used in a rack that merged before the output and priorities were not set, less latency could be achieved? Curious if this action is a serial thread operation, or if it truly utilizes multiple threading per rack.
However, if you increase more sends per rack you would be cutting your thread count available in half right?
-s
However, if you increase more sends per rack you would be cutting your thread count available in half right?
-s
"Every act of creation is first an act of destruction." -Picasso
-
sm_jamieson
- Member
- Posts: 555
- Contact:
Its hard to know without knowing the internal structure of Usine.
Clearly the calculations along a signal path have to be serial since each stage has to be calculated before being passed to the next. And It has to be done in time before the bloc time period has been used up, else you would get drop outs - the Usine CPU monitor is actually a measure of the amount of time available for the bloc that is used up.
But why the delay is a full bloc size is not clear. It could be that the data can be passed onto the bus much quicker (i.e. thread for the other end of the bus could access the data), but since the main processing engine and "onProcess" is called once per bloc, the data going onto the bus has to wait until the next bloc to be processed by the next stage. But this would apply equally to the chaining of racks.
It would be interesting to know whether if you drag many racks into the next to create a very long chain, is the whole chain done with zero additional latency.
Either way, the issue must be to do with inter-thread communication since a single rack does not have the latency issue that inter-rack buses do.
Simon.
Clearly the calculations along a signal path have to be serial since each stage has to be calculated before being passed to the next. And It has to be done in time before the bloc time period has been used up, else you would get drop outs - the Usine CPU monitor is actually a measure of the amount of time available for the bloc that is used up.
But why the delay is a full bloc size is not clear. It could be that the data can be passed onto the bus much quicker (i.e. thread for the other end of the bus could access the data), but since the main processing engine and "onProcess" is called once per bloc, the data going onto the bus has to wait until the next bloc to be processed by the next stage. But this would apply equally to the chaining of racks.
It would be interesting to know whether if you drag many racks into the next to create a very long chain, is the whole chain done with zero additional latency.
Either way, the issue must be to do with inter-thread communication since a single rack does not have the latency issue that inter-rack buses do.
Simon.
Not a delphi limitation!
In a multi thread context, this request is to impossible conceptually...
The solution is, for the receive bus patch, to wait until all the send buses have been calculated, so we loose the multi-thread advantages.
You can try yourself the result: set the setup/nb threads = 1 and put your buses in the order you want to calculate/receive them. They will be Zero latency...
The main advantage of the actual bus system is that the latency is constant : 3ms on a normal config.
ps : the Zero latency for rack routing is not guaranty in all the cases.
In a multi thread context, this request is to impossible conceptually...
The solution is, for the receive bus patch, to wait until all the send buses have been calculated, so we loose the multi-thread advantages.
You can try yourself the result: set the setup/nb threads = 1 and put your buses in the order you want to calculate/receive them. They will be Zero latency...
The main advantage of the actual bus system is that the latency is constant : 3ms on a normal config.
ps : the Zero latency for rack routing is not guaranty in all the cases.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
sm_jamieson
- Member
- Posts: 555
- Contact:
I was wondering why the latency of the bus was always one bloc, but I understand that making it all as the worst case so that it is consistent is a good idea.
Simon.
Simon.
Who is online
Users browsing this forum: No registered users and 15 guests
