Understanding Galera Status wsrep_local_recv_queue_avg Does wsrep_local_recv_queue_avg really represent the average size of the wsrep_local_recv_queue?

For the MariaDB version below I have problems to understand the status value of it, because the wsrep_local_recv_queue is 0 all the time, but wsrep_local_recv_queue_avg is sometimes very high (above 500), even though the node has been restarted 600 seconds ago and 580 of those 600 seconds the queue size is 0 and only 10-15 seconds after starting the mysql node the receive queue can be as high as 10000, but is being saved away fastly.

The wsrep_local_recv_queue_avg value is even also only decreasing in fractions when checking the value regularly.

So please enlighten me, what this value actually represents if not the average receive queue size for the node's uptime.

~ $ dpkg -l | grep mariadb
ii  libmariadbclient18                5.5.45+maria-1~wheezy         amd64        MariaDB database client library
ii  mariadb-client-5.5                5.5.45+maria-1~wheezy         amd64        MariaDB database client binaries
ii  mariadb-client-core-5.5           5.5.45+maria-1~wheezy         amd64        MariaDB database core client binaries
ii  mariadb-common                    5.5.45+maria-1~wheezy         all          MariaDB database common files (e.g. /etc/mysql/conf.d/mariadb.cnf)
ii  mariadb-galera-server             5.5.45+maria-1~wheezy         all          MariaDB database server with Galera cluster (metapackage depending on the latest version)
ii  mariadb-galera-server-5.5         5.5.45+maria-1~wheezy         amd64        MariaDB database server with Galera cluster binaries
According to the MariaDB KB: Galera Cluster Status Variables:


  Description: Average length of the receive queue since the most recent
  status query. If this value is noticeably larger than zero, the node
  is likely to be overloaded, and cannot apply the writesets as quickly
  as they arrive, resulting in replication throttling.


So it not the average receive queue size for the node's uptime, but since the last time you queried this status.