I extended the track the full 240 tiles across the map. 9 are ramp. The rollers are off. At the end I built the following construction:
<<<
v ^
>>^===
The track turns north, loops counter-clockwise and exits back along the track without connecting, with walls keeping the cart on the track.
Pass 1: The cart exits the ramp and travels 108 tiles in 100 ticks, crosses the map, jumps the track and takes the loop clockwise, and travels 7 tiles back up the ramp before starting pass 2
Pass 2: The cart exits the ramp and travels 91 tiles in 100 ticks, jumps the track and again takes the loop clockwise, and travels 5 tiles back up the ramp.
Pass 3: The cart exits the ramp and travels 79 tiles in 100 ticks, jumps the track and again takes the loop clockwise, and travels 3 tiles back up the ramp.
Pass 4: The cart exits the ramp and travels 63 tiles in 100 ticks, jumps the track and again takes the loop clockwise, and travels 1 tile back up the ramp.
Pass 5: The cart exits the ramp and travels 47 tiles in 100 ticks does NOT jump the track and properly takes the loop counter-clockwise, and travels 0 tiles back up the ramp (but still bounces back).
Pass 6: The cart exits the ramp and travels 26 tiles in 100 ticks and travels a total of 303 tiles, including the loop properly before coming to a stop.
The track is 214 tiles long from the bottom of the ramp to the turn into the loop. The loop is 4 turns and 4 straight tracks. End-to-end, excluding ramp, it is 436 tiles.
From initial push, the cart travels 2524 tiles in total, including the runs up and back down the ramp. 24 of those tiles are turns, 2500 are straight track. Speed losses per run:
Run 1: 17 tiles/100 ticks
Run 2: 12 tiles/100 ticks
Run 3: 16 tiles/100 ticks
Run 4: 16 tiles/100 ticks
Run 5: 21 tiles/100 ticks
Run 6: >21 tiles/100 ticks as the cart fails to return to the bottom of the ramp.
It's possible Run 2 was mismeasured. I'll repeat the experiment later, but the tile the cart ends on has been the same for each run - I did this about 20x before I got everything right, and got runs where I didn't get a pause/recenter in the middle of the effort. It's very reliable WRT distance. I got the same distance when the rollers were activated, so I believe the 9z ramp gets the cart to maximum velocity (a shorter ramp may as well, not tested here).
I chose 100 ticks because it's a reasonable period of time to get a measurement with a minimum amount of rounding error. It's also the duration for a pressure plate to signal a drawbridge, so it's a useful measure in that way. For example, if you're going for maximum velocity and want to trigger a bridge to lower, you'll need somewhere in the neighborhood of 110 tiles between the pressure plate and the drawbridge to keep the cart from slamming into the bridge.
Some theories:
1) Toady intended the max cart speed to be 1 tile per tick, but there's a bug causing the cart to exceed this value. I've done some programming along these lines, and dealing with cases where objects travel farther than your sample rate is a lot harder than when objects are limited to your sample rate. I suspect this will be changed, and cart max speed lowered in a future update because of 2) below.
2) Because carts can travel more than 1 tile per tick, we get 'tunneling'. I've had the cart fly through a solid wall several times, and strike another solid wall. I believe what's happening is that each tick the game determines any 'leading' interactions (like a dwarf steps in front of the cart) resolves those, takes the speed of the cart, reduces it through friction, calculates where the next position of the cart should be looks ahead to that position, and determines if there's a wall or other 'trailing' interaction that should prevent the cart from going to that position. If there isn't, it advances the cart. If there is, it deals with that accordingly. In the case where the cart is going more than one tile per tick, it's possible that the current position is one tile short of a wall and the next position is one tile past the wall and the game never sees the wall, because it doesn't bother to check if those positions are >1 tile apart and check the intermediate positions because it assumes a 1 tile per tick max speed. Whether the cart tunnels is purely a rounding error. Move the wall one tile closer or farther and it won't tunnel. I'm going to test this with floodgates on levers.
3) The internal calculations for speed and position are more accurate than the display. If it wasn't, the speed/distance would be quickly clamped to integers. It's not. If my measurements above are correct, there is a rounding error still that is apparent. You'd expect the distance/time falloff to be more predictable - linear, geometric, etc. but it doesn't seem to be exactly either. And we're not off by one tile here or there, but several. I'm using a script that pushes the one-step button exactly 100 times, so I've taken counting out of the equation in this. I'll redo this and see if anything changes, in the event that I mismeasured, etc.