this can't be right...

[VolumetricSteve]

I've sorted out some of my segmentation fault issues, it was a voltage setting problem. Turns out for my system, you actually need lightning to go directly into each core to power it correctly. Now that that's solved...I got this...I don't even...q3map2, or linux, is crazy.

With the CPU at stock clocks, and ram at stock clocks (1333), I compile:

bsp 34 seconds
vis 121 seconds

With CPU at stock, and ram clocked to 1600, I compile:

bsp 29 seconds
vis 125 seconds

what? (those numbers are averages, I ran each test three times)

[obsidian]

I'm not sure what you're asking or what's wrong with your compile times. If you're wondering why the faster RAM speeds equates to same compile times, it's because Q3Map2 can't really take advantage of faster RAM as it is CPU dependant.

[VolumetricSteve]

I just don't get why having faster ram speeds made one process go slower and another go faster. I'm testing all the different settings I can, and I came across this again where something that should be faster isn't.

[mrd]

You're probably splitting hairs and looking for efficiencies where none exist. I would just be happy that your map compiles in less than three minutes and get on with the map making :P

[VolumetricSteve]

A valid point, but my curiosity is just an academic one. You have to admit...it doesn't make a ton of sense.

[^misantropia^]

It's probably just noise in the benchmark but overclocking can actually slow down your system. I speculate it's the memory refresh cycle that's doing you in.

[spookmineer]

It's probably just noise in the benchmark but overclocking can actually slow down your system. I speculate it's the memory refresh cycle that's doing you in.

Bit tech posted an article on optimal DDR2 clocks in the AM2 era (something technical, in some cases, faster clocks didn't mean faster real life results because of the multiplier).

Anyway it doesn't explain this:

It does seem odd that the bsp compiles faster, while the vis compiles slower.

It's a clear case of a haunted PC. Most ghosts don't mind you knowing the way, they just don't like you seeing it. They try to block all vis, then realise they're invisible anyway, but that causes the longer vis time.
Best get rid of it, sell it on ebay to a teen for the price you bought it. 1 spray can costs a few bucks and goes a long way for the visuals.

Or: I don't wtf is going on, it doesn't make sense.
My money is on the latter.

[VolumetricSteve]

It gets worse, just did some more tests:

with the ram at stock clocks and the cpu OC'd from 3.3 to 3.8, it ruined my light compile time.

it took light 30311 seconds to complete @ 3.8GHz, the exact same light compile took 24070 seconds to complete @ 3.3GHz

On the hand hand, it's stable now, in another thread i'd posted about segmentation faults I was getting - I seem to have totally fixed those, the stupid thing is at least stable now. On the other hand....this is crazy. What misantropia said about memory refresh cycles makes sense, I can get my head around that....I can't get my head around six processor cores going from 3.3GHz to 3.8GHz and performing slower at /some/ things, oh yeah, vis compiled 20 seconds faster at 3.8GHz.

...I'm switchin' motherboards, I'm out of ideas.

[Hipshot]

I don't get it. If it's faster w/o the o/c, why o/c?

[VolumetricSteve]

I don't get it. If it's faster w/o the o/c, why o/c?

You're right, if I can't get it to go any faster, there's no point. I'm only going on about it because I'm baffled by my findings. I did just switch motherboards and it's acting a little bit better under OC settings, but I'm starting to wonder if my cpu has some sort of defect. I mean...if this is what overclocking does to command line linux, then I'll just leave it at stock speeds, but it's hard to find a frame reference for what's normal because I've never heard of an OC making some things slower and some things marginally faster. At the same time, people don't generally go around OCing systems to run in CLI mode.