Another one of those days . . . If the executable is using a small amount of CPU, it is very likely the file descriptor is a blocking descriptor, and very likely to be the majority of the performance problem.
Looking at the code, and seeing the use of select() though I would *assume* the file descriptor is non blocking. But assuming anything, often has a way of coming back and biting one's backside. On Tue, Sep 29, 2015 at 4:25 PM, William Hermans <[email protected]> wrote: > *OK, so while the executable is running. How much CPU is being used ? The >> reason I ask may be less than obvious, but I'm asking because I do not know >> what type pruIo *is*. But the assignment of this type looks remarkably >> similar to mmap(). e.g. a file mapped to a region in memory.* > > > err . . .heh , What I was getting at here is that if the executable is > using more than say 5% CPU. Then there is a good possibility that the file > descriptor object is non blocking. But if the executable is using a small > amount of CPU, then it most likely is a non blocking file descriptor. Which > in English means it is probably the majority of the "slowness" problem. > > On Tue, Sep 29, 2015 at 4:08 PM, William Hermans <[email protected]> > wrote: > >> OK, so while the executable is running. How much CPU is being used ? The >> reason I ask may be less than obvious, but I'm asking because I do not know >> what type pruIo *is*. But the assignment of this type looks remarkably >> similar to mmap(). e.g. a file mapped to a region in memory. >> >> So a few things to take notice of. >> >> First, you're making a call to select() every while loop iteration. That >> is to say: every 1ms, assuming the OS lets you. select() I believe is a >> system call, and can slow things down. If the call to the file descriptor >> object is blocking. It can slow things down quite considerably. Here, >> again, I'm not familiar with TJF's library to know. One potential "fix" >> might be to change the file descriptor object to O_NONBLOCK using fcntl(). >> Then perhaps look into using epoll() which has none of the performance >> issues that select(), or poll() have. Which is something I do not >> experience with personally, but have been reading a lot about lately for my >> own purposes. >> >> Second, you making a call to every while loop cycle to fprintf() which >> has to format 8 variables down to every 1ms. fprintf(), I'm not very >> familiar with, but if it is similar to printf() this can be another >> performance hit. With that said, I'm not sure how you could avoid this. >> That is to say, I know what the function does, I just have never read the >> actual implementation code . . . so could not tell you how it does, what it >> does. I'm assuming, it behaves exactly like printf(), but allows one to >> send this formatted output to an alternate "file stream". Without . . >> .heh . . . "magic hand waving". >> >> Thirdly, and I'm still not quite sure how often this happens. Because I >> have not even a clue what the TEMP_FAILURE_RETRY macro does. Here, Im >> assuming it returns some condition based on the state of the file >> descriptor( ready read, etc ). But once you break out of the while loop, >> into the outside do loop, you have *cough* 3 what I think are also system >> calls to tcgetattr(). But once again, I'm not all that familiar with termios >> either . . . >> >> Anyway, are you seeing a pattern here ? For very performant code, system >> calls are *baaaaaaaaad*. Did I emphasize that enough ? This is why many >> people when working with file descriptors often use mmap() Or rather is one >> very good reason why. Unfortunately I'm also not all that familiar with the >> ADC on this platform either . . . However, assuming there is a sysfs pseudo >> file available for the ADC, using mmap() to map to it should not be all >> that difficult. After that, I think the majority of the difficulty would be >> working out timing. Or in other words it is very possible using mmap() on >> the file descriptor to the ADC and just pumping that data straight into the >> termios buffer may be too fast. >> >> Anyway, sorry I could not answer your question better . . . but hopefully >> I did give you a few things to consider. Perhaps TJF can elaborate on some >> of the points I made, and prove / disprove what I'm assuming in many cases. >> >> On Tue, Sep 29, 2015 at 1:38 PM, Rathin Dholakia < >> [email protected]> wrote: >> >>> Hi, >>> Thank u very much for prompt response. I am using the default C wrapper >>> example from libpruio and modified it. HEre are the changes and the paste >>> bin >>> >>> Modifications: >>> 1. changed steps - 8 >>> 2. Made delay = 0, >>> 3. Start sample delay = 0 >>> Paste bin: http://pastebin.com/yBHdN548 >>> <iframe src="http://pastebin.com/embed_iframe.php?i=yBHdN548"; >>> style="border:none;width:100%"></iframe> >>> >>> On Wednesday, September 30, 2015 at 1:59:05 AM UTC+5:30, William Hermans >>> wrote: >>>> >>>> Well essentially, you probably need a review of your code. If it's >>>> large, past it on a pastebin site, and give us a link here. Also ALL code >>>> would be best. bit's and pieces won't be enough. >>>> >>>> On Tue, Sep 29, 2015 at 1:16 PM, Rathin Dholakia <[email protected]> >>>> wrote: >>>> >>>>> Dear Community Members, >>>>> >>>>> I am trying to implement a fast 8 channel Analog capture using on >>>>> board ADC on BBB. I know there are only 7 available on pin header, but as >>>>> I >>>>> am starting off & learning I am ok with count of 7. :) >>>>> >>>>> I just wanted to have an opinion about the approach to opt for, What >>>>> would be the most optimum (& preferably faster to implement) option to >>>>> achieve it? >>>>> >>>>> I have read quite a few articles and thread (& more confused ) and >>>>> currently I am using libpruio >>>>> <http://beagleboard.org/project/libpruio/> for implementing it but as >>>>> of now even after configuring libpruio I am only getting 900 - 1000 >>>>> samples >>>>> per seconds. >>>>> >>>>> So, is it my configuration wrong or for such high speed I should opt >>>>> for external ADC? or something else? >>>>> >>>>> I am completely NEW to EMBEDDED domain. So please pardon me. >>>>> >>>>> It would be great if someone could guide me, precisely towards some >>>>> direction. >>>>> >>>>> Sincerely, >>>>> Rathin >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
