kernelTimeSlice clarification - VxWorks

This is a discussion on kernelTimeSlice clarification - VxWorks ; Two sources disseminating data to a destination. Each source can accomodate 200MB/sec transfers across it's link. Simply put, the destination has two - 'pipes' if you will for each source. Upon receipt of the data, the destination will write the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: kernelTimeSlice clarification

  1. kernelTimeSlice clarification


    Two sources disseminating data to a destination. Each source can
    accomodate 200MB/sec transfers across it's link. Simply put, the
    destination has two - 'pipes' if you will for each source. Upon
    receipt of the data, the destination will write the data out to a
    file. The destination is capable of writing data at 400 MB max.

    For 100MB worth of data per source, the mathematics suggests .5
    seconds for each source. Profiling does suggests .5 seconds for a
    single source.

    My sysClkRate is 60 ticks.

    While some of this might boil down to architecure.

    The question. In a round robin based scheme my kernelTimeSlice should
    be set to to - at a minimum - 30. Correct?

    For some reason I'm not seeing ~400 MiB per second when two sources
    are involved utilizing a round robin setup. I'm seeing ~200->210 MB/
    sec.


  2. Re: kernelTimeSlice clarification

    forums_mp@hotmail.com wrote:
    > Two sources disseminating data to a destination. Each source can
    > accomodate 200MB/sec transfers across it's link. Simply put, the
    > destination has two - 'pipes' if you will for each source. Upon
    > receipt of the data, the destination will write the data out to a
    > file. The destination is capable of writing data at 400 MB max.
    >
    > For 100MB worth of data per source, the mathematics suggests .5
    > seconds for each source. Profiling does suggests .5 seconds for a
    > single source.
    >
    > My sysClkRate is 60 ticks.
    >
    > While some of this might boil down to architecure.
    >
    > The question. In a round robin based scheme my kernelTimeSlice should
    > be set to to - at a minimum - 30. Correct?
    >
    > For some reason I'm not seeing ~400 MiB per second when two sources
    > are involved utilizing a round robin setup. I'm seeing ~200->210 MB/
    > sec.
    >


    If reasonably implemented, it is not clear why one would even round
    robin scheduling to make this work and it is not really clear there is
    enough data here still to answer the question (i.e. you'd need to know
    the max depth of the buffers that are involved for the read side and the
    write side -- if time slices are required for this implementation, the
    max buffer depth would need to be known and obviously, if the buffers
    are being filled at the task level (v.s. interrupt level) then this will
    probably fail no matter what you do).

  3. Re: kernelTimeSlice clarification


    Jeffrey Creem wrote:
    > >

    > If reasonably implemented, it is not clear why one would even round
    > robin scheduling to make this work and it is not really clear there is
    > enough data here still to answer the question (i.e. you'd need to know
    > the max depth of the buffers that are involved for the read side and the
    > write side -- if time slices are required for this implementation, the
    > max buffer depth would need to be known and obviously, if the buffers
    > are being filled at the task level (v.s. interrupt level) then this will
    > probably fail no matter what you do).



    Appreciate the response. Let me elaborate on the buffers for a minute.
    The destination allocates two 4MB buffers for each source. Each source
    connects to its representative buffer and writes at offsets within its
    respective buffer. Writes are done in 2 MB chunks. For example. Source
    1 writes at offset 0 within buffer. Source 1 then interrupts
    destination. Source 1 writes at offset 2 MB within buffer. Source 1
    interrupts destination. The process repeats with each source doing the
    same thing. On the destination side. Upon receipt of an interrupt
    counting semaphores are given to representative tasks. Having said
    all this. Could you elaborate on why this might fail no matter what I
    do? For a single souce. I observe the expected throughput. For two
    sources things fall apart. This leaves me perplexed. Thanks in
    advance.


  4. Re: kernelTimeSlice clarification

    forums_mp@hotmail.com wrote:
    > Jeffrey Creem wrote:
    >> If reasonably implemented, it is not clear why one would even round
    >> robin scheduling to make this work and it is not really clear there is
    >> enough data here still to answer the question (i.e. you'd need to know
    >> the max depth of the buffers that are involved for the read side and the
    >> write side -- if time slices are required for this implementation, the
    >> max buffer depth would need to be known and obviously, if the buffers
    >> are being filled at the task level (v.s. interrupt level) then this will
    >> probably fail no matter what you do).

    >
    >
    > Appreciate the response. Let me elaborate on the buffers for a minute.
    > The destination allocates two 4MB buffers for each source. Each source
    > connects to its representative buffer and writes at offsets within its
    > respective buffer. Writes are done in 2 MB chunks. For example. Source
    > 1 writes at offset 0 within buffer. Source 1 then interrupts
    > destination. Source 1 writes at offset 2 MB within buffer. Source 1
    > interrupts destination. The process repeats with each source doing the
    > same thing. On the destination side. Upon receipt of an interrupt
    > counting semaphores are given to representative tasks. Having said
    > all this. Could you elaborate on why this might fail no matter what I
    > do? For a single souce. I observe the expected throughput. For two
    > sources things fall apart. This leaves me perplexed. Thanks in
    > advance.
    >


    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.



  5. 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.


+ Reply to Thread