Wrong microtime & load numbers

Does anyone know why the Dreamhost servers are the only ones I have ever seen that do not have accurate microtime functions and the load reading is always wrong?

(this can be easily seen via PHP but also perl, etc)

The effects of this are bizzare - programs that try to time their page generation times get negative results and the load often reads ridiculously high when it’s obviously not or the page would not even be rendering.

Is this because of the AMD multi-core bug that needs a patch to fix the timers? Is it possible the servers are just not patched?

Obviously this is not critical by any means but it is annoying at times when you are trying to get accurate page rendering times.

I can’t speak to the microtime problem. But as a practical thing, does time() have the same problem? If not, you could add the whole second results of time() with the subsecond results of microtime() to get an accurate result.

But on load, the issue is that DreamHost NFS mounts their user directories. This has both pluses and minuses. One side-effect, though, is that load averages can be artificially high relative to CPU load if there are lots of processes waiting for NFS results.

Free unique IP and $67 off with promo code [color=#CC0000]LMIP67[/color] or use [color=#CC0000]LM97[/color] for $97 off. Click for more promo code discounts

Did you search forum for microtime?

There are only a handful of speculative questions and (incorrect/incomplete) answers going back a couple years with no clear solutions. I wanted to bring it up again and see if there were any further insights/workarounds. Maybe even catch the attention of senior dreamhost admin to at least get an explanation as to how it’s happening if not a fix.

Having experienced a somewhat similar problem on my home computer with AMD multi-core, I might have insight in that it’s because the cores are out of sync and instead of using an independent source for the clock, it’s using the core’s own clock. AMD released patches for this for windows (and I believe linux too)

However I’ve been on several shared hosts, also VPS and one dedicated, and no-one else exhibits this issue. It’s somehow unique to Dreamhost.

Thanks for the load insight! That does actually explain the problem I was seeing with php packages that had many includes. By concatinating the files being included, I was able to reduce page rendering time radically. It would seem dreamhost’s file system speed is definitely a weakness. They trade capacity for response time.

Adding whole seconds to microtime does not help. The clock literally seems to go backwards in time by small amount on frequent occasion.

I’m pretty sure this is because the start time is taken from one core, and then the end time sometimes is taken from another core, where the two are out of sync by a few hundred milliseconds.

The question is can this be fixed by an os patch and is dreamhost willing to do the patch.

I don’t know if it would solve your error or not, but you could run the function once and discard the results at the start of your script and then run the rest of your script as you have. The first time it is called, the function has to be loaded, so there is a very tiny delay. After that, it is cached and runs faster.

Read my blog. You know you want to…

Thanks for the idea but I already have it being called a dozen times in a benchmark program (which works on every other host I try).

I’ve even tried using the r_usage trick to look directly at stime and utime but it makes no difference. I’m virtually positive this has to do with multi-cores being out of sync and the OS using the core clocks instead of some universal clock. AMD had to patch it on Windows back when the X2 came out because it was messing up games and other things in browsers that rely on timing.

Suggest contact support. Previous link:

“In this thread, the similar problem was determined to be a kernel parameter issue, that DH support was able to fix.”

Interesting! I missed that thread (and I did search).

When I contacted support recently about this they basically gave me the classic shared hosting brush off I get everywhere

along the lines of (I paraphrase)
“we can’t see the problem, works for us, so it’s not a problem bye”
(this was from level 2 support)

I emailed again with a link to that discussion, many thanks.

With any luck, Sherisa is still around or someone else will know the kernal problem that needs to be fixed.

petrovietnam, thank you so much!

I sent that specific link to support
and then they realised they had to do a kernel update and then reboot.

The microtime numbers seem to be correct now, wonderful!