Re: kernelTimeSlice clarification


Jeffrey Creem wrote:

Sorry, I realize now that my response in the morning was not clear as I
left out an important detail. What I was trying to get to was determine
if buffers were being filled by a task that was doing the filling by
polling on the availability of some data (v.s. waiting for an
interrupt). I am starting to get some idea of what you are doing but not
quite there yet.

When you talk about interrupts above, it certainly leaves me wondering
if you really mean interrupts in a true hardware sense or if you are
mixing terms.

My initial question about this (and I don't know that I am any closer to
understanding the answer) was really focused on the way the thread
started -- asking about kerneltimeslice.

If you really have two sources of data, and these two sources of data
are interrupt driven and the destination output spooling is interrupt
driven, and the buffers are sized correctly, there is no reason to
believe that doing any sort of timeslicing could do anything but hurt
the situation.

So, lets step back for a moment and ask some more simple questions
before we dig into the tasking/interrupt structure questions.

1) I believe you said that the destination can write 400 Mbytes/Sec.
Have you demonstrated that or is it based on specs and expectations?

2) If demonstrated, how was the testing done. Was it done in a manner
where (potentially) all available CPU and perhaps memory bandwidth was
allowed to be used by the destination processing? -- If so, then there
is none available for the 'source' processing.

3) 400 Mbytes per second is a very fast rate even by todays standards if
you are talking about files. All sorts of things can conspire to prevent
you from meeting that sort of a rate. It only takes a few drivers doing
copies on things at various levels before suddenly the massive speed of
even you DRAM starts to fail to keep up.


Before looking into the complexity of scheduling, semaphores and the
like, try doing something like having just one source attempt to send
the same data twice per arrival. If you can't make that work at
400Mbytes/sec, your problems are not related to your
tasking/semaphores/context switching, etc.

The vendor has an api suite one of which requires a user callback
function. In a nutshell the destination allocates a buffer. The size
of the buffer along with buffer address and a callback function is
passed to the vendor api's. The source once initialized gets a
"handle" to the buffer. The souce dma's data to the destination, then
notifies the destination. This notification is in the form of a pci
interrupt. Translation when notified the callback function gets
invoked. Within the callback function semaphores are given to the
appropriate task. As for the data rates. Yes benchmarks were done
using a single source. The benchmarks confirmed vendor numbers. Alas
our conversation reminded me of one thing. For a single souce pci
works fine. For multiple sources pci can no longer be used since this
results in collision. Since the vendor api does support two forms of
interrupts I'll retrofit source code to use a different vendor api.
This should assist in my understanding of some issues I encountered
when I decided to use multiple sources. I'll keep you posted.

.

Relevant Pages

  • Re: kernelTimeSlice clarification
    ... The destination allocates two 4MB buffers for each source. ... connects to its representative buffer and writes at offsets within its ... Source 1 writes at offset 2 MB within buffer. ... Upon receipt of an interrupt ...
    (comp.os.vxworks)
  • Re: problem with dyn. extending/shrinking array
    ... I have an interrupt function that kicks in when I can receive a byte ... // buffer was allocated with calloc ... measurement at a rate of once a second, you can use a timer interrupt ... If you have a clock with millisecond ...
    (comp.lang.c)
  • Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
    ... * There are three lists which are used to keep track of the different states ... * are cleared, the interrupt is de-asserted. ... * Data Buffer Allocation Helpers ... the driver's private data structure ...
    (Linux-Kernel)
  • Re: 2.6.11-rc1-mm1
    ... the only way this will fail is if an interrupt occurred ... index value needs to get reloaded from memory each time around the loop. ... > Frankly this is legacy code for when ltt only supported one trace buffer, ... As Roman suggested, relayfs ...
    (Linux-Kernel)
  • Re: Handling SSC interrupts in Applesoft BASIC
    ... He has written an assembly-language program that reads and writes to the ... A little background on the concept of an interrupt. ... the initial interrupt handler does some ... No idea where the rest of the 256 char buffer is (John's ...
    (comp.sys.apple2.programmer)