This is not an easy question to answer.
When people first started using SCC power management, there was no way for a program to check when the change actually took place. Users would open up another window and issue the SCC BMC status command to read the voltage. This was in human time. There was no way for a program on the cores to read the voltage. There was a hack that let a program read the voltage ... you had to have your core program call a script on the MCPC which would then run the status command and send the results back. The latency was terrible ... seconds.
With sccKit 1.4.x, you can now read an FPGA register that contains the voltage. http://communities.intel.com/docs/DOC-6804 . The latency is ms rather than seconds. Milliseconds is still, of course, a long time, but it is a way of ensuring from within your program that the voltage change actually occurred.
Note that the manpage for RCCE_wait_power(0 says that it "blocks the power domain master UE until the previously specified power level has been reached." What the call did was reissue the power change request; the intent was that it would block until the first request was processed. Later some work showed that this was not sufficient ... that one must issue the request yet again and wait for the third request to return. Look inside RCCE_power_management.c for details.
I don't know what this time is in terms of CPU cycles. Has anyone measured this time?
As for frequency .... The RCCE specification says "Because frequency changes are almost instantaneous, RCCE does not provide a non-blocking version to hide latency."