I have been a computer programmer for a long time so things like this minor incongruity pop out to me.

Rem B/s is documented as the speed at which the Peer is adding to his/her file.  If the Peer is receiving bytes from me, then that should be the minimum value that Rem B/s should show.  However it frequently shows a lower value.  This could be that the completion indicators (block completed per unit time?) used for calculating this counter are slow arriving and it appears that the Peer's file is growing more slowly than what it actually is.

The fix for this is to check Rem B/s and if it is lower than my B/s Out, then elevate it to the B/s Out value.  That's what it must be, at a minimum, since the Peer is getting that many B/s from me.  It would be impossible that their file is growing more slowly than what I am sending to them.  Right?

A simple fix to bring this value closer to reality, I believe.

Thanks for an excellent product.
Mike Morrow

could it be that B/s out includes some overhead bytes that are not included in the Remote B/s to be added to their file?

It is unlikely but possible. Data may become corrupted along the way.

I guess Rem B/s value is calculated from HAVE messages. It depends on information given by the peer and is only estimated value. For example some clients, like qBittorent, are "optimised" so that they won't send HAVE messages to seeders (this breaks Super Seeding too: http://forum.tixati.com/support/1777/  ). If you are seeding, qBittorrent will always show 0 Rem B/s, also their Progress won't advance.