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:[email protected]>
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
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|