Dar, many thanks for your detailed response. I've addressed your various points below.
> On Tuesday, August 20, 2002, at 11:19 AM, Rich Mooney wrote: > > > I'm desperate and throwing myself on the mercy of this mail list. > > I have an > >> irate customer who wants this problem solved quickly. I have used > > MetaCard > >> to create software which we use to monitor and control our distributed > >> lighting control systems. It does these things very well. I > >> currently > > have > >> a job which requires that I poll the status of all my controls > >> every 30 > >> seconds. I do this so I can catch any changes of state and a close > >> approximation of the time at which that change occurred. I also > >> use this > >> function to catch any errors in operation. The problem is that > >> the time > > it > >> takes to poll all the controls becomes increasingly longer the > >> longer I > > run > >> the software. Initially it will take 33 seconds to poll all of my > > controls > >> if the polling interval is set to 30 seconds. After three hours > >> it will > >> take 43 seconds. By the next day it will take 2 minutes. > Is your network TCP/IP? Besides the processor usage you can > monitor network usage and this may give a clue. A packet sniffer > might also. No. My commands are going out a serial port to a device we make which converts from serial to our protocol which is similar to Appletalk. I do have the capability to send my commands through TCP/IP to a module which converts from TCP/IP to our protocol and I've considered trying this onsite to try to work around the problem. > Is each poll run by a batch of "send in <time>"? If it takes 33 > seconds and a poll is started every 30 seconds, does that mean > there is an overlap? That can cause a few problems. There is just one send in time command keeping the software cycling (I realize that I forgot about this when I responded to Jaqueline). It isn't invoked until after the polling cycle has completed so it polls then waits 30 seconds then polls again etc.. > Second, unless you carry all of your poll state in args of the > handler spec'd in send (or other wise provide for this problem), > you might have one send cycle messing up data from the next. I'm doing this to handle timers on these controls (if a light is manually turned on, I use the send in time command to automatically turn it back off after a user configured amount of time) but, this functionality is currently turned off and I still have the problem. I'm not doing this with the send in time command I'm using to poll every 30 seconds. I'll look into this. > For example, you might query several controls at once. > In the long term, you might want to put polling on leaf nodes only > and distribute these over the system. They can communicate with > concentrators and central control in better ways than polling. This isn't possible with our system. > Polling has killed many large system designs. Hopefully not this time. Thanks for the input. Rich Mooney Payne Sparkman Mfg. [EMAIL PROTECTED] _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
