TCP::rtt is not affected by processing time. It is the "pure rtt" determined at the TCP layer to the peer. The value will be different between the client side and the serverside. If we were to include processing time, it would lead to vastly unfair and non-deterministic results, not to mention a bit of a layering violation.
Even though our measurement granularity for a round-trip is generally 1ms (as given by the timestamps we use to obtain fine-grained round-trip resolutions and re-ordering detection), we use a smoothed-round-trip moving average that requires us to return these values in multiples. For those who are interested, floating-point math should generally be avoided in the kernel, so we simply scale up by a factor of 32 to obtain the resolution we need when calculating these values, so we don't lose too much to round-off errors.
So yes, if TCP::rtt gives you "32" this means that we've detected the round trip time between us and the endpoint in question to be 1ms. And if you get 2400, the rtt being estimated is indeed 75ms.
Does this help?