Controllers/TPs slow or?

Jorde_VJorde_V UX ScientistPosts: 393
I haven't run into any issues perse, but I was just curious. Aren't the processors really slow, considering they had faster ones in 1996? (intel pentium pro with 541 MIPS)

The small ones (700/900) are 304 MIPS and the bigger ones (x100) are 404 MIPS.

And a ARM Cortex A8 has 2000 MIPS (which is used in a lot of cellphones and other small form devices).

If they used that in the controllers/TPs wouldn't we be able to squeeze out much quicker response times? not to mention more tasks in a shorter amount of time?

I couldn't find the speed of the TPs, don't know if anyone else knows it. But I was just hoping to get quicker responses this way. As I noticed the TPs are kinda slow sometimes when they have a little 'dip'.

Just throwing this out there. Hope to get some insights from the more experienced people.

Comments

  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I don't think processor speed is the bottleneck, it's communications speed. The panel sends a message to the processor, the processor spits out IR or RS_232 to the device, the device responds. You have several steps more than, "the remote sends a signal to the device, the device responds." It's even worse when you have to wait for a response, parse it, then display it. And I suspect, in that entire chain, that "the panel sends a message to the processor, and the processor spits out a command," is the most laggy part of the whole operation, considering the amount of overhead going into actually doing all that. Processor speed can improve the whole scenario, but exchanging communications is limited by the nature of the communications themselves, and whatever timing, waits, and cross checks are necessary to be sure they went through properly.

    Add to that, panel messages could be anything. By nature, being prepared for anything and everything is necessarily more complex and time consuming than, being prepared for one specific thing only.
  • ColzieColzie Senior Member Posts: 470
    Nerieru wrote: »
    As I noticed the TPs are kinda slow sometimes when they have a little 'dip'.

    Is this a wired or wireless panel? I definitely can tell the difference, wireless ones are just a tad laggy...sometimes, not always. Wired ones are very solid.
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,159
    It has been my experience that when I identified a truly slow processor in the master, it ended up being a problem with masssive numbers of errors being reported and flooding the unit as it tries to log each one.

    All other 'slowness' was due to the comms between the unit and its various IP based devices.
  • jweatherjweather Junior Member Posts: 320
    Response time wouldn't change significantly unless your program is CPU-limited. If you're trying to talk to too many noisy devices or using too many Duet modules, you might benefit from a faster CPU. If the CPU is less than 100% loaded at all times, though, you're not going to see a big change in response times just from decreasing the cycle times. The network is a much bigger factor in response times.

    Also keep in mind that these processors aren't trying to run a full desktop multimedia operating system... they really just have one thing to do, and they seem to do a pretty good job of it.

    To properly gauge responsiveness on a touchpanel, compare the results of a local page flip (just redraws the page locally) with something that requires a round-trip (true button feedback, or a processor-triggered page flip). I've always found the TPs to be very snappy at redrawing, but there's not much you can do about network round trip times.
  • TurnipTruckTurnipTruck Junior Member Posts: 1,485
    The wireless panels can be finicky with WiFi reception.

    I had one where the WAP sat on top of a table. It fell off the table and was laying against a metal blind panel. Responsiveness of the TP suffered substantially. Putting the WAP back on the table cleared it right up.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    jweather wrote: »
    Response time wouldn't change significantly unless your program is CPU-limited. If you're trying to talk to too many noisy devices or using too many Duet modules, you might benefit from a faster CPU. If the CPU is less than 100% loaded at all times, though, you're not going to see a big change in response times just from decreasing the cycle times. The network is a much bigger factor in response times.

    Also keep in mind that these processors aren't trying to run a full desktop multimedia operating system... they really just have one thing to do, and they seem to do a pretty good job of it.

    To properly gauge responsiveness on a touchpanel, compare the results of a local page flip (just redraws the page locally) with something that requires a round-trip (true button feedback, or a processor-triggered page flip). I've always found the TPs to be very snappy at redrawing, but there's not much you can do about network round trip times.

    The other factor is bigger and faster processors require more power, and generate more heat. There is a point after which the extra benefits no longer outweigh the cost of supporting it. I am reminded of how hot the typical satellite DVR box gets, and I have to wonder if they over-engineered those things. And the last thing I want in my equipment racks is yet another device with an on-board fan ... :) . I half expect the things to create their own weather as it is.
  • Jorde_VJorde_V UX Scientist Posts: 393
    Thanks for all the reactions so far guys.
    Colzie wrote: »
    Is this a wired or wireless panel? I definitely can tell the difference, wireless ones are just a tad laggy...sometimes, not always. Wired ones are very solid.

    Yeah the wireless, never had an issue with wired ones being slow/unresponsive.
    DHawthorne wrote:
    I don't think processor speed is the bottleneck, it's communications speed. The panel sends a message to the processor, the processor spits out IR or RS_232 to the device, the device responds. You have several steps more than, "the remote sends a signal to the device, the device responds." It's even worse when you have to wait for a response, parse it, then display it. And I suspect, in that entire chain, that "the panel sends a message to the processor, and the processor spits out a command," is the most laggy part of the whole operation, considering the amount of overhead going into actually doing all that. Processor speed can improve the whole scenario, but exchanging communications is limited by the nature of the communications themselves, and whatever timing, waits, and cross checks are necessary to be sure they went through properly.

    Add to that, panel messages could be anything. By nature, being prepared for anything and everything is necessarily more complex and time consuming than, being prepared for one specific thing only.

    So you think that things should speed up a lot if we start using higher end networks and IP control? (I certainly hope so myself)
    jweather wrote:
    Response time wouldn't change significantly unless your program is CPU-limited. If you're trying to talk to too many noisy devices or using too many Duet modules, you might benefit from a faster CPU. If the CPU is less than 100% loaded at all times, though, you're not going to see a big change in response times just from decreasing the cycle times. The network is a much bigger factor in response times.

    Also keep in mind that these processors aren't trying to run a full desktop multimedia operating system... they really just have one thing to do, and they seem to do a pretty good job of it.

    To properly gauge responsiveness on a touchpanel, compare the results of a local page flip (just redraws the page locally) with something that requires a round-trip (true button feedback, or a processor-triggered page flip). I've always found the TPs to be very snappy at redrawing, but there's not much you can do about network round trip times.

    I know it runs windriver vxworks and the panels run windriver linux. However sometimes the master needs to do a lot, and you can notice it's under stress and I assume a faster processor means less load and faster processes.
    DHawthorne wrote:
    The other factor is bigger and faster processors require more power, and generate more heat. There is a point after which the extra benefits no longer outweigh the cost of supporting it. I am reminded of how hot the typical satellite DVR box gets, and I have to wonder if they over-engineered those things. And the last thing I want in my equipment racks is yet another device with an on-board fan ... . I half expect the things to create their own weather as it is.

    That's not necessarily true, a faster processor also means less load => lower wattage, I also think more energy efficient processors are launched these days.

    Does anyone know when there will be support for wireless N?
Sign In or Register to comment.