Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: overheads in serial communications with drvAscii, sioSup & tnetDe v
From: "Redman, Russell O." <Russell.Redman@nrc-cnrc.gc.ca>
To: "Tech-Talk (E-mail)" <tech-talk@aps.anl.gov>
Cc: "'Honey, Allan'" <ahoney@hapuna.keck.hawaii.edu>, "Dunn, Jennifer" <Jennifer.Dunn@nrc-cnrc.gc.ca>, "Wooff, Robert" <Robert.Wooff@nrc-cnrc.gc.ca>
Date: Fri, 4 Jul 2003 15:38:07 -0700
This is probably one for Allan Honey to consider, but may be of wider
interest.

I am experiencing very large overheads using serial communications to talk
to a motor controller.  I am using drvAscii v2.2 with sioSup and tnetDev to
communicate over a serial line to a motor controller.  The hardware layout
is :

   ioc --(Ethernet)-- terminal server --(19200)-- controller

where I am using sioSup and tnetDev to connect to a specified port on a
terminal server, which is configured to talk at 19200 baud to the
controller.  The IOC an MVME2402-3, a PowerPC running VxWorks 5.4 and EPICS
R3.13.5.  

I am passing short messages both ways across this link, 10 characters max
each way.  At 19200 baud, the line should pass about 2000 characters each
second, so the whole prompt/response sequence should be complete in about 10
ms.  In fact, it takes around 300 to 400 ms to complete.  Till now, I have
operated on the assumption that the PPC was so fast that the latency in
serial communications would be dominated by the baud rate, but apparently
not.  After considerable testing, I am convinced that the controller is
replying quite rapidly to each message and is not a significant source of
delay.  I am convinced at the 95% level that the delay is introduced
somewhere in the serial driver/Ethernet connection.

For example, if I set a single record to scan every 0.1 seconds, it is able
to process once every 4 tries:

  -> dbpf "conb:lo:gal:wrtst.TPRO","1"
  DBR_UCHAR:          1         0x1
  value = 0 = 0x0
  -> dbpf "conb:lo:gal:wrtst.SCAN",".1 second"
  DBR_STRING:          .1 second
  value = 0 = 0x0
  -> process:   conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  process:   conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  process:   conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  active:    conb:lo:gal:wrtst
  process:   conb:lo:gal:wrtst
  (etc...)

An interesting variation is to forward link two records 
  conb:lo:gunn:x:rx.FLNK = conb:lo:gunn:x:px 

  -> dbpf "conb:lo:gunn:x:px.TPRO","1"
  DBR_UCHAR:          1         0x1
  value = 0 = 0x0
  -> dbpf "conb:lo:gunn:x:rx.TPRO","1"
  DBR_UCHAR:          1         0x1
  value = 0 = 0x0
  -> dbpf "conb:lo:gunn:x:rx.SCAN","Passive"
  DBR_STRING:          Passive
  value = 0 = 0x0
  -> dbpf "conb:lo:gunn:x:rx.SCAN",".1 second"
  DBR_STRING:          .1 second
  value = 0 = 0x0
  -> process:   conb:lo:gunn:x:rx
  active:    conb:lo:gunn:x:rx
  active:    conb:lo:gunn:x:rx
  process:   conb:lo:gunn:x:px
  process:   conb:lo:gunn:x:rx  - repeat block
  active:    conb:lo:gunn:x:rx    |
  active:    conb:lo:gunn:x:rx    |
  active:    conb:lo:gunn:x:rx    |
  active:    conb:lo:gunn:x:rx    |
  active:    conb:lo:gunn:x:rx    |
  process:   conb:lo:gunn:x:px  - end block
  process:   conb:lo:gunn:x:rx
  (etc...)

In this case, rx is able to queue a message at the start of the block but
must wait for both the previous px message and its own message to complete
before it finishes processing and triggers px again.  The pair of messages
take about 700 ms to complete.

Needless to say, this overhead is unacceptably large.

I have no idea where to begin looking for such large overheads in the
drvAscii/sioSup/tnetDev combination, nor even whether this is the real
source of the problem.  Any ideas what might be wrong?

Dr. Russell O. Redman
Tel: (250) 363-6917 | Fax: (250) 363-0045
<mailto:Russell.Redman@nrc-cnrc.gc.ca>
National Research Council Canada | Conseil national de recherches Canada
5071 West Saanich Road           | 5071 West Saanich Road
Victoria, B. C. V9E 2E7          | Victoria, C.-B. V9E 2E7
Government of Canada             | Gouvernement du Canada

Navigate by Date:
Prev: How to use the errlog with epics 3.14 on a windows Pc? kuner
Next: RE: overheads in serial communications with drvAscii, sioSup & tn etDe v Redman, Russell O.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: How to use the errlog with epics 3.14 on a windows Pc? Jeff Hill
Next: RE: overheads in serial communications with drvAscii, sioSup & tn etDe v Redman, Russell O.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·