#55 How do we Implement #PublishInterval / PublishRate?

1.0.0.0: EoN
pending
aliazzz
Pub (1)
2020-09-21
2020-09-13
aliazzz
No

Publish interval Definition

PublishInterval / PublishRate is default set to 5000 ms.
So we cannot publish "updates" any faster then each 5s.

This means the publish rate is a kind of "sample-rate" per signal change:

  • 5000 means 1 signal change per interval of 5 seconds is sent,
  • 100 means 1 signal change per interval of 100mec is sent,
  • 10000 means 1 signal change per interval of 10 seconds is sent.

Solution

We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.

Discussion

  • aliazzz

    aliazzz - 2020-09-13
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,10 +1,9 @@
    -PublishInterval / PublishRate is default set to 5000ms.
    +PublishInterval / PublishRate is default set to 5000 ms.
     This means we cannot publish "updates" any faster then each 5000 ms.
    
     How should we implement this?
    
    -1) some form of delay which acts as a NDATA/DDATA buffer?
    -For this to work we have to prevent NDATA/DDATA data to get sent immediately on-change and "buffer" theses changes into the encoding list until the PublishInterval expires. If the interval expired we can encode/send the blob which contains all changes from/during the last interval period.
    +1) For this to work we have to prevent NDATA or DDATA data to get sent immediately on-change and "buffer" all incoming changes into the encoding list until the PublishInterval expires. If the interval expires we can encode the list into a blob which contains all changes from/during the last interval period and send it.
    
     2) Some readily available mechanism via the MQTT Publisher? (haven't looked for it, but cannot remember its there either)
    
     
  • aliazzz

    aliazzz - 2020-09-13
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,13 +1,7 @@
     PublishInterval / PublishRate is default set to 5000 ms.
     This means we cannot publish "updates" any faster then each 5000 ms.
    
    -How should we implement this?
    +After some debate we decided on the following mechanism:
    
    -1) For this to work we have to prevent NDATA or DDATA data to get sent immediately on-change and "buffer" all incoming changes into the encoding list until the PublishInterval expires. If the interval expires we can encode the list into a blob which contains all changes from/during the last interval period and send it.
    -
    -2) Some readily available mechanism via the MQTT Publisher? (haven't looked for it, but cannot remember its there either)
    -
    -3) Some other mechanism?
    -
    -I think 1 is the most likely candidate unless someone has a better/other idea offcourse!
    -
    +We have a timer, it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown, we "buffer" it. 
    +If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.
    
     
  • aliazzz

    aliazzz - 2020-09-14
    • status: open --> accepted
     
  • aliazzz

    aliazzz - 2020-09-14
    • status: accepted --> pending
    • Milestone: MVP: EoN --> 1.0.0.0: basic protobufs
     
  • aliazzz

    aliazzz - 2020-09-15
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,7 +1,10 @@
     PublishInterval / PublishRate is default set to 5000 ms.
    -This means we cannot publish "updates" any faster then each 5000 ms.
    +So we cannot publish "updates" any faster then each 5s.
    
    -After some debate we decided on the following mechanism:
    +This means the publish rate is a kind of sample rate per signal change so 5000 means 1 change per interval of 5 seconds.
    
    -We have a timer, it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown, we "buffer" it. 
    -If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.
    +100 means a signal change per 100mec.
    +10000 means a signal change per 10 seconds.
    +
    +Solution
    +We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.
    
     
  • aliazzz

    aliazzz - 2020-09-15
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,10 +1,11 @@
    +# Publish interval Definition
     PublishInterval / PublishRate is default set to 5000 ms.
     So we cannot publish "updates" any faster then each 5s.
    
    -This means the publish rate is a kind of sample rate per signal change so 5000 means 1 change per interval of 5 seconds.
    +This means the publish rate is a kind of "sample-rate" per signal change:
    +* 5000 means 1 signal change per interval of 5 seconds is sent,
    +* 100 means 1 signal change per interval of 100mec is sent,
    +* 10000 means 1 signal change per interval of 10 seconds is sent.
    
    -100 means a signal change per 100mec.
    -10000 means a signal change per 10 seconds.
    -
    -Solution
    +# Solution
     We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.
    
     
  • aliazzz

    aliazzz - 2020-09-15
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -3,6 +3,7 @@
     So we cannot publish "updates" any faster then each 5s.
    
     This means the publish rate is a kind of "sample-rate" per signal change:
    +
     * 5000 means 1 signal change per interval of 5 seconds is sent,
     * 100 means 1 signal change per interval of 100mec is sent,
     * 10000 means 1 signal change per interval of 10 seconds is sent.
    
     
  • i-campbell

    i-campbell - 2020-09-15
    • Milestone: 1.0.0.0: basic protobufs --> 1.0.0.0: EoN
     
  • aliazzz

    aliazzz - 2020-09-21

    This ticket will be pushed into the trunk within the next day

     

Log in to post a comment.