Announcement

Collapse
No announcement yet.

Very slow INSTEON perfomance with plugin.

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Very slow INSTEON perfomance with plugin.

    Hi,

    I have very slow INSTEON performance with plug-in.. If I send two INSTEON commands to two different devices then second command delayed on 1-5 seconds. I found that plug-in processes commands one by one waiting for the result of execution of each command. Moreover, if the device does not respond, the plug can wait up to 5 seconds and delay execution of remaining commands.Why do not you make asynchronous execution of commands by sending requests one by one and processing the results separately?

    Best Regards,
    Dmitry

    #2
    It's the nature of Insteon itself. The line can only carry one message at a time. The bandwidth is barely enough for that. The plug-in can't do anything to work around this limitation.

    Comment


      #3
      Originally posted by JeffryD View Post
      It's the nature of Insteon itself. The line can only carry one message at a time. The bandwidth is barely enough for that. The plug-in can't do anything to work around this limitation.
      You are wrong. Insteon protocol don't have this limitation. Where are you find this information? Only one message can be TRANSMITTED at the time. But between request and response it can support many OTHER requests and responses from OTHER devices. But your plug-in does not send any other requests while waiting response from specific device...and it is wrong. Line is free at this moment and other devices can communicate at this time but not plug-in. INSTEON protocol can support from 36 to 160 standard messages per second but your plugin limit it to maximum 4 (2 requests + 2 responses) messages per second. Because pure plug-in message speed is 5 messages per second (100ms delay on transmit after each message + 100ms delay on receive after each message) + minimum 300 ms delay for device response. Your plug-in can work in 9-32 times faster!!!!
      More that, I found that your programmer don't understand multithreaded programming at all. He use Queue for pass messages to another threads but it is NOT THREAD SAFE. Only TransmitMsgThread try to use thread safe Queue BUT it STILL NOT THREAD SAFE because all other threads use THIS Queue WITHOUT lock!!! You MUST use thread safe Queue in EVERY thread! It work ONLY because you use BIG delays (100ms) on every step. It is very bad idea. You should use AutoResetEvent to Thread Synchronization and LOCK EVERY action with Queue.
      If you want I can help you to improve your plug-in for free...because I plan to use it

      Best Regards,
      Dmitry
      Last edited by ddv; August 5, 2010, 11:15 PM.

      Comment


        #4
        Dmitry,

        would you care to share some sample code of the thread safe code and queueing mechanism you mentioned
        Mark

        HS3 Pro 4.2.19.5
        Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
        Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
        Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

        Comment


          #5
          Originally posted by mnsandler View Post
          would you care to share some sample code of the thread safe code and queueing mechanism you mentioned
          ok.
          1. All Queue's (gTransmitMsgQueue, gReceivedInsteonRaw, gReceivedInsteonText) that you use must be SynchronizedQueue. Because only SynchronizedQueue use lock for Dequeue/Enqueue. You use SynchronizedQueue only in TransmitMsgThread() but all other methods (TransmitGroupCommand, TransmitDeviceCommand and etc) use same queue (gTransmitMsgQueue) without lock.

          2. Use AutoResetEvent instead of Thread.Sleep(100). For each queue declare AutoResetEvent like "AutoResetEvent gTransmitMsgQueueEvent = new AutoResetEvent(false)". Add gTransmitMsgQueueEvent.Set() after each Enqueue for this queue. Add same for each queue in ShutdownPlugin method just after "gShutdown = true" to unlock threads. Replace Thread.Sleep(100) to gTransmitMsgQueueEvent.WaitOne(100) in TransmitMsgThread(). In other methods use proper event name for each queue.

          3. ResourceManager is absolutly not thread safe (several threads can simultaneously enter to any method and simultaneously check that it is FREE on same resource). Just use array of ReaderWriterLock in ResourceManager. It exactly what you want to implement (AcquireReaderLock for locks and AcquireWriterLock for exclusive locks).

          To increase performance you have to change transmit logic. Now you transmit the data and wait result in same method in same thread. It should be divided. One thread should only transmit messages and ANOTHER thread should wait and process results for each transmission. It look like transactions...One thread start transaction and another thread process it result or retransmit it if no results received. Only need to provide when the same device has several transactions that do not start new until old will be done.


          Best Regards,
          Dmitry
          Last edited by ddv; August 11, 2010, 01:05 PM.

          Comment


            #6
            thanks i will take a look at these queues, etc.

            out of curiousity, what tool did you use to reverse engineer/decompile the dll to see the level of detail you are quoting above?
            Mark

            HS3 Pro 4.2.19.5
            Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
            Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
            Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

            Comment


              #7
              Originally posted by mnsandler View Post
              out of curiousity, what tool did you use to reverse engineer/decompile the dll to see the level of detail you are quoting above?
              I use Reflector.NET

              Comment

              Working...
              X