Hey,
I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz: loadComponent("Reporter","OCL::FileReporting") setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
When I do reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file. However, when I do reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
Deployer [S]> Reporter.stop = false Deployer [S]> Reporter.stop 166.835 [ ERROR ][DeploymentComponent::connectPorts] Failed to stop thread Activity: step() function did not return after Failed to stop thread Activity: step() function did not return after 0.05 seconds. = false
I am using the orocos-ros-toolchain and did an upgrade today.
Bert
Strange behaviour Reporter
On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
> Hey,
>
> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
> loadComponent("Reporter","OCL::FileReporting")
> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
OK.
>
> When I do
> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
This samples a property or attributes, no buffering takes place here.
> However, when I do
> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
This gets you all the data of the port, using a small buffer (10
samples) to get all data. The reporter then empties this buffer 100
times a second, and gives all data in the buffer the same timestamp.
Only in 'snapshot' mode, no buffering is done, but then some
thread/script is responsible for calling the snapshot operation and
the reporter must get an activity with no period, such that the
snapshot operation can trigger the component for making a log.
I think this architecture is overly complex and confusing.
* The nominal behavior (no snapshotting) should not use a buffer and
just sample the ports 'at the frequency of the reporter'.
* If the user wants to install a buffer to get all the data on a given
port, a new function should be added which receives a connection
policy object which sets these parameters for that port (no hard coded
buffer sizes etc)
* Finally snapshot shouldn't be a property since this is confusing.
The reporter should provide snapshotting as a service/operation in one
shot (zero period activity) mode and do classical 'sampling' in
periodic mode.
>
>
>
> I am using the orocos-ros-toolchain and did an upgrade today.
This is caused by the overruns your periodic reporting thread is
suffering from. If we fix the above issues, this will be resolved as
well, although not being able to stop a thread which goes in overrun
is not a nice 'feature' which needs a resolution eventually.
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Strange behaviour Reporter
2011/7/25 Peter Soetens <peter [..] ...>:
> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>> Hey,
>>
>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>> loadComponent("Reporter","OCL::FileReporting")
>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>
> OK.
>
>>
>> When I do
>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>
> This samples a property or attributes, no buffering takes place here.
>
>> However, when I do
>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>
> This gets you all the data of the port, using a small buffer (10
> samples) to get all data. The reporter then empties this buffer 100
> times a second, and gives all data in the buffer the same timestamp.
> Only in 'snapshot' mode, no buffering is done, but then some
> thread/script is responsible for calling the snapshot operation and
> the reporter must get an activity with no period, such that the
> snapshot operation can trigger the component for making a log.
>
> I think this architecture is overly complex and confusing.
> * The nominal behavior (no snapshotting) should not use a buffer and
> just sample the ports 'at the frequency of the reporter'.
+1
> * If the user wants to install a buffer to get all the data on a given
> port, a new function should be added which receives a connection
> policy object which sets these parameters for that port (no hard coded
> buffer sizes etc)
I think using a buffer is not useful in any case. I'll try to explain.
The reporter connects to all 'to be reported' ports using addEventPort().
So, depending on the activity of the Reporter:
* give the Reporter a non-periodic acitivity: data is logged as soon
as it is written on the port - this logs all data, _unless_ and that's
what happens in e.g. Bert's case, the reporter can't keep up with the
frequency the data is generated. Probably because writing to the file
is time consuming? In that case currently, a small buffer is used: but
this is useless, as the reporter can't keep up, why try to buffer a
(limited) number of samples, to discard others anyway? IMO, better is
to just run as fast as possible, and always write the _last_ value.
* give the Reporter a periodic activity: (this already is actually bad
design because we now have an event-triggered component running
periodically). If I recall correctly, new data on the port will
trigger the reporter, but it will only process that trigger in the
next updateHook(). If you use a buffer in this case, it will only
serve if new data arrives within the time slot needed to write the
previous data to the file. This data in any case will all have
(nearly) the same timestamp, so again, the buffer is not useful.
Steven
> * Finally snapshot shouldn't be a property since this is confusing.
> The reporter should provide snapshotting as a service/operation in one
> shot (zero period activity) mode and do classical 'sampling' in
> periodic mode.
>
>>
>>
>>
>> I am using the orocos-ros-toolchain and did an upgrade today.
>
> This is caused by the overruns your periodic reporting thread is
> suffering from. If we fix the above issues, this will be resolved as
> well, although not being able to stop a thread which goes in overrun
> is not a nice 'feature' which needs a resolution eventually.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Strange behaviour Reporter
On Fri, 29 Jul 2011, Steven Bellens wrote:
> 2011/7/25 Peter Soetens <peter [..] ...>:
>> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>>> Hey,
>>>
>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>> loadComponent("Reporter","OCL::FileReporting")
>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>
>> OK.
>>
>>>
>>> When I do
>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>
>> This samples a property or attributes, no buffering takes place here.
>>
>>> However, when I do
>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>
>> This gets you all the data of the port, using a small buffer (10
>> samples) to get all data. The reporter then empties this buffer 100
>> times a second, and gives all data in the buffer the same timestamp.
>> Only in 'snapshot' mode, no buffering is done, but then some
>> thread/script is responsible for calling the snapshot operation and
>> the reporter must get an activity with no period, such that the
>> snapshot operation can trigger the component for making a log.
>>
>> I think this architecture is overly complex and confusing.
>> * The nominal behavior (no snapshotting) should not use a buffer and
>> just sample the ports 'at the frequency of the reporter'.
>
> +1
>
>> * If the user wants to install a buffer to get all the data on a given
>> port, a new function should be added which receives a connection
>> policy object which sets these parameters for that port (no hard coded
>> buffer sizes etc)
>
> I think using a buffer is not useful in any case. I'll try to explain.
> The reporter connects to all 'to be reported' ports using addEventPort().
> So, depending on the activity of the Reporter:
>
> * give the Reporter a non-periodic acitivity: data is logged as soon
> as it is written on the port - this logs all data, _unless_ and that's
> what happens in e.g. Bert's case, the reporter can't keep up with the
> frequency the data is generated. Probably because writing to the file
> is time consuming? In that case currently, a small buffer is used: but
> this is useless, as the reporter can't keep up, why try to buffer a
> (limited) number of samples, to discard others anyway? IMO, better is
> to just run as fast as possible, and always write the _last_ value.
>
> * give the Reporter a periodic activity: (this already is actually bad
> design because we now have an event-triggered component running
> periodically). If I recall correctly, new data on the port will
> trigger the reporter, but it will only process that trigger in the
> next updateHook(). If you use a buffer in this case, it will only
> serve if new data arrives within the time slot needed to write the
> previous data to the file. This data in any case will all have
> (nearly) the same timestamp, so again, the buffer is not useful.
Buffering _is_ useful (and even _needed_ when you want to have all data),
but a component will have to be dedicated to that. This is "best practice"
architecture, where that component is always ready to get the latest data,
and put them in a _local_ buffer (many times larger than the size of one
data sample, of course), and having a second local buffer ready for when
the first one is full; it writes the filled buffer in non-realtime to
persistent storage.
It's this kind of 'standard architectures' that are necessary for control,
and that the new "Orocos Control Box" projects wants to offer in the near
future.
> Steven
Herman
Strange behaviour Reporter
2011/7/29 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Fri, 29 Jul 2011, Steven Bellens wrote:
>
>> 2011/7/25 Peter Soetens <peter [..] ...>:
>>> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>>>> Hey,
>>>>
>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>> loadComponent("Reporter","OCL::FileReporting")
>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>
>>> OK.
>>>
>>>>
>>>> When I do
>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>
>>> This samples a property or attributes, no buffering takes place here.
>>>
>>>> However, when I do
>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>
>>> This gets you all the data of the port, using a small buffer (10
>>> samples) to get all data. The reporter then empties this buffer 100
>>> times a second, and gives all data in the buffer the same timestamp.
>>> Only in 'snapshot' mode, no buffering is done, but then some
>>> thread/script is responsible for calling the snapshot operation and
>>> the reporter must get an activity with no period, such that the
>>> snapshot operation can trigger the component for making a log.
>>>
>>> I think this architecture is overly complex and confusing.
>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>> just sample the ports 'at the frequency of the reporter'.
>>
>> +1
>>
>>> * If the user wants to install a buffer to get all the data on a given
>>> port, a new function should be added which receives a connection
>>> policy object which sets these parameters for that port (no hard coded
>>> buffer sizes etc)
>>
>> I think using a buffer is not useful in any case. I'll try to explain.
>> The reporter connects to all 'to be reported' ports using addEventPort().
>> So, depending on the activity of the Reporter:
>>
>> * give the Reporter a non-periodic acitivity: data is logged as soon
>> as it is written on the port - this logs all data, _unless_ and that's
>> what happens in e.g. Bert's case, the reporter can't keep up with the
>> frequency the data is generated. Probably because writing to the file
>> is time consuming? In that case currently, a small buffer is used: but
>> this is useless, as the reporter can't keep up, why try to buffer a
>> (limited) number of samples, to discard others anyway? IMO, better is
>> to just run as fast as possible, and always write the _last_ value.
>>
>> * give the Reporter a periodic activity: (this already is actually bad
>> design because we now have an event-triggered component running
>> periodically). If I recall correctly, new data on the port will
>> trigger the reporter, but it will only process that trigger in the
>> next updateHook(). If you use a buffer in this case, it will only
>> serve if new data arrives within the time slot needed to write the
>> previous data to the file. This data in any case will all have
>> (nearly) the same timestamp, so again, the buffer is not useful.
>
> Buffering _is_ useful (and even _needed_ when you want to have all data),
> but a component will have to be dedicated to that. This is "best practice"
> architecture, where that component is always ready to get the latest data,
> and put them in a _local_ buffer (many times larger than the size of one
> data sample, of course), and having a second local buffer ready for when
> the first one is full; it writes the filled buffer in non-realtime to
> persistent storage.
It will still give you problems when the first buffer fills quicker
then you can write out the second one... no?
Steven
>
> It's this kind of 'standard architectures' that are necessary for control,
> and that the new "Orocos Control Box" projects wants to offer in the near
> future.
>
>> Steven
>
> Herman
Strange behaviour Reporter
On Fri, 29 Jul 2011, Steven Bellens wrote:
> 2011/7/29 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>
>>> 2011/7/25 Peter Soetens <peter [..] ...>:
>>>> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>>>>> Hey,
>>>>>
>>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>>> loadComponent("Reporter","OCL::FileReporting")
>>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>>
>>>> OK.
>>>>
>>>>>
>>>>> When I do
>>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>>
>>>> This samples a property or attributes, no buffering takes place here.
>>>>
>>>>> However, when I do
>>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>>
>>>> This gets you all the data of the port, using a small buffer (10
>>>> samples) to get all data. The reporter then empties this buffer 100
>>>> times a second, and gives all data in the buffer the same timestamp.
>>>> Only in 'snapshot' mode, no buffering is done, but then some
>>>> thread/script is responsible for calling the snapshot operation and
>>>> the reporter must get an activity with no period, such that the
>>>> snapshot operation can trigger the component for making a log.
>>>>
>>>> I think this architecture is overly complex and confusing.
>>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>>> just sample the ports 'at the frequency of the reporter'.
>>>
>>> +1
>>>
>>>> * If the user wants to install a buffer to get all the data on a given
>>>> port, a new function should be added which receives a connection
>>>> policy object which sets these parameters for that port (no hard coded
>>>> buffer sizes etc)
>>>
>>> I think using a buffer is not useful in any case. I'll try to explain.
>>> The reporter connects to all 'to be reported' ports using addEventPort().
>>> So, depending on the activity of the Reporter:
>>>
>>> * give the Reporter a non-periodic acitivity: data is logged as soon
>>> as it is written on the port - this logs all data, _unless_ and that's
>>> what happens in e.g. Bert's case, the reporter can't keep up with the
>>> frequency the data is generated. Probably because writing to the file
>>> is time consuming? In that case currently, a small buffer is used: but
>>> this is useless, as the reporter can't keep up, why try to buffer a
>>> (limited) number of samples, to discard others anyway? IMO, better is
>>> to just run as fast as possible, and always write the _last_ value.
>>>
>>> * give the Reporter a periodic activity: (this already is actually bad
>>> design because we now have an event-triggered component running
>>> periodically). If I recall correctly, new data on the port will
>>> trigger the reporter, but it will only process that trigger in the
>>> next updateHook(). If you use a buffer in this case, it will only
>>> serve if new data arrives within the time slot needed to write the
>>> previous data to the file. This data in any case will all have
>>> (nearly) the same timestamp, so again, the buffer is not useful.
>>
>> Buffering _is_ useful (and even _needed_ when you want to have all data),
>> but a component will have to be dedicated to that. This is "best practice"
>> architecture, where that component is always ready to get the latest data,
>> and put them in a _local_ buffer (many times larger than the size of one
>> data sample, of course), and having a second local buffer ready for when
>> the first one is full; it writes the filled buffer in non-realtime to
>> persistent storage.
>
> It will still give you problems when the first buffer fills quicker
> then you can write out the second one... no?
Obviously. That means that your hardware has to be chosen in order to
provide the raw performance that your application requires :-)
But there is _always_ a _major_ difference in having to write each sample
to persistent storage compared to being able to write blocks of 100k
samples or so. Hard disks are not called "block devices" for nothing :-)
See
<http://en.wikipedia.org/wiki/Block_device#Block_devices>
compared to "character devices", which is the typical usage mode of
control hardware.
Herman
Strange behaviour Reporter
2011/7/29 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Fri, 29 Jul 2011, Steven Bellens wrote:
>
>> 2011/7/29 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>
>>>> 2011/7/25 Peter Soetens <peter [..] ...>:
>>>>> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>>>>>> Hey,
>>>>>>
>>>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>>>> loadComponent("Reporter","OCL::FileReporting")
>>>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>>>
>>>>> OK.
>>>>>
>>>>>>
>>>>>> When I do
>>>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>>>
>>>>> This samples a property or attributes, no buffering takes place here.
>>>>>
>>>>>> However, when I do
>>>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>>>
>>>>> This gets you all the data of the port, using a small buffer (10
>>>>> samples) to get all data. The reporter then empties this buffer 100
>>>>> times a second, and gives all data in the buffer the same timestamp.
>>>>> Only in 'snapshot' mode, no buffering is done, but then some
>>>>> thread/script is responsible for calling the snapshot operation and
>>>>> the reporter must get an activity with no period, such that the
>>>>> snapshot operation can trigger the component for making a log.
>>>>>
>>>>> I think this architecture is overly complex and confusing.
>>>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>>>> just sample the ports 'at the frequency of the reporter'.
>>>>
>>>> +1
>>>>
>>>>> * If the user wants to install a buffer to get all the data on a given
>>>>> port, a new function should be added which receives a connection
>>>>> policy object which sets these parameters for that port (no hard coded
>>>>> buffer sizes etc)
>>>>
>>>> I think using a buffer is not useful in any case. I'll try to explain.
>>>> The reporter connects to all 'to be reported' ports using addEventPort().
>>>> So, depending on the activity of the Reporter:
>>>>
>>>> * give the Reporter a non-periodic acitivity: data is logged as soon
>>>> as it is written on the port - this logs all data, _unless_ and that's
>>>> what happens in e.g. Bert's case, the reporter can't keep up with the
>>>> frequency the data is generated. Probably because writing to the file
>>>> is time consuming? In that case currently, a small buffer is used: but
>>>> this is useless, as the reporter can't keep up, why try to buffer a
>>>> (limited) number of samples, to discard others anyway? IMO, better is
>>>> to just run as fast as possible, and always write the _last_ value.
>>>>
>>>> * give the Reporter a periodic activity: (this already is actually bad
>>>> design because we now have an event-triggered component running
>>>> periodically). If I recall correctly, new data on the port will
>>>> trigger the reporter, but it will only process that trigger in the
>>>> next updateHook(). If you use a buffer in this case, it will only
>>>> serve if new data arrives within the time slot needed to write the
>>>> previous data to the file. This data in any case will all have
>>>> (nearly) the same timestamp, so again, the buffer is not useful.
>>>
>>> Buffering _is_ useful (and even _needed_ when you want to have all data),
>>> but a component will have to be dedicated to that. This is "best practice"
>>> architecture, where that component is always ready to get the latest data,
>>> and put them in a _local_ buffer (many times larger than the size of one
>>> data sample, of course), and having a second local buffer ready for when
>>> the first one is full; it writes the filled buffer in non-realtime to
>>> persistent storage.
>>
>> It will still give you problems when the first buffer fills quicker
>> then you can write out the second one... no?
>
> Obviously. That means that your hardware has to be chosen in order to
> provide the raw performance that your application requires :-)
>
> But there is _always_ a _major_ difference in having to write each sample
> to persistent storage compared to being able to write blocks of 100k
> samples or so. Hard disks are not called "block devices" for nothing :-)
> See
> <http://en.wikipedia.org/wiki/Block_device#Block_devices>
> compared to "character devices", which is the typical usage mode of
> control hardware.
Agree, but, given the current Reporter implementation, which writes
one sample at the time, a buffer is useless. It _would_ be useful, if
the implementation changes so as to write blocks of data. Still, this
would only add value in the case the data generator runs at a rate
faster the 'write one sample at the time' reporter can follow, but
slower then the 'write blocks' reporter (cfr your hardware) can at
most handle.
Steven
>
> Herman
Strange behaviour Reporter
2011/7/29 Steven Bellens <steven [dot] bellens [..] ...>:
> 2011/7/29 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>
>>> 2011/7/29 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>>
>>>>> 2011/7/25 Peter Soetens <peter [..] ...>:
>>>>>> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>>>>> loadComponent("Reporter","OCL::FileReporting")
>>>>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>>>
>>>>>>> When I do
>>>>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>>>>
>>>>>> This samples a property or attributes, no buffering takes place here.
>>>>>>
>>>>>>> However, when I do
>>>>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>>>>
>>>>>> This gets you all the data of the port, using a small buffer (10
>>>>>> samples) to get all data. The reporter then empties this buffer 100
>>>>>> times a second, and gives all data in the buffer the same timestamp.
>>>>>> Only in 'snapshot' mode, no buffering is done, but then some
>>>>>> thread/script is responsible for calling the snapshot operation and
>>>>>> the reporter must get an activity with no period, such that the
>>>>>> snapshot operation can trigger the component for making a log.
>>>>>>
>>>>>> I think this architecture is overly complex and confusing.
>>>>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>>>>> just sample the ports 'at the frequency of the reporter'.
>>>>>
>>>>> +1
>>>>>
>>>>>> * If the user wants to install a buffer to get all the data on a given
>>>>>> port, a new function should be added which receives a connection
>>>>>> policy object which sets these parameters for that port (no hard coded
>>>>>> buffer sizes etc)
>>>>>
>>>>> I think using a buffer is not useful in any case. I'll try to explain.
>>>>> The reporter connects to all 'to be reported' ports using addEventPort().
>>>>> So, depending on the activity of the Reporter:
>>>>>
>>>>> * give the Reporter a non-periodic acitivity: data is logged as soon
>>>>> as it is written on the port - this logs all data, _unless_ and that's
>>>>> what happens in e.g. Bert's case, the reporter can't keep up with the
>>>>> frequency the data is generated. Probably because writing to the file
>>>>> is time consuming? In that case currently, a small buffer is used: but
>>>>> this is useless, as the reporter can't keep up, why try to buffer a
>>>>> (limited) number of samples, to discard others anyway? IMO, better is
>>>>> to just run as fast as possible, and always write the _last_ value.
>>>>>
>>>>> * give the Reporter a periodic activity: (this already is actually bad
>>>>> design because we now have an event-triggered component running
>>>>> periodically). If I recall correctly, new data on the port will
>>>>> trigger the reporter, but it will only process that trigger in the
>>>>> next updateHook(). If you use a buffer in this case, it will only
>>>>> serve if new data arrives within the time slot needed to write the
>>>>> previous data to the file. This data in any case will all have
>>>>> (nearly) the same timestamp, so again, the buffer is not useful.
>>>>
>>>> Buffering _is_ useful (and even _needed_ when you want to have all data),
>>>> but a component will have to be dedicated to that. This is "best practice"
>>>> architecture, where that component is always ready to get the latest data,
>>>> and put them in a _local_ buffer (many times larger than the size of one
>>>> data sample, of course), and having a second local buffer ready for when
>>>> the first one is full; it writes the filled buffer in non-realtime to
>>>> persistent storage.
>>>
>>> It will still give you problems when the first buffer fills quicker
>>> then you can write out the second one... no?
>>
>> Obviously. That means that your hardware has to be chosen in order to
>> provide the raw performance that your application requires :-)
>>
>> But there is _always_ a _major_ difference in having to write each sample
>> to persistent storage compared to being able to write blocks of 100k
>> samples or so. Hard disks are not called "block devices" for nothing :-)
>> See
>> <http://en.wikipedia.org/wiki/Block_device#Block_devices>
>> compared to "character devices", which is the typical usage mode of
>> control hardware.
>
> Agree, but, given the current Reporter implementation, which writes
> one sample at the time, a buffer is useless. It _would_ be useful, if
> the implementation changes so as to write blocks of data. Still, this
> would only add value in the case the data generator runs at a rate
> faster the 'write one sample at the time' reporter can follow, but
> slower then the 'write blocks' reporter (cfr your hardware) can at
> most handle.
I should at that there does exist one use case where buffering, in the
current implementation, is useful: an non-periodic data generator
which generates a limited amount of data, but sometimes the data is
generated at nearly the same time.
Steven
>
> Steven
>
>>
>> Herman
>
Strange behaviour Reporter
On 07/29/2011 01:37 PM, Steven Bellens wrote:
> 2011/7/29 Steven Bellens<steven [dot] bellens [..] ...>:
>> 2011/7/29 Herman Bruyninckx<Herman [dot] Bruyninckx [..] ...>:
>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>
>>>> 2011/7/29 Herman Bruyninckx<Herman [dot] Bruyninckx [..] ...>:
>>>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>>>
>>>>>> 2011/7/25 Peter Soetens<peter [..] ...>:
>>>>>>> On Mon, Jul 25, 2011 at 5:06 PM,<bert [dot] willaert [..] ...> wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>>>>>> loadComponent("Reporter","OCL::FileReporting")
>>>>>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>>>>> OK.
>>>>>>>
>>>>>>>> When I do
>>>>>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>>>>> This samples a property or attributes, no buffering takes place here.
>>>>>>>
>>>>>>>> However, when I do
>>>>>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>>>>> This gets you all the data of the port, using a small buffer (10
>>>>>>> samples) to get all data. The reporter then empties this buffer 100
>>>>>>> times a second, and gives all data in the buffer the same timestamp.
>>>>>>> Only in 'snapshot' mode, no buffering is done, but then some
>>>>>>> thread/script is responsible for calling the snapshot operation and
>>>>>>> the reporter must get an activity with no period, such that the
>>>>>>> snapshot operation can trigger the component for making a log.
>>>>>>>
>>>>>>> I think this architecture is overly complex and confusing.
>>>>>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>>>>>> just sample the ports 'at the frequency of the reporter'.
>>>>>> +1
>>>>>>
>>>>>>> * If the user wants to install a buffer to get all the data on a given
>>>>>>> port, a new function should be added which receives a connection
>>>>>>> policy object which sets these parameters for that port (no hard coded
>>>>>>> buffer sizes etc)
>>>>>> I think using a buffer is not useful in any case. I'll try to explain.
>>>>>> The reporter connects to all 'to be reported' ports using addEventPort().
>>>>>> So, depending on the activity of the Reporter:
>>>>>>
>>>>>> * give the Reporter a non-periodic acitivity: data is logged as soon
>>>>>> as it is written on the port - this logs all data, _unless_ and that's
>>>>>> what happens in e.g. Bert's case, the reporter can't keep up with the
>>>>>> frequency the data is generated. Probably because writing to the file
>>>>>> is time consuming? In that case currently, a small buffer is used: but
>>>>>> this is useless, as the reporter can't keep up, why try to buffer a
>>>>>> (limited) number of samples, to discard others anyway? IMO, better is
>>>>>> to just run as fast as possible, and always write the _last_ value.
>>>>>>
>>>>>> * give the Reporter a periodic activity: (this already is actually bad
>>>>>> design because we now have an event-triggered component running
>>>>>> periodically). If I recall correctly, new data on the port will
>>>>>> trigger the reporter, but it will only process that trigger in the
>>>>>> next updateHook(). If you use a buffer in this case, it will only
>>>>>> serve if new data arrives within the time slot needed to write the
>>>>>> previous data to the file. This data in any case will all have
>>>>>> (nearly) the same timestamp, so again, the buffer is not useful.
>>>>> Buffering _is_ useful (and even _needed_ when you want to have all data),
>>>>> but a component will have to be dedicated to that. This is "best practice"
>>>>> architecture, where that component is always ready to get the latest data,
>>>>> and put them in a _local_ buffer (many times larger than the size of one
>>>>> data sample, of course), and having a second local buffer ready for when
>>>>> the first one is full; it writes the filled buffer in non-realtime to
>>>>> persistent storage.
>>>> It will still give you problems when the first buffer fills quicker
>>>> then you can write out the second one... no?
>>> Obviously. That means that your hardware has to be chosen in order to
>>> provide the raw performance that your application requires :-)
>>>
>>> But there is _always_ a _major_ difference in having to write each sample
>>> to persistent storage compared to being able to write blocks of 100k
>>> samples or so. Hard disks are not called "block devices" for nothing :-)
>>> See
>>> <http://en.wikipedia.org/wiki/Block_device#Block_devices>
>>> compared to "character devices", which is the typical usage mode of
>>> control hardware.
>> Agree, but, given the current Reporter implementation, which writes
>> one sample at the time, a buffer is useless. It _would_ be useful, if
>> the implementation changes so as to write blocks of data. Still, this
>> would only add value in the case the data generator runs at a rate
>> faster the 'write one sample at the time' reporter can follow, but
>> slower then the 'write blocks' reporter (cfr your hardware) can at
>> most handle.
> I should at that there does exist one use case where buffering, in the
> current implementation, is useful: an non-periodic data generator
> which generates a limited amount of data, but sometimes the data is
> generated at nearly the same time.
FYI, the rock data logger uses buffer connections to not miss samples as
it runs in a lower priority than the control loops and sensor tasks. It
also uses an internal buffer to account for I/O issues.
Sylvain
Strange behaviour Reporter
On Fri, Jul 29, 2011 at 1:39 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 07/29/2011 01:37 PM, Steven Bellens wrote:
>> 2011/7/29 Steven Bellens<steven [dot] bellens [..] ...>:
>>> 2011/7/29 Herman Bruyninckx<Herman [dot] Bruyninckx [..] ...>:
>>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>>
>>>>> 2011/7/29 Herman Bruyninckx<Herman [dot] Bruyninckx [..] ...>:
>>>>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>>>>
>>>>>>> 2011/7/25 Peter Soetens<peter [..] ...>:
>>>>>>>> On Mon, Jul 25, 2011 at 5:06 PM,<bert [dot] willaert [..] ...> wrote:
>>>>>>>>> Hey,
>>>>>>>>>
>>>>>>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>>>>>>> loadComponent("Reporter","OCL::FileReporting")
>>>>>>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>>>>>> OK.
>>>>>>>>
>>>>>>>>> When I do
>>>>>>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>>>>>> This samples a property or attributes, no buffering takes place here.
>>>>>>>>
>>>>>>>>> However, when I do
>>>>>>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>>>>>> This gets you all the data of the port, using a small buffer (10
>>>>>>>> samples) to get all data. The reporter then empties this buffer 100
>>>>>>>> times a second, and gives all data in the buffer the same timestamp.
>>>>>>>> Only in 'snapshot' mode, no buffering is done, but then some
>>>>>>>> thread/script is responsible for calling the snapshot operation and
>>>>>>>> the reporter must get an activity with no period, such that the
>>>>>>>> snapshot operation can trigger the component for making a log.
>>>>>>>>
>>>>>>>> I think this architecture is overly complex and confusing.
>>>>>>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>>>>>>> just sample the ports 'at the frequency of the reporter'.
>>>>>>> +1
>>>>>>>
>>>>>>>> * If the user wants to install a buffer to get all the data on a given
>>>>>>>> port, a new function should be added which receives a connection
>>>>>>>> policy object which sets these parameters for that port (no hard coded
>>>>>>>> buffer sizes etc)
>>>>>>> I think using a buffer is not useful in any case. I'll try to explain.
>>>>>>> The reporter connects to all 'to be reported' ports using addEventPort().
>>>>>>> So, depending on the activity of the Reporter:
>>>>>>>
>>>>>>> * give the Reporter a non-periodic acitivity: data is logged as soon
>>>>>>> as it is written on the port - this logs all data, _unless_ and that's
>>>>>>> what happens in e.g. Bert's case, the reporter can't keep up with the
>>>>>>> frequency the data is generated. Probably because writing to the file
>>>>>>> is time consuming? In that case currently, a small buffer is used: but
>>>>>>> this is useless, as the reporter can't keep up, why try to buffer a
>>>>>>> (limited) number of samples, to discard others anyway? IMO, better is
>>>>>>> to just run as fast as possible, and always write the _last_ value.
>>>>>>>
>>>>>>> * give the Reporter a periodic activity: (this already is actually bad
>>>>>>> design because we now have an event-triggered component running
>>>>>>> periodically). If I recall correctly, new data on the port will
>>>>>>> trigger the reporter, but it will only process that trigger in the
>>>>>>> next updateHook(). If you use a buffer in this case, it will only
>>>>>>> serve if new data arrives within the time slot needed to write the
>>>>>>> previous data to the file. This data in any case will all have
>>>>>>> (nearly) the same timestamp, so again, the buffer is not useful.
>>>>>> Buffering _is_ useful (and even _needed_ when you want to have all data),
>>>>>> but a component will have to be dedicated to that. This is "best practice"
>>>>>> architecture, where that component is always ready to get the latest data,
>>>>>> and put them in a _local_ buffer (many times larger than the size of one
>>>>>> data sample, of course), and having a second local buffer ready for when
>>>>>> the first one is full; it writes the filled buffer in non-realtime to
>>>>>> persistent storage.
>>>>> It will still give you problems when the first buffer fills quicker
>>>>> then you can write out the second one... no?
>>>> Obviously. That means that your hardware has to be chosen in order to
>>>> provide the raw performance that your application requires :-)
>>>>
>>>> But there is _always_ a _major_ difference in having to write each sample
>>>> to persistent storage compared to being able to write blocks of 100k
>>>> samples or so. Hard disks are not called "block devices" for nothing :-)
>>>> See
>>>> <http://en.wikipedia.org/wiki/Block_device#Block_devices>
>>>> compared to "character devices", which is the typical usage mode of
>>>> control hardware.
>>> Agree, but, given the current Reporter implementation, which writes
>>> one sample at the time, a buffer is useless. It _would_ be useful, if
>>> the implementation changes so as to write blocks of data. Still, this
>>> would only add value in the case the data generator runs at a rate
>>> faster the 'write one sample at the time' reporter can follow, but
>>> slower then the 'write blocks' reporter (cfr your hardware) can at
>>> most handle.
>> I should at that there does exist one use case where buffering, in the
>> current implementation, is useful: an non-periodic data generator
>> which generates a limited amount of data, but sometimes the data is
>> generated at nearly the same time.
> FYI, the rock data logger uses buffer connections to not miss samples as
> it runs in a lower priority than the control loops and sensor tasks. It
> also uses an internal buffer to account for I/O issues.
How do you distinguish between 'need all samples' versus 'sample
samples at X Hz' ?
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Strange behaviour Reporter
On Fri, 29 Jul 2011, Sylvain Joyeux wrote:
> On 07/29/2011 01:37 PM, Steven Bellens wrote:
>> 2011/7/29 Steven Bellens<steven [dot] bellens [..] ...>:
>>> 2011/7/29 Herman Bruyninckx<Herman [dot] Bruyninckx [..] ...>:
>>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>>
>>>>> 2011/7/29 Herman Bruyninckx<Herman [dot] Bruyninckx [..] ...>:
>>>>>> On Fri, 29 Jul 2011, Steven Bellens wrote:
>>>>>>
>>>>>>> 2011/7/25 Peter Soetens<peter [..] ...>:
>>>>>>>> On Mon, Jul 25, 2011 at 5:06 PM,<bert [dot] willaert [..] ...> wrote:
>>>>>>>>> Hey,
>>>>>>>>>
>>>>>>>>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>>>>>>>>> loadComponent("Reporter","OCL::FileReporting")
>>>>>>>>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>>>>>>>> OK.
>>>>>>>>
>>>>>>>>> When I do
>>>>>>>>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>>>>>>>> This samples a property or attributes, no buffering takes place here.
>>>>>>>>
>>>>>>>>> However, when I do
>>>>>>>>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>>>>>>>> This gets you all the data of the port, using a small buffer (10
>>>>>>>> samples) to get all data. The reporter then empties this buffer 100
>>>>>>>> times a second, and gives all data in the buffer the same timestamp.
>>>>>>>> Only in 'snapshot' mode, no buffering is done, but then some
>>>>>>>> thread/script is responsible for calling the snapshot operation and
>>>>>>>> the reporter must get an activity with no period, such that the
>>>>>>>> snapshot operation can trigger the component for making a log.
>>>>>>>>
>>>>>>>> I think this architecture is overly complex and confusing.
>>>>>>>> * The nominal behavior (no snapshotting) should not use a buffer and
>>>>>>>> just sample the ports 'at the frequency of the reporter'.
>>>>>>> +1
>>>>>>>
>>>>>>>> * If the user wants to install a buffer to get all the data on a given
>>>>>>>> port, a new function should be added which receives a connection
>>>>>>>> policy object which sets these parameters for that port (no hard coded
>>>>>>>> buffer sizes etc)
>>>>>>> I think using a buffer is not useful in any case. I'll try to explain.
>>>>>>> The reporter connects to all 'to be reported' ports using addEventPort().
>>>>>>> So, depending on the activity of the Reporter:
>>>>>>>
>>>>>>> * give the Reporter a non-periodic acitivity: data is logged as soon
>>>>>>> as it is written on the port - this logs all data, _unless_ and that's
>>>>>>> what happens in e.g. Bert's case, the reporter can't keep up with the
>>>>>>> frequency the data is generated. Probably because writing to the file
>>>>>>> is time consuming? In that case currently, a small buffer is used: but
>>>>>>> this is useless, as the reporter can't keep up, why try to buffer a
>>>>>>> (limited) number of samples, to discard others anyway? IMO, better is
>>>>>>> to just run as fast as possible, and always write the _last_ value.
>>>>>>>
>>>>>>> * give the Reporter a periodic activity: (this already is actually bad
>>>>>>> design because we now have an event-triggered component running
>>>>>>> periodically). If I recall correctly, new data on the port will
>>>>>>> trigger the reporter, but it will only process that trigger in the
>>>>>>> next updateHook(). If you use a buffer in this case, it will only
>>>>>>> serve if new data arrives within the time slot needed to write the
>>>>>>> previous data to the file. This data in any case will all have
>>>>>>> (nearly) the same timestamp, so again, the buffer is not useful.
>>>>>> Buffering _is_ useful (and even _needed_ when you want to have all data),
>>>>>> but a component will have to be dedicated to that. This is "best practice"
>>>>>> architecture, where that component is always ready to get the latest data,
>>>>>> and put them in a _local_ buffer (many times larger than the size of one
>>>>>> data sample, of course), and having a second local buffer ready for when
>>>>>> the first one is full; it writes the filled buffer in non-realtime to
>>>>>> persistent storage.
>>>>> It will still give you problems when the first buffer fills quicker
>>>>> then you can write out the second one... no?
>>>> Obviously. That means that your hardware has to be chosen in order to
>>>> provide the raw performance that your application requires :-)
>>>>
>>>> But there is _always_ a _major_ difference in having to write each sample
>>>> to persistent storage compared to being able to write blocks of 100k
>>>> samples or so. Hard disks are not called "block devices" for nothing :-)
>>>> See
>>>> <http://en.wikipedia.org/wiki/Block_device#Block_devices>
>>>> compared to "character devices", which is the typical usage mode of
>>>> control hardware.
>>> Agree, but, given the current Reporter implementation, which writes
>>> one sample at the time, a buffer is useless. It _would_ be useful, if
>>> the implementation changes so as to write blocks of data. Still, this
>>> would only add value in the case the data generator runs at a rate
>>> faster the 'write one sample at the time' reporter can follow, but
>>> slower then the 'write blocks' reporter (cfr your hardware) can at
>>> most handle.
>> I should at that there does exist one use case where buffering, in the
>> current implementation, is useful: an non-periodic data generator
>> which generates a limited amount of data, but sometimes the data is
>> generated at nearly the same time.
> FYI, the rock data logger uses buffer connections to not miss samples as
> it runs in a lower priority than the control loops and sensor tasks. It
> also uses an internal buffer to account for I/O issues.
That's the kind of "best practice architecture" that someone should capture
in an Orocos "OCL" template! (I hope to achieve this with the "Orocos
Control Box" project... Don't hold your breath :-))
> Sylvain
Herman
Strange behaviour Reporter
On 07/29/2011 01:42 PM, Herman Bruyninckx wrote:
>> it runs in a lower priority than the control loops and sensor tasks. It
>> also uses an internal buffer to account for I/O issues.
> FYI, the rock data logger uses buffer connections to not miss samples as
>
> That's the kind of "best practice architecture" that someone should
> capture
> in an Orocos "OCL" template! (I hope to achieve this with the "Orocos
> Control Box" project... Don't hold your breath :-))
Not really, as it is not (I believe) a pattern, but a single use-case
(logging). There is no need for 200 different logging component
implementations. This two-buffer pattern is only used, in rock, for the
logger.
The choice of buffer/data and of buffer size is done automatically by
the system deployment layer based on requirements from the components
and from information on the component deployment (priorities,
realtime/non-realtime scheduling class, triggering periods ...).
Sylvain
Strange behaviour Reporter
On Fri, 29 Jul 2011, Sylvain Joyeux wrote:
> On 07/29/2011 01:42 PM, Herman Bruyninckx wrote:
>>> it runs in a lower priority than the control loops and sensor tasks. It
>>> also uses an internal buffer to account for I/O issues.
>> FYI, the rock data logger uses buffer connections to not miss samples as
>>
>> That's the kind of "best practice architecture" that someone should
>> capture
>> in an Orocos "OCL" template! (I hope to achieve this with the "Orocos
>> Control Box" project... Don't hold your breath :-))
> Not really, as it is not (I believe) a pattern, but a single use-case
> (logging).
I mean: your suggested solution is _the_ pattern for things like logging. :-)
> There is no need for 200 different logging component
> implementations. This two-buffer pattern is only used, in rock, for the
> logger.
>
> The choice of buffer/data and of buffer size is done automatically by
> the system deployment layer based on requirements from the components
> and from information on the component deployment (priorities,
> realtime/non-realtime scheduling class, triggering periods ...).
>
> Sylvain
Herman
Re: Strange behaviour Reporter
> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz: > loadComponent("Reporter","OCL::FileReporting") > setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
OK.
> > When I do > reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
This samples a property or attributes, no buffering takes place here.
> However, when I do > reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
This gets you all the data of the port, using a small buffer (10 samples) to get all data. The reporter then empties this buffer 100 times a second, and gives all data in the buffer the same timestamp.
Hmm, that doesn't correspond to what I see: 1) My reports.dat file contains +-3500 samples per second (and not 10*100) 2) The timestamps are not the same for each group of 10 samples. The dt between each two samples is around 0.00028...
Only in 'snapshot' mode, no buffering is done, but then some thread/script is responsible for calling the snapshot operation and the reporter must get an activity with no period, such that the snapshot operation can trigger the component for making a log.
I think this architecture is overly complex and confusing.
just sample the ports 'at the frequency of the reporter'.
port, a new function should be added which receives a connection policy object which sets these parameters for that port (no hard coded buffer sizes etc)
The reporter should provide snapshotting as a service/operation in one shot (zero period activity) mode and do classical 'sampling' in periodic mode.
> >> I am using the orocos-ros-toolchain and did an upgrade today.
This is caused by the overruns your periodic reporting thread is suffering from. If we fix the above issues, this will be resolved as well, although not being able to stop a thread which goes in overrun is not a nice 'feature' which needs a resolution eventually.
Peter -- Orocos-Users mailing list Orocos-Users [..] ... http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Strange behaviour Reporter
On Tue, Jul 26, 2011 at 9:37 AM, <bert [dot] willaert [..] ...> wrote:
> On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...> wrote:
>> Hey,
>>
>> I am seeing strange behaviour of the Reporter component. I have all components running at 5khz and I set the Reporter to run at 100 Hz:
>> loadComponent("Reporter","OCL::FileReporting")
>> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>
> OK.
>
>>
>> When I do
>> reportData("component_name","data_name") and then start and stop the Reporter, everything goes fine: I get data_name sampled at 100 Hz in the reports.dat file.
>
> This samples a property or attributes, no buffering takes place here.
>
>> However, when I do
>> reportPort("component_name","port_name") I can start the Reporter but I cannot stop it: it returns 'false' and keeps adding data to the reports.dat file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>
> This gets you all the data of the port, using a small buffer (10
> samples) to get all data. The reporter then empties this buffer 100
> times a second, and gives all data in the buffer the same timestamp.
> -------------------------------------------------------------------------
> Hmm, that doesn't correspond to what I see:
> 1) My reports.dat file contains +-3500 samples per second (and not 10*100)
The buffer overflows and drops samples.
> 2) The timestamps are not the same for each group of 10 samples. The dt between each two samples is around 0.00028...
That's the time required to log one line to the file, then a next
timestamp is taken. So 'all data the same timestamp' is indeed not
correct, what I meant is 'nearly the same timestamp'.
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Strange behaviour Reporter
2011/7/26 Peter Soetens <peter [..] ...>
> On Tue, Jul 26, 2011 at 9:37 AM, <bert [dot] willaert [..] ...> wrote:
> > On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...>
> wrote:
> >> Hey,
> >>
> >> I am seeing strange behaviour of the Reporter component. I have all
> components running at 5khz and I set the Reporter to run at 100 Hz:
> >> loadComponent("Reporter","OCL::FileReporting")
> >> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
> >
> > OK.
> >
> >>
> >> When I do
> >> reportData("component_name","data_name") and then start and stop the
> Reporter, everything goes fine: I get data_name sampled at 100 Hz in the
> reports.dat file.
> >
> > This samples a property or attributes, no buffering takes place here.
> >
> >> However, when I do
> >> reportPort("component_name","port_name") I can start the Reporter but I
> cannot stop it: it returns 'false' and keeps adding data to the reports.dat
> file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
> >
> > This gets you all the data of the port, using a small buffer (10
> > samples) to get all data. The reporter then empties this buffer 100
> > times a second, and gives all data in the buffer the same timestamp.
> > -------------------------------------------------------------------------
> > Hmm, that doesn't correspond to what I see:
> > 1) My reports.dat file contains +-3500 samples per second (and not
> 10*100)
>
> The buffer overflows and drops samples.
>
But here he seems to have more than 1000 samples, not less
>
> > 2) The timestamps are not the same for each group of 10 samples. The dt
> between each two samples is around 0.00028...
>
> That's the time required to log one line to the file, then a next
> timestamp is taken. So 'all data the same timestamp' is indeed not
> correct, what I meant is 'nearly the same timestamp'.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Strange behaviour Reporter
On Tue, Jul 26, 2011 at 10:39 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>
>
> 2011/7/26 Peter Soetens <peter [..] ...>
>>
>> On Tue, Jul 26, 2011 at 9:37 AM, <bert [dot] willaert [..] ...> wrote:
>> > On Mon, Jul 25, 2011 at 5:06 PM, <bert [dot] willaert [..] ...>
>> > wrote:
>> >> Hey,
>> >>
>> >> I am seeing strange behaviour of the Reporter component. I have all
>> >> components running at 5khz and I set the Reporter to run at 100 Hz:
>> >> loadComponent("Reporter","OCL::FileReporting")
>> >> setActivity("Reporter",0.01,LowestPriority,ORO_SCHED_RT)
>> >
>> > OK.
>> >
>> >>
>> >> When I do
>> >> reportData("component_name","data_name") and then start and stop the
>> >> Reporter, everything goes fine: I get data_name sampled at 100 Hz in the
>> >> reports.dat file.
>> >
>> > This samples a property or attributes, no buffering takes place here.
>> >
>> >> However, when I do
>> >> reportPort("component_name","port_name") I can start the Reporter but I
>> >> cannot stop it: it returns 'false' and keeps adding data to the reports.dat
>> >> file. Moreover, the data is not sampled at 100Hz but at +- 3500Hz??
>> >
>> > This gets you all the data of the port, using a small buffer (10
>> > samples) to get all data. The reporter then empties this buffer 100
>> > times a second, and gives all data in the buffer the same timestamp.
>> >
>> > -------------------------------------------------------------------------
>> > Hmm, that doesn't correspond to what I see:
>> > 1) My reports.dat file contains +-3500 samples per second (and not
>> > 10*100)
>>
>> The buffer overflows and drops samples.
>
> But here he seems to have more than 1000 samples, not less
I'm assuming the producer runs faster than the reporter, ie at > 3500Hz.
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users