Re: [LAU] [LAD] Update of jconv

On Wed, Dec 02, 2009 at 08:19:06AM -0500, Paul Davis wrote: In the general case this would be correct, SCHED_FIFO does not in any way ensure that threads get a 'fair share of time'. But this is not the general case. In cases such as the one discussed, the threads are triggered at a divisor of Jack's period rate. Each time they get a quantum of work, perform it, and wait for the next trigger. They do not try to run for as long as they can. The threads do not compete on CPU time: the assumption is always that there is enough CPU power to perform all the work. If this is not the case the whole thing fails anyway. The 'competition' is on the order in which they are allowed to run, and for that priority is the only criterion. The objective of the priority scheme is to allow all threads to meet their deadline, not to give them equal CPU shares. They don't need equal CPU shares anyway, in most cases the bulk of the work is done by the lowest priority ones. An example should make this clear. Assuming the period size is 256, running the 'Great Hall' reverb in jconvolver, configured for a minimum partition size of 256 (no processing delay) will result in the following threads: (you can use -v to see this) prio = 0, offs = 0, parsize = 256, npar = 3 prio = -1, offs = 768, parsize = 512, npar = 6 prio = -3, offs = 3840, parsize = 2048, npar = 6 prio = -5, offs = 16128, parsize = 8192, npar = 13 The first one is Jack's process thread, this will do the work for 3 partitions of size 256. The second one will do 6 partitions of size 512, it will be triggered every two periods. The next one runs every 8 Jack periods, the last one every 32. The last three are required to have completed their work when the next trigger arrives. Their output is actually only required later, 3 periods after the start for the size 512, 15 periods for the size 2048, and 31 for the last. This gives the whole system some robustness it would not have if everything was planned 'just in time'. Note that the extra margin is small for small partition sizes and quite big for the larger ones. Now if the same reverb is configured to use a minumum period size of 4096 (because the user can tolerate the delay and wants less CPU load) this would look different: prio = -4, offs = 0, parsize = 4096, npar = 2 prio = -5, offs = 8192, parsize = 8192, npar = 14 As you can see the priorities match the partition size. In this case no work is done in Jack's thread. Now assume that I would use the scheme of version 1.0.0. Then the priorities would be -1 512 -2 2048 -3 8192 and -1 4096 -2 8192 respectively. This would mean that the size 4096 thread of the second instance would have the same priority as the size 512 thread of the first. The time required for the size 4096 calculations could easily be longer than the period of of the size 256 thread. This would result in the size 256 thread being late every time it has to wait for the other to complete, which could happen every 16 periods. Matching priorities to period size removes this problem, and ensure that the most urgent work will always be done first.