porting code from VRTX on 68K to vxWorks on pentium - VxWorks

This is a discussion on porting code from VRTX on 68K to vxWorks on pentium - VxWorks ; I have a project which is a port of code from a 68K based VRTX system to a vxWorks (5.5.1) based penitum system and we are very displeased with the execution speed. On the original hardware (68040 @ 25 MHz), ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: porting code from VRTX on 68K to vxWorks on pentium

  1. porting code from VRTX on 68K to vxWorks on pentium

    I have a project which is a port of code from a 68K based VRTX system
    to a vxWorks (5.5.1) based penitum system and we are very displeased
    with the execution speed.

    On the original hardware (68040 @ 25 MHz), the two time critical tasks
    take 1.33 and 1.49 mS each to execute. On the new hardware (pentium3
    at 1.8 GHz) the same two tasks take 1.40 and 1.54 mS respectively.

    The application code is a direct port of the C source code from VRTX on
    a 68K to VxWorks on a P3 with the only changes being those required by
    the OS differences and a few related to control register bitfields (big
    endian vs. little endian).

    We expected a speed increase of _at least_ an order of magnitude. I
    have gone though the code and verified that there aren't any taskDelay
    calls or hardware accesses that would account for this.

    Does anyone have any ideas as to why the code on a much faster
    processor is running in basically the same timeframe. Better yet,
    any ideas how to make it faster?

    I have the target shell and wbd tasks included in the build, how much
    are they affecting the execution speed of lower priority tasks?

    JiMZ


  2. Re: porting code from VRTX on 68K to vxWorks on pentium

    Hi:

    How are you doing these timings? Do you have access to Windview - you
    could see if the task is blocked on something at some point.

    Are these tasks purely computational also. If you have the ability to
    do precise timings and the ability to still run on both systems, I
    start with something smaller than your full systems and time those.

    The spy task may also shed some light on what's going on.

    Larry
    jimzat wrote:
    > I have a project which is a port of code from a 68K based VRTX system
    > to a vxWorks (5.5.1) based penitum system and we are very displeased
    > with the execution speed.
    >
    > On the original hardware (68040 @ 25 MHz), the two time critical tasks
    > take 1.33 and 1.49 mS each to execute. On the new hardware (pentium3
    > at 1.8 GHz) the same two tasks take 1.40 and 1.54 mS respectively.
    >
    > The application code is a direct port of the C source code from VRTX on
    > a 68K to VxWorks on a P3 with the only changes being those required by
    > the OS differences and a few related to control register bitfields (big
    > endian vs. little endian).
    >
    > We expected a speed increase of _at least_ an order of magnitude. I
    > have gone though the code and verified that there aren't any taskDelay
    > calls or hardware accesses that would account for this.
    >
    > Does anyone have any ideas as to why the code on a much faster
    > processor is running in basically the same timeframe. Better yet,
    > any ideas how to make it faster?
    >
    > I have the target shell and wbd tasks included in the build, how much
    > are they affecting the execution speed of lower priority tasks?
    >
    > JiMZ



  3. Re: porting code from VRTX on 68K to vxWorks on pentium


    LarryC wrote:
    > Hi:
    >
    > How are you doing these timings? Do you have access to Windview - you
    > could see if the task is blocked on something at some point.
    >
    > Are these tasks purely computational also. If you have the ability to
    > do precise timings and the ability to still run on both systems, I
    > start with something smaller than your full systems and time those.
    >
    > The spy task may also shed some light on what's going on.


    Hi Larry,

    The timings are accomplished by setting analog levels on a D/A board to
    10 volts at the top of the task loops and 0 volts at the bottom of the
    task loops. The tasks pend on semaphores just before setting the
    analog to 10 volts, the semaphores are released by the ISR of a 10 mS
    hardware clock. From this configuration, we can see that the tasks run
    for less the 2 mS each and sit idle for over 8 mS.

    The code is not all purely computational, in order to rule out any
    external events or varying logic, I bracketed a function which simply
    contains (a lot of) Boolean math, ANDs and ORs, and find that this
    function takes around 1.2 mS to execute (on both platforms).

    I have not tried WindView yet, but since these are the highest priority
    tasks (aside from OS tasks), I doubt that it will show anything. I
    _have_ tried spy, but it interferes with my hard real-time
    requirements. After shifting spy's priority, it shows that these two
    tasks are using around 50% of my CPU, with 36% IDLE.


  4. Re: porting code from VRTX on 68K to vxWorks on pentium

    Hi:

    I still think somethings uo with your timings. Top to bottom within
    your task, I believe your numbers, but I think something else is going
    on to interrupt your task's execution, whether it's another task or
    some interrupts.

    I'd taskLock and intLock the task at the top and bottom and see what
    you get.

    The percentages of time you say you are using are pretty high given the
    processor speed.

    LC
    jimzat wrote:
    > LarryC wrote:
    > > Hi:
    > >
    > > How are you doing these timings? Do you have access to Windview - you
    > > could see if the task is blocked on something at some point.
    > >
    > > Are these tasks purely computational also. If you have the ability to
    > > do precise timings and the ability to still run on both systems, I
    > > start with something smaller than your full systems and time those.
    > >
    > > The spy task may also shed some light on what's going on.

    >
    > Hi Larry,
    >
    > The timings are accomplished by setting analog levels on a D/A board to
    > 10 volts at the top of the task loops and 0 volts at the bottom of the
    > task loops. The tasks pend on semaphores just before setting the
    > analog to 10 volts, the semaphores are released by the ISR of a 10 mS
    > hardware clock. From this configuration, we can see that the tasks run
    > for less the 2 mS each and sit idle for over 8 mS.
    >
    > The code is not all purely computational, in order to rule out any
    > external events or varying logic, I bracketed a function which simply
    > contains (a lot of) Boolean math, ANDs and ORs, and find that this
    > function takes around 1.2 mS to execute (on both platforms).
    >
    > I have not tried WindView yet, but since these are the highest priority
    > tasks (aside from OS tasks), I doubt that it will show anything. I
    > _have_ tried spy, but it interferes with my hard real-time
    > requirements. After shifting spy's priority, it shows that these two
    > tasks are using around 50% of my CPU, with 36% IDLE.



  5. Re: porting code from VRTX on 68K to vxWorks on pentium


    LarryC wrote:
    > Hi:
    >
    > I still think somethings uo with your timings. Top to bottom within
    > your task, I believe your numbers, but I think something else is going
    > on to interrupt your task's execution, whether it's another task or
    > some interrupts.
    >
    > I'd taskLock and intLock the task at the top and bottom and see what
    > you get.
    >
    > The percentages of time you say you are using are pretty high given the
    > processor speed.
    >
    > LC
    > jimzat wrote:
    > > LarryC wrote:
    > > > Hi:
    > > >
    > > > How are you doing these timings? Do you have access to Windview - you
    > > > could see if the task is blocked on something at some point.
    > > >
    > > > Are these tasks purely computational also. If you have the ability to
    > > > do precise timings and the ability to still run on both systems, I
    > > > start with something smaller than your full systems and time those.
    > > >
    > > > The spy task may also shed some light on what's going on.

    > >
    > > Hi Larry,
    > >
    > > The timings are accomplished by setting analog levels on a D/A board to
    > > 10 volts at the top of the task loops and 0 volts at the bottom of the
    > > task loops. The tasks pend on semaphores just before setting the
    > > analog to 10 volts, the semaphores are released by the ISR of a 10 mS
    > > hardware clock. From this configuration, we can see that the tasks run
    > > for less the 2 mS each and sit idle for over 8 mS.
    > >
    > > The code is not all purely computational, in order to rule out any
    > > external events or varying logic, I bracketed a function which simply
    > > contains (a lot of) Boolean math, ANDs and ORs, and find that this
    > > function takes around 1.2 mS to execute (on both platforms).
    > >
    > > I have not tried WindView yet, but since these are the highest priority
    > > tasks (aside from OS tasks), I doubt that it will show anything. I
    > > _have_ tried spy, but it interferes with my hard real-time
    > > requirements. After shifting spy's priority, it shows that these two
    > > tasks are using around 50% of my CPU, with 36% IDLE.


    Hi Larry,
    Out of curiosity asking ,Will not including taskLock and UNLOCK add up
    to more delays in the system in the case described above?

    Regards,
    s.subbarayan


  6. Re: porting code from VRTX on 68K to vxWorks on pentium

    Measuring the time between when your task starts and ends doesn't
    really represent amount of CPU time used in your task, given other
    things like interrrupts and other tasks can be running.

    Using windview or some taskhook calls to see what's going on might
    help.

    task and int locking your code should lead to more accurate timings of
    what's going on.

    lc
    ssubbarayan wrote:
    > LarryC wrote:
    > > Hi:
    > >
    > > I still think somethings uo with your timings. Top to bottom within
    > > your task, I believe your numbers, but I think something else is going
    > > on to interrupt your task's execution, whether it's another task or
    > > some interrupts.
    > >
    > > I'd taskLock and intLock the task at the top and bottom and see what
    > > you get.
    > >
    > > The percentages of time you say you are using are pretty high given the
    > > processor speed.
    > >
    > > LC
    > > jimzat wrote:
    > > > LarryC wrote:
    > > > > Hi:
    > > > >
    > > > > How are you doing these timings? Do you have access to Windview - you
    > > > > could see if the task is blocked on something at some point.
    > > > >
    > > > > Are these tasks purely computational also. If you have the ability to
    > > > > do precise timings and the ability to still run on both systems, I
    > > > > start with something smaller than your full systems and time those.
    > > > >
    > > > > The spy task may also shed some light on what's going on.
    > > >
    > > > Hi Larry,
    > > >
    > > > The timings are accomplished by setting analog levels on a D/A board to
    > > > 10 volts at the top of the task loops and 0 volts at the bottom of the
    > > > task loops. The tasks pend on semaphores just before setting the
    > > > analog to 10 volts, the semaphores are released by the ISR of a 10 mS
    > > > hardware clock. From this configuration, we can see that the tasks run
    > > > for less the 2 mS each and sit idle for over 8 mS.
    > > >
    > > > The code is not all purely computational, in order to rule out any
    > > > external events or varying logic, I bracketed a function which simply
    > > > contains (a lot of) Boolean math, ANDs and ORs, and find that this
    > > > function takes around 1.2 mS to execute (on both platforms).
    > > >
    > > > I have not tried WindView yet, but since these are the highest priority
    > > > tasks (aside from OS tasks), I doubt that it will show anything. I
    > > > _have_ tried spy, but it interferes with my hard real-time
    > > > requirements. After shifting spy's priority, it shows that these two
    > > > tasks are using around 50% of my CPU, with 36% IDLE.

    >
    > Hi Larry,
    > Out of curiosity asking ,Will not including taskLock and UNLOCK add up
    > to more delays in the system in the case described above?
    >
    > Regards,
    > s.subbarayan



  7. Re: porting code from VRTX on 68K to vxWorks on pentium

    use a high res timer counter (that runs without interrupt) to save
    timestamps / high-res tick values at beginning and end of your code.
    Also, record intCnt values at beginning and end.

    The values should tell you exact elapsed time for the code execution.
    And how many interrupts occurred (if any) during execution of the code.

    It could also be floating point support code which is triggering
    exceptions.

    jimzat wrote:
    > LarryC wrote:
    > > Hi:
    > >
    > > How are you doing these timings? Do you have access to Windview - you
    > > could see if the task is blocked on something at some point.
    > >
    > > Are these tasks purely computational also. If you have the ability to
    > > do precise timings and the ability to still run on both systems, I
    > > start with something smaller than your full systems and time those.
    > >
    > > The spy task may also shed some light on what's going on.

    >
    > Hi Larry,
    >
    > The timings are accomplished by setting analog levels on a D/A board to
    > 10 volts at the top of the task loops and 0 volts at the bottom of the
    > task loops. The tasks pend on semaphores just before setting the
    > analog to 10 volts, the semaphores are released by the ISR of a 10 mS
    > hardware clock. From this configuration, we can see that the tasks run
    > for less the 2 mS each and sit idle for over 8 mS.
    >
    > The code is not all purely computational, in order to rule out any
    > external events or varying logic, I bracketed a function which simply
    > contains (a lot of) Boolean math, ANDs and ORs, and find that this
    > function takes around 1.2 mS to execute (on both platforms).
    >
    > I have not tried WindView yet, but since these are the highest priority
    > tasks (aside from OS tasks), I doubt that it will show anything. I
    > _have_ tried spy, but it interferes with my hard real-time
    > requirements. After shifting spy's priority, it shows that these two
    > tasks are using around 50% of my CPU, with 36% IDLE.



  8. Re: porting code from VRTX on 68K to vxWorks on pentium

    I ran windView and it shows that the two tasks in question run straight
    through with only a single clock interrupt (tickAnnounce() call) in
    each.

    Someone commented that "if the code has lots of ANDs and ORs, maybe
    that's creating a lot of branches in the code that defeat the prefetch
    and cache." One portion of the code, which is built as an individual
    module, is nothing but Boolean math (lots of ANDs and ORs). Does
    anyone have any gcc command line switch suggestions?

    JiMZ


    LarryC wrote:
    > Measuring the time between when your task starts and ends doesn't
    > really represent amount of CPU time used in your task, given other
    > things like interrrupts and other tasks can be running.
    >
    > Using windview or some taskhook calls to see what's going on might
    > help.
    >
    > task and int locking your code should lead to more accurate timings of
    > what's going on.



+ Reply to Thread