I suppose.
It would be a little convoluted, though.
I'd have an ASYN record to read the values and an aSub record to perform any necessary endian-swapping, and then the waveform record to hold the result.
Doable, but a fix to StreamDevice would certainly make things simpler. :-)
On Sep 26, 2010, at 4:17 PM, Mark Rivers wrote:
> So do you have a workaround? Use streamDevice for everything except the waveform, and the asyn record for that?
>
> Mark
>
>
> ________________________________
>
> From: Eric Norum [mailto:[email protected]]
> Sent: Sun 9/26/2010 5:41 PM
> To: Mark Rivers; Dirk Zimoch; [email protected] tech-talk
> Subject: Re: StreamDevice slowdown
>
>
>
> Hmm...
> I have an asyn record in my application already.
>
> So, I set up a bug buffer when I instantiate it:
> dbLoadRecords "db/asynRecord.db" "P=tfb:,R=asyn,PORT=L0,ADDR=-1,OMAX=0,IMAX=33554432"
>
> Then at the end of the st.cmd file:
> dbpf tfb:arm Arm
> DBR_STRING: "Arm"
> epicsThreadSleep 1
> dbpf tfb:softTrigger 1
> DBR_STRING: "Trigger"
> epicsThreadSleep 1
> dbpf tfb:asyn.OFMT ASCII
> DBR_STRING: "ASCII"
> dbpf tfb:asyn.IFMT Binary
> DBR_STRING: "Binary"
> dbpf tfb:asyn.AOUT "Waveform?"
> DBR_STRING: "Waveform?"
>
>
>
> And the 'seconds per megasample' are:10.24
> 10.24
> 10.25
> 10.25
> 10.24
> 10.25
> 10.24
> 10.25
> 10.24
> 10.24
> 10.25
> 10.25
> 10.24
> 10.24
> 10.25
> 10.24
>
>
>
>
> So, the smoking gun appears to be in StreamDevice's hand.....
>
> On Sep 26, 2010, at 3:29 PM, Mark Rivers wrote:
>
>> To be sure that the problem is streamDevice rather than something else in EPICS, you could use the asynRecord to do the tests. Put the OFMT=ASCII, IFMT=Binary, and make the IMAX be large enough to hold your waveform when you boot the IOC.
>>
>> Mark
>>
>>
>> ________________________________
>>
>> From: Eric Norum [mailto:[email protected]]
>> Sent: Sun 9/26/2010 5:25 PM
>> To: Mark Rivers
>> Cc: [email protected]; Dirk Zimoch
>> Subject: Re: StreamDevice slowdown
>>
>>
>>
>> To check the raw transfer speed I did:
>> telnet -c 192.168.1.159 73 >/dev/null
>> and typed in the 'Waveform?\n" command.
>>
>> The times per megasample for 16 megasamples in this case:
>> 10.25
>> 10.24
>> 10.24
>> 10.25
>> 10.24
>> 10.25
>> 10.24
>> 10.25
>> 10.24
>> 10.25
>> 10.24
>> 10.25
>> 10.24
>> 10.25
>> 10.24
>> 10.24
>>
>> So I'm pretty sure that the slowdown is in the StreamDevice processing somewhere.
>>
>> By way of comparison, here are the 16 'seconds per megasample' values when using ASYN/StreamDevice rather than telnet:
>> 16.78
>> 48.18
>> 80.91
>> 113.86
>> 147.28
>> 180.20
>> 211.65
>> 244.36
>> 278.61
>> 308.90
>> 342.91
>> 374.54
>> 408.60
>> 439.26
>> 473.29
>> 505.54
>>
>>
>>
>> On Sep 26, 2010, at 2:40 PM, Mark Rivers wrote:
>>
>>> Have you turned on asynTrace in the low-level (TCP?) driver and sent the output to a file so it does not slow things down too much? Can you see then what's on the wire?
>>>
>>> Mark
>>>
>>
>> --
>> Eric Norum
>> [email protected]
>>
>>
>>
>
> --
> Eric Norum
> [email protected]
>
>
>
>
--
Eric Norum
[email protected]
- References:
- StreamDevice slowdown Eric Norum
- RE: StreamDevice slowdown Mark Rivers
- Re: StreamDevice slowdown Eric Norum
- RE: StreamDevice slowdown Mark Rivers
- Re: StreamDevice slowdown Eric Norum
- RE: StreamDevice slowdown Mark Rivers
- Navigate by Date:
- Prev:
RE: StreamDevice slowdown Mark Rivers
- Next:
RE: ImageMagick tom.cobb
- 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: StreamDevice slowdown Mark Rivers
- Next:
Re: StreamDevice slowdown Dirk Zimoch
- 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
|