[asterisk-dev] Increasing DAHDI_CHUNKSIZE, what consequences?

[Thomas Petazzoni]

Hello all,

Any suggestion about the below questions?

Thanks,

Thomas

On Thu, 7 Aug 2014 09:57:33 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> I am currently writing a driver for the XHFC ISDN chip from Cologne
> Chip, which is interfaced over SPI with an ARM processor (i.e it's not
> the typical PCI card setup). The fact that it's over SPI means that
> talking to the XHFC chip is quite slower than talking to memory-mapped
> devices such as PCI devices.
> 
> With the default DAHDI_CHUNKSIZE of 8 bytes, we need to have an
> interrupt every millisecond to push and pull data from/out of the XHFC
> chip. And it's quite difficult to do all the necessary SPI
> communication in one millisecond (not really transferring the 8 bytes,
> but doing all the administrative stuff such as reading the interrupt
> flags, etc.). Getting interrupts every millisecond is also generating a
> fairly significant CPU load.
> 
> Ideally, we would like to be able to get less interrupts, like only
> every 4 ms, and therefore push and pull 32 bytes of data at each
> interrupt.
> 
> This would however require raising the DAHDI_CHUNKSIZE to 32 bytes
> instead of the default 8 bytes. What are the consequences of such an
> increase of the chunk size ?
> 
> Back in 2010, there was a thread at
> http://lists.digium.com/pipermail/asterisk-ss7/2010-March/003544.html
> showing that apparently wasn't really simple. And the document at
> http://www.sangoma.com/assets/docs/misc/2009_10_09_How_to_Reduce_Asterisk_System_Loads.pdf
> indicates that if you use any other value than 8 bytes for
> DAHDI_CHUNKSIZE, you cannot use any software echo cancellation. But
> both of these things are 4-5 years old, so I'm not sure to what extent
> they apply to the current DAHDI code base.
> 
> Do you have any insights/experience about the possibility of raising
> the DAHDI_CHUNKSIZE ?
> 
> Thanks a lot,
> 
> Thomas



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com