If you have a master/master chain of replications the seconds_behind_master can fluctuate due to that it calculates this value as the difference between the last record executed by the SQL_THREAD and the first execution time of the last received entry by the IO_THREAD and since you are running master/master in a chain, this entry could have been replicated anywhere from one to seven times which would be noticeable on slow connections.

On top of this you also have the time difference calculation that is only calculated once and then assumed to be constant.

Comment

You have some statements that have a timestamp a long time ago. This could be transactions that stay open a long time before committing, or maybe they deliberately set their timestamp. The most certain way to debug this is to enable log_slave_updates and log_slave_slow_statements (and set long_query_time=0) on the slave, and compare the resulting logs to find out which statements execute with a long-ago timestamp.