Am 22.08.2011 18:55, schrieb Oliver Hartkopp: > On 22.08.2011 17:04, "Müller, René" wrote: > >> Am 19.08.2011 17:27, schrieb "Müller, René": >>> Am 17.08.2011 11:43, schrieb Oliver Hartkopp: >>>> Am 17.08.2011 10:38, schrieb "Müller, René": >>>>> Hi all, >>>>> >>>>> I have an performance issue with socketcan and an MPC5200B. My setup >>>>> looks like this: >>>>> - MPC5200B board (TQM5200) >>>>> - custom base board with two PCA82C251, one for each can controller >>>>> - linux-2.6.27.18-denx, I use the mpc52xx driver >>>>> - booted with uboot and kernel from flash >>>>> - mount root filesystem via NFS >>>>> - can0 with 1Mbit/s >>>>> - candump -l can0 to tmpfs >>>> Hi René, >>>> >>>> can you check if the frames are dropped on socket-level? I assume, that >>>> the candump is not able to dump the stuff into tmpfs at full speed. >>>> >>>> See details at: >>>> >>>> http://www.mail-archive.com/[email protected]/msg00170.html >>> Hi Oliver, >>> >>> thanks for the hint. I tried it, and indeed I lose my frames because I'm to >>> slow with fetching them. I will take a look, if I find a better mechanism >>> to dump the frames. >> Hi Oliver, >> >> I made some tests with increased rx buffer size and a hacked candump. I want >> to dump every frame in an 30 second time span, so I increased the rx buffer >> with candump -r to 20000000. In candump I disabled the live-dump to the log >> file. When I press a key, I set a "nothing passes" filter, so that the >> socket rx buffer contains the last ~25s (1Mbit/s with >90% busload). Then I >> start writing the frames to my candump log file until the buffer is empty. >> So far this solution is fine (no data is lost), but it eats my memory. For >> this ~25s I need ~100MB ram. My board has only 128MB, so this is way too >> much and I cannot increase the buffer further (I'm still missing ~5s). >> >> I took a look at the kernel code and I think the socket buffer has some >> "slight" overhead in case of can. There is an huge structure used to store >> the 8 bytes of one can frame. I'm afraid that this structure is needed. >> >> I think my main problem is the system call overhead of recv/recvmsg, because >> I tried to store the data in an circular buffer (from boost libraries) >> entirely in ram and I'm still losing data. The only way I get the frames >> without data loss seems to increase the socket buffer. >> >> At the moment I see 3 options: >> 1. Decrease memory demand of the socket buffer (to fit my 30s into <30MB) >> 2. Put more than one can frame into one socket buffer structure to minimize >> the overhead >> 3. Try lincan with hopefully less system call overhead >> >> What do you think I should try? Do you see another option to get the frames >> at such high busload without data loss? >> > > Hi René, > > i would try move the problem into userspace. > > The skbuff struct contains indeed much more than just the 16 bytes used by the > can_frame. If you can make an estimation about how many frames you receive in > this 30 seconds, you could create a big array of struct can_frames in > userspace that holds the (binary) CAN frames in userspace. > > After the 30 seconds, you can dump the binary frames into a file. IMO not > getting the frames from the socket is the problem, but writing to a file. > > An increased socket buffer size still gives you some additional safety, that > you don't lose frames, when writing the file. > > Do you also need the timestamps? > > If so, i would add them to an other new big array containing the the (64 bit) > timestamps. I don't know if it's better to save timestamp offsets, as this > would probably cost more CPU time than just copying the timestamps. > > What do you think about this idea? Hi Oliver,
I like this idea. I liked it so much, that I just tried it :) But the results are not exactly what I want. I used candump as base and created a simple array, as you suggested (only for the frames, none for the timestamps. I need them, but for testing purposes I can life without them). Now the problem is the cpu load, again. I have ~18-20% idle time and ~60% for candump. Basically I can dump the frames this way, but in my application dumping the frames is not the only task. I need a bit more cpu time than the remaining 20%. When I used the increased socket buffer size I had plenty cpu time available (>70%), but no memory for my application left. With an simple buffer I have plenty of memory available (>90MB), but not enough cpu time left. :( It seems, that I have to optimize either the memory consumption of the socket buffer or the cpu load of the frame fetching. Maybe the right tradeoff between user space and socket is the clue. I'm familiar with linux, but I'm no kernel hacker. I think, you have way more experience in this area (at least you implemented many stuff in kernel space for socketcan ;) ), so do you think I can get my application running with one of the three options from above? Or I'm missing some "simple" other option? (beside from switching the cpu, of course) Best regards, René > Regards, > Oliver > > _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
