On Tue, 12 Oct 2004, Stephen R. Besch wrote: > > That is pretty much what I said. The lack of buffering is a feature - > > latency is the enemy in telecomunications. That is why I said 100-200us > > should be acceptable. This should be redily aceivable, even with shared > > interrupts. > > > 200us probably would be. And, you could probably get average interrupt > latency that low. The problem is that in any real machine, even when > operating in real time mode, maximum interrupt latency is much longer - > sometimes in the ms range - and the standard deviation isn't that great > either. If you don't believe it, hook a scope up to one of the active > interrupt request lines on the bus. It's very revealing.
There really cannot be that much of a problem - it works! We see a few missed interrupts a day on our TE405P and the machine is really stock. >From my experience the jitter on the interrupts is really low. We used to run a user-space based app that bit-banged a can bus at 1kHz. No misses were allowed or the log would have to be restarted. This worked even with X running. From user-space. There were no real problems, and after a few tewak basicall no missed deadlines. Of course, any broken driver that took a long time to service its interrupts would have left us dead in the waters. I'm just saying we never had a problem. The jitter was on the order of 100us or so. Anyway, shared or not shared interrupts should not have a great effect on servicing interrupts. No unless either of the two drivers are taking a long time just to determine that they were not the intended receiver of the interrupt. For even stricter timings there is the realtime interrupts from http://linuxdevices.com/articles/AT6105045931.html. 5 us worst case. Nice. :-) Peter _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
