Thank you. The problem was indeed contention with other threads, caused by a misconfigured value.
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, November 20, 2024 12:40 PM
To: Iain Marcuson <iain.marcuson at sydortechnologies.com>
Cc: tech-talk at aps.anl.gov
Subject: Re: QuadEM Update rate limited by lock
Hi Iain,
lock() should not take 6 ms, it should be a few microseconds at most. Your lock must be waiting for another thread.
You only need to call lock() for threads that you create, not for functions called from other threads, like writeInt32, etc.
drvTetrAMM.cpp is a good example. readThread() holds the lock except when it is waiting for input from the device (which is most of the time).
I am writing EPICS for a QuadEM, based on designs in the distribution. The data come at 200 Hz, and my benchmarking in EPICS shows that I receive at that rate with very low jitter. Following the examples of other electrometers, I lock()
before computePositions() and callParamCallbacks(). I have observed that the lock() takes about 6 ms, which is too long for the full packet rate. Is this a normal time for the lock()? I believe I have eliminated other calls for the lock() in my code, although
a calltree shows lock()s in the callbacks.
Thank you,
Iain.
This message has been scanned for malware by Forcepoint.
www.forcepoint.com
Click
here to report this email as spam.
|
