adjust zaptel/dahdi chunk size

I have been reading this document from sangoma whitepapers:
www.sangoma.com/assets/docs/misc/2009_10...isk_System_Loads.pdf

And I wonder if the same modifications can be applied by openvox engineers for a D210P.
Since it requieres modifications of timmings on zaptel/dahdi source code, I guess an official openvox patch will help.

Extract from the sangoma PDF (page 4 and 5):
........
Thus, the developers of zaptel/dahdi have now introduced a configurable chunk size that can be taken advantage of by any card that incorporates hardware echo cancellation. All non-analog Sangoma hardware is able to automatically detect the zaptel/dahdi chunk size and adjust accordingly. You can configure zaptel/dahdi for 8 bytes (1 ms - default), 16 bytes (2 ms), 40 bytes (5 ms) or 80 bytes (10 ms) chunk size.
What does that do for you?
It reduces the interrupt and context switching loads for the driver to a small fraction of its 1 ms value. Both the loads due to interrupt handling and context switches (changes from user space to kernel space) are reduced. The interrupts have to be handled whether or not calls are up, while the context switching load depends on the number of active calls.
.............
The reductions are quite dramatic. At 496 calls, the system load was reduced from 26% to 7%, as the chunk size goes from 8 bytes (1 ms) to 80 bytes (10 ms). That’s a decrease of over 70%. At idle, the reduction went from 15% down to a negligible 1%. Nearly all the benefi t is achieved by using a chunk size of 40 bytes, which is the maximum that gives reliable timing for meetme and music on hold. However, if you really want to go to the maximum, the cards all have an.....

Thanks for all your comments.

We are designing a new generate E1 card, which will support this feature.