Fw: application slowing down

[Rich Mooney]

Rich:
> > 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.
Dar:
> I know what you are going through.  I just got a call from a
> customer on a similar problem.  Their customer had just upgraded
> their Unison (lighting control) system and now we have errors that
> slow down the polling cycle.  (I wasn't able to convince the Unison
> folks to avoid the need for polling back when they were setting up
> the protocol.)
>
> I think I'm getting the picture.  The entire polling operation is
> done in one handler (and subs).  At the end of that the next one is
> scheduled with a send.
>
> You might want to put a meter on the number of lines in
> pendingMessages() just to be sure this is how it is working.  Or
> log the value.
>
> If this is all in one handler then you must be using "read until
> <string>" or "read for n" depending on your protocol.  Do you use
> "in time"?  You might want to log those timeouts or put a counter
> on them.
>
> You might want to log the time and the long seconds since start of
> poll for each write and read as well as other events such as
> retries.  Log result and syserr, too.
>
> (I use a different style.  I read all available bytes in a single
> read in a handler called in timer send cycle and process those for
> messages.  I might get some delays, but this allows me to do other
> things at the same time.  And it allows me to use the same method
> for processing tcp messages as serial.  With tcp a callback is
> available.)
>
> As you can tell, I've run out of ideas on what might be causing the
> slowing down.  These are just some that might give you a heads up
> as to what is happening.
>
> You said only a slight increase in memory usage, right?
>
> Is this the kind of thing where you need to empty your read buffer
> just before sending out a command just incase there is something in
> there?

I want to thank everyone, especially Dar, for their suggestions on this
problem.  I've finally solved it but, I don't really understand why.  In my
core serial communication handler I have some code which records everything
sent to or read from the serial port to a field.  This was actually the
first thing I looked at when I found out about this problem because I hadn't
set any limit on how much info could be written to this field except that I
made sure it was emptied on startup.  This was obviously a problem for
software that had to run 24/7.  I addressed this issue by having my code
delete the oldest entries if the field grew to more than 200 lines.  If I
turn off this feature so that nothing is written to this field, my software
no longer slows down.  As I mentioned earlier, if I run the software without
being connected to the system the software doesn't slow down even if I am
writing to that field.  Here's a sample of what gets written to the field if
I'm not communicating with the system:

Local: <104600020300
Remote: ?
Remote:
Local: <104700020300
Remote: ?
Remote:
Local: <104800020300
Remote: ?
Remote:
Local: <104900020300
Remote: ?
Remote:
Local: <104A00020300
Remote: ?
Remote:
Local: <104B00020300
Remote: ?

here's a sample of what gets written if I am communicating with the system

Local: <104600020300
Remote: ><1046000110

Remote:
Local: <104700020300
Remote: ><1047000110

Remote:
Local: <104800020300
Remote: ><1048000110

Remote:
Local: <104900020300
Remote: ><1049000110

Remote:
Local: <104A00020300
Remote: ><104A000110

Remote:
Local: <104B00020300
Remote: ><104B000110

Local refers to stuff I'm writing to the port while remote refers to stuff
I'm reading from the port.  It makes no earthly sense to me at all that this
should make a difference.  Anybody have any ideas?

Rich Mooney
Payne Sparkman Mfg.
shop at paynesparkman.com