Unsure what I'm more astonished about, that the correct case is that it would spin 29ms, or that a CPU instruction has changed it expected latency and prder of magnitude upwards.

I would expect any spinning lock to spin at most some slight fraction of the scheduling granularity, but almost always far less than the context switch time except maybe in some specific case of latency sensitive code.

Maybe thr long spin tine is for some reason trying to account for the very long scheduling quantas of windows server?

Superficially it seems misdirected in anything but real-time code since most schedulers would allow the thread to keep its quanta until the next scheduling if the thread wait time was low. The only case I can see this as not being the case is in a system that is overloaded and all CPU's have multiple threads that are all starved.