Well I dont mean to intrude, but IMHO, this looks like a multithreading requirement in userspace. writes are generally blocking calls and if the application intends to fill in another buffer during the time the write call is being executed, let him use multithreading in userland and that will solve his problem.. Or am I missing something ? Bashuman "Nagaraj" <nagaraj@smartyantra.com> on 10/17/2002 05:19:52 PM To: "Momchil Velikov" <velco@fadata.bg> cc: "kernelnewbies" <kernelnewbies@nl.linux.org> (bcc: Bashuman Dev/HSSDLF) Subject: Re: real-time process > Can you post a pseudocode of the variant with "blocking call" ? U want another bullshit ? > I'm > really tempted to call the above code bullshit and utter crap, I agree ..but that gets the work done ! And with no dirty ways. Im using only the features provided in linux how does it become crap ? >but, > hey, one can always learn something new, maybe in fact it is a fine > example of programminng excelence and I'm a complete idiot. > let others decide abt it. > Why the "blocking call" variant performed so poorly ? i told it in prev mails..( READ THEM WELL ! ) look at the sequence: suppose u do a blocking write, probably the driver does interruptible_sleep_on() and waits for irq_handler() wake it up. When data xfer is complete, irq_handler wakes it up. NOTE: Now the xfer is stopped. then blocking write returns to application THEN application starts filling in the data into the buffer ( Time reqd to fill in the buffer ). Then again driver calls write. This fill time of application is goin to screw up ur display. as xfer is in terms of Mbits even small delay means large data. So idea is if u can make use of multiple buffers, make write non blocking. when device xfers from first buffer...( DMA does it, so CPU neednt worry ) fill in next buffers simulteneously. When xfer is complete DMA gives control to irq_handler, which sets up the next DMA and also kill_fasync() the application. So the delay between two DMA xfers is just the interrupt latency. ( which would be around 100us max ) Now this achieves both synchromization and low buffer switching latency. However u need to arrive at proper buffer size and number of buffers u need. U can do that by considering the CPU speed, DMA speed, and the bandwidth of xfer. ( design issue again ) thats it... want to hear more bullshit ? -nagaraj \(*_*)/ > > ~velco > > -- > Kernelnewbies: Help each other learn about the Linux kernel. > Archive: http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/ -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
