On Tuesday 16 March 2010 18:18, Oliver Hartkopp wrote: > 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. Yes, I ended up with the same thoughts :-) > > 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. This could end up in an endless story. > > Quite interesting idea, i think. E.g. for a diploma thesis ;-) Of course and I really like the idea of using the socket's tx queue.
Matthias _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
