Hi Michael,
> I’m seeing poor performance using the default PV request type on the receive side:
Could you quantify what "poor performance" means? Are you only looking at dropped updates? Do you have any observations wrt. CPU and/or network load?
Yes, apologies, I think I rushed the e-mail. I'm currently running a script and doing more detailed tests so I'll be able to give a lot more details in a few days.
This is using base 7.0.6.1.
The VM is fairly underpowered and only has 2 cores allocated to it, and several other applications are running on it, although the CPU is relatively idle and less than 20% used. I was generating 0.5MB sized images at 100Hz, so about 50MB/s. Since both IOCs are running on the same VM this is going over the loopback interface.
I see dropped images (a few %) by generating a fixed number of images on the 'source' side and then comparing how many were received on the other side.
I suspect since the VM has other applications running, the IOC is sometimes suspended to allow the other programs to run, and it can't resume quick enough within the necessary 0.02 seconds (which would be the time length of the buffer if the queueSize=2). However, I did check the 'nonvoluntary_ctxt_switches' and that wasn't increasing.
fyi. without "pipeline=true" there is no guarantee that clients won't drop updates. So unrelated changes to system and/or network load may change things.
That makes sense. As well as queueSize=100 I will run the detailed testing for pipeline=true, and I'll report back.
Yes, absolutely. With "pipeline=true", queueSize sets the flow control window size, which is analogous to the TCP window size, though applied to individual subscriptions.
If pipeline=true, and queueSize sets the flow control window size on the server, does the client side buffer size remain at 2 or is it also set to queueSize?
> I saw strange results with the “record[queueSize=100, pipeline=true]field()” where I was sending data at 1Hz but receiving at 100Hz or so.
Do you subscribe to a PV post()ing updates at 1Hz and somehow get 99 extra updates?
That's what it seemed like, but I'd like to do more detailed testing next.
Thanks for the detailed explanation. I'll continue testing and report back, and I'd also like to test on a more powerful machine.
Cheers,
Matt
- Replies:
- RE: [EXTERNAL] Re: PVA monitor request parameters Pearson, Matthew via Tech-talk
- References:
- PVA monitor request parameters Pearson, Matthew via Tech-talk
- Re: PVA monitor request parameters Michael Davidsaver via Tech-talk
- Navigate by Date:
- Prev:
Re: phoebus and subarrays in displays Kasemir, Kay via Tech-talk
- Next:
areaDetector build errors Jong Woo Kim via Tech-talk
- 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: PVA monitor request parameters Michael Davidsaver via Tech-talk
- Next:
RE: [EXTERNAL] Re: PVA monitor request parameters Pearson, Matthew via Tech-talk
- 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
|