AF_ISDN / RAW B-channels and different Rx/Tx Clocks
Harald Welte <[email protected]> Sat, 12 May 2018 16:59:54 +0200
| Newsgroups | gmane.linux.isdn.i4l.user |
|---|---|
| Message-ID | <20180512145954.GH9313@nataraja> |
Hi! In the Osmocom project, in libosmo-abis, we have an E1 input driver for mISDN. When using raw B-channels via mISDN, we use the following philosophy for timing our transmits: * Whenever we receive a PH_DATA_IND from the kernel about received data, we also send a PH_DATA_REQ back to the kernel As it occurred to me recently, this might actually be problematic if the Rx and Tx clock of the E1 link are not identical. This is actually quite normal in a variety of situations. There is nothing in the E1 specs that I know of which would force the Rx and Tx clocks to be somehow locked to each other. Sure, there's the general +/-50ppm accuracy, but that's it. And if you intereconnect between multiple clock domains (operators, PBXs, ...) , then of course there will be some drift relative to each other. So let's assume the Rx data is arriving at a slower clock than the clock at which we transmit. Over time, this will add up and at some point it will result in a buffer underrun of the mISDN kernel code/driver, as it the hardware will want to pull more bits for the given B-channel, but the application code hasn't yet sent it, as it's send interval is locked to the receive interval of PH_DATA_IND. What is the proper solution here? How can a userspace process use AF_ISDN and time its PH_DATA_REQ independent of PH_DATA_IND on the Rx side? Thanks! [1] http://git.osmocom.org/libosmo-abis/tree/src/input/misdn.c#n319 Regards, Harald -- - Harald Welte <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)