Matthias Fuchs wrote: > On Thursday 11 March 2010 17:46, Kurt Van Dijck wrote:
>> Try to look at it this way: poll()/select() only work well if you know >> you're the _only_ user using the file (reason: if more users use the same fd, >> user A can write between B's calls to poll() & write()). > This really makes poll/select unusable. I really like the idea (of the esd > CAN driver) that multiple applications can use/share one CAN interface without > really interfering. Up to now I was not really aware of SocketCAN's shared > txqueue. The potential problem come up with different applications having different communication concepts. An example with applications A and B: A want's to send data every 100 ms B communicates with ISO-TP 15765-2 transportprotocol Assuming the communication parameters of ISO-TP are set to transmit CAN frames with 0ms frame distance: Sending a 4095 byte ISO-TP PDU will generate 4095/7 = 585 CAN frames, that are pushed into the tx queue en-bloc(!!). Imagine what happens to A's cyclic sent frames ... at 500 kbit/s they are blocked for at least 649ms :-( The idea to solve this problem could be an implementation of CAN-capable queueing disciplines (qdisc) inside the Linux kernel. As you might know qdiscs from peer-to-peer data throttling, you would need to specify new approaches for CAN-qdics according the CAN use-cases. E.g. SFQ (stochastic fair queueing) with round robin scheduling by using 2048 queues (for 11-bit CAN Ids) could be an approach. Quite interesting idea, i think. E.g. for a diploma thesis ;-) Regards, Oliver _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
