substantial lag time difference from boost::thread 1.57 and 1.60
Hello, I am an engineer in a neurosciences lab. We have some data acquisition software that uses boost::thread and some other boost libraries as well. Part of my job is to measure the lag time for our devices' data acquisition. I have been testing the acquisition software when linking against boost v.1.57.0 and v.160.0. Basically I generate a test signal and read it in with an NIDAQ and our EEG system. The signal is a series of 3ms long pulses. When the input to the NIDAQ goes high, I generate a timestamped marker. Meanwhile the EEG system is getting the same pulse train input and I record that digital data on its own thread and timestamp that as well. Then I compare the timestamps at which the EEG signal has a rising edge with the timestamps of the markers. The difference between these time values is the lag of the EEG system. The app I use to get the EEG signal uses boost::thread. The lag time is consistently ~2.7 ms when linking against boost v.1.57.0 and is a whopping 11.6 ms when I link against v.1.60.0. Since the data acquisition happens in a tight loop on its own thread, I am guessing that there is some kind of increased latency of boost threads in newer versions of the library. Does anybody know what might be causing this? I am on Windows 7, 64-bit and am using the pre-compiled boost libraries (i.e. I am not compiling them myself). Cheers, David
On Fri, Jul 8, 2016 at 2:35 PM, David Medine <dmedine@ucsd.edu> wrote:
Hello, I am an engineer in a neurosciences lab. We have some data acquisition software that uses boost::thread and some other boost libraries as well. Part of my job is to measure the lag time for our devices' data acquisition. I have been testing the acquisition software when linking against boost v.1.57.0 and v.160.0.
10 ms is pretty good on a non-r/t OS such as Windows, much less Windows 7 (basically, Vista core). You're sure you're building against release and not debug mode?
Basically I generate a test signal and read it in with an NIDAQ and our EEG system. The signal is a series of 3ms long pulses. When the input to the NIDAQ goes high, I generate a timestamped marker. Meanwhile the EEG system is getting the same pulse train input and I record that digital data on its own thread and timestamp that as well. Then I compare the timestamps at which the EEG signal has a rising edge with the timestamps of the markers. The difference between these time values is the lag of the EEG system.
The app I use to get the EEG signal uses boost::thread. The lag time is consistently ~2.7 ms when linking against boost v.1.57.0 and is a whopping 11.6 ms when I link against v.1.60.0. Since the data acquisition happens in a tight loop on its own thread, I am guessing that there is some kind of increased latency of boost threads in newer versions of the library.
Does anybody know what might be causing this? I am on Windows 7, 64-bit and am using the pre-compiled boost libraries (i.e. I am not compiling them myself).
Cheers, David _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sure, 10 or so ms is fine. I just want to be consistent and correct. I don't want to tell people the lag is one thing when it's another. However, I'm starting to think that it isn't boost::thread, but perhaps some other boost library that is somehow less efficient in more recent releases. It will take some time to track this down. If anyone else has had an experience like this, please chime in! On 7/8/2016 1:42 PM, Michael Powell wrote:
On Fri, Jul 8, 2016 at 2:35 PM, David Medine <dmedine@ucsd.edu> wrote:
Hello, I am an engineer in a neurosciences lab. We have some data acquisition software that uses boost::thread and some other boost libraries as well. Part of my job is to measure the lag time for our devices' data acquisition. I have been testing the acquisition software when linking against boost v.1.57.0 and v.160.0. 10 ms is pretty good on a non-r/t OS such as Windows, much less Windows 7 (basically, Vista core). You're sure you're building against release and not debug mode?
Basically I generate a test signal and read it in with an NIDAQ and our EEG system. The signal is a series of 3ms long pulses. When the input to the NIDAQ goes high, I generate a timestamped marker. Meanwhile the EEG system is getting the same pulse train input and I record that digital data on its own thread and timestamp that as well. Then I compare the timestamps at which the EEG signal has a rising edge with the timestamps of the markers. The difference between these time values is the lag of the EEG system.
The app I use to get the EEG signal uses boost::thread. The lag time is consistently ~2.7 ms when linking against boost v.1.57.0 and is a whopping 11.6 ms when I link against v.1.60.0. Since the data acquisition happens in a tight loop on its own thread, I am guessing that there is some kind of increased latency of boost threads in newer versions of the library.
Does anybody know what might be causing this? I am on Windows 7, 64-bit and am using the pre-compiled boost libraries (i.e. I am not compiling them myself).
Cheers, David _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
David Medine -
Michael Powell