Well, first of all, the kernel chooses the best one automatically, it is usually TSC if it's available, because it's kept by the cpu and it's very fast (RDTSC and reading EDX:EAX).
But that wasn't always the case, in the early days when the SMP systems were mostly built with several discrete cpus it was very important that the cpus where as "equal" as it was possible (perfect match of model, speed and stepping), but even then it sometimes occurred that one was sightly faster that the other, so the TSC counter between then was "unstable", that was the reason to allow to change it (or disable it with the "notsc" kernel parameter). And even with this restrictions the TSC is still the best source, but the kernel has to take great care to only rely on one cpu in multicore systems or actively try to keep them synchronized, and also take in account things like suspend/resume (it resets the counter) and cpu frequency scaling (affects TSC in some cpu models).
Some people in those early days of SMP even built systems with cpus of different speeds (kind of the new BIG.little architecture in arm), that created big problems in the timekeeping area.
As for a way to check the resolutions you have clock_getres() and you have an example here.
And a couple of extra links: oficial kernel doc (there are other interesting files in this dir) and TSC resynchronization in chromebooks with some benchmarks of different clocksources.
In short, there shouldn't be any userspace visible changes when changing the clocksource, only a slower gettimeofday().