Não vejo quais informações úteis devem ser coletadas do que você está tentando fazer, mas você pode alterar a resolução do seu clock em máquinas Windows por meio da API padrão do Win32. Aplicativos diferentes no sistema que exigem tempos de resposta mais altos (como aplicativos multimídia) fazem isso o tempo todo. A resolução do relógio pode estar entre 0,5 e 15,6 e além. Então, faça suas duas máquinas terem as mesmas resoluções de clock.
O Windows 7 é configurado por padrão para permitir que os encadeamentos sejam executados por 2 intervalos de tempo antes que outra decisão de planejamento seja feita. (Ou seja, mudo de contexto ou não?) Por padrão, o Server 2008 R2 está configurado para 12 intervalos de clock entre as decisões de planejamento de thread (também conhecido como thread quantum.) A ideia é que com quanta thread mais longo, o Server OS tem uma chance melhor de iniciar e concluir uma solicitação do cliente sem ser interrompido. (Ou seja, menos alternância de contexto.) Mas você não obteria uma experiência de área de trabalho "rápida" em uma versão de servidor do Windows. (Que em geral ninguém se importa.)
Aqui está um exemplo usando meu PC Win7. O Google Chrome na verdade pediu uma resolução de clock menor do sistema de 1ms. Você pode usar o clockres.exe da Sysinternals para ver a resolução atual e a base do seu clock e o powercfg.exe para ver quais aplicativos estão alterando a resolução do seu relógio.
Meu processador conclui 3.501.000.000 ciclos por segundo (3,5 GHz) e o timer dispara a cada 0,001 segundo. 3501000000 * 0,001 = 3501000 ciclos de CPU por intervalo de clock.
1 Unidade Quântica = 1/3 (um terço) de um intervalo de relógio, portanto, 1 Unidade Quântica = 1167000 ciclos de CPU.
Supondo que a uma taxa de 3,501GHz, cada ciclo de CPU é de 286 picossegundos, que chega a 333,8 microssegundos por unidade quântica. Como meu PC está configurado para quantums de thread de 2 intervalos de clock, e cada intervalo de clock é de 3 unidades quânticas, isso significa que meu PC está fazendo uma decisão de escalonamento de threads a cada 2 milissegundos.
Não vamos nem entrar em quantums de thread de tamanho variável ou no agendador preemptivo (o thread não consegue terminar seu quantum antes de ser antecipado por outro thread de prioridade mais alta.)
Portanto, sua experiência de querer comparar a alternância de contexto em dois sistemas operacionais diferentes executando conjuntos de códigos totalmente diferentes ainda não faz sentido para mim, mas talvez isso ajude, pelo menos no lado do Windows.