That's bad, someone has been too lazy to write DX9 engine? How about the 40 % of folks still running XP?
That's a really outstanding job, the result looks pretty good for an automated system.
Sometimes I had the feeling that the camera was changing a bit too hectically, especially at the start of the race. I realize that stuff like this is a pain to get right, but perhaps you could introduce a "race start" mode that would focus more on the entire pack and battles in the front instead of numerous little bumps and fights in the middle of the field?
Sometimes I had the feeling that the camera was changing a bit too hectically, especially at the start of the race. I realize that stuff like this is a pain to get right, but perhaps you could introduce a "race start" mode that would focus more on the entire pack and battles in the front instead of numerous little bumps and fights in the middle of the field?
Sorry, but you couldn't be more wrong about this. LFS is very CPU intensive - all the physics has to be calculated somewhere - but it's OK with any GPU which can do HVS. If you have a strong enough CPU, you can run LFS with no 3D acceleration at all and still get playable FPS.
The way I understand Scawen's posts, the new tyre physics engine uses some ultimately complex set of calculations - if fact so complex that no computer today can run it in real time. He's probably been spending the last couple of months simplifying and optimizing it to make it run on a common modern PC, so optimization is paramount. It's also the most time consuming part, getting from a badly designed algorithm to a reasonably efficient one is quite easy, turning a reasonable algorithm into a really fast one is usually pretty painstaking.
bbman has a point here. Monitoring doesn't necessarily mean protection. Maybe I'm missing something here, but how exactly is CISPA supposed to help disclose hackers who all use Tor - a strongly encrypted network tunnels which make tracing it's users almost impossible - and who by all chances live in countries where US law/gov has no jurisdiction? I'm sorry to put it like this, but the argument flymike used sounded a lot like the kind of propaganda I'd expect to hear from a politician trying to make this act look good in the eyes of the general public... or maybe I should just find the full text of CISPA and educate myself better before making such statements...
I'm not going to honor this flamewar any further, but unless that power benchmark was run at 4 threads only, it's completely meaningless. 8-core CPU will always use more power than a 4-core one under full load. Also the idle power consumption get better when you use an OS with Bulldozer-aware CPU scheduler which lets the whole module "park".
Don't worry, I saw some benchmarks. The price depends on the region, I could definitely save a few bucks by getting a Bulldozer system here(the MoBo's for Bulldozers come cheaper too, at least here). I admit wouldn't be much, but in the end you still need a high-end GPU to be able to tell the difference between i5-2500 and FX-8150 in most games, who cares if a game runs at avg 180 or 120 FPS?
See? That's why I never ask for an advice on the Interwebs, I don't feel like turning my problems into a flamewar fuel.
If you're not already up to speed with the Llano architecture and you don't feel like googling it up, Bulldozer:
- Is a real 8-core CPU
- Has 4 modules with 2 cores per each
- Each module has a shared L2 cache and FPU. The shared FPU becomes a bit of a bottleneck only when both cores want to execute a 256 bit long SIMD instruction at once (today only AVX is like that)
- It scales much better than Intel's HT, with about 80% effectivity of what a full-blown 8-core CPU would do.
- It works best when accompanied by a Bulldozer-aware CPU scheduler. It doesn't really help the performance, but it helps to lower the power consumption a lot. Windows 8 seems to have such a CPU scheduler.
Bottomline: If you're looking to save as much money as possible and you don't build your life around dominating 3DMark leaderboards, Bulldozer it not as bad a choice as some "experts" here would like you to believe. It has quite poor instruction-per-cycle ratio though, so some unoptimized single thread apps won't run as well as they do on SNB's or even older Phenoms.
Older versions of LFS used waveOut whereas current versions use DirectSound, because waveOut didn't work correctly on Vista. DirectSound has to be specifically told to use global sound buffers so you could hear the sound even when application is backgrounded.
The app actively polls HPET in a while loop, so it does hog the CPU quite a bit. Other running tasks might affect the precision a little due to the OS not being able to serve the app in time, but unless you're
running some CPU intensive stuff at high priority during the test, it shouldn't be a problem.Because you can use firewall to IP ban anybody. If there are server admins who think IP bans are any effective, they are free to use their firewalls to accomplish that and stop posting this request over and over...
Or more to the point, when will people learn that this is what firewalls have been invented for.
It's possible that you've run into a problem with G27 detection which wasn't done at all in 1.02, is somewhat wacky in 1.03 and it's supposed to be fixed in 1.04. I'd however need the extra debugging info to investigate it further.
I'm not sure if I'm getting it... What is it that doesn't work? Is it AONIO or the LEDs mod? The mod needs OutGauge to be enabled in LFS, AONIO can enable OutGauge via InSim command, alternatively it can be enabled in cfg.txt. It doesn't matter which port or IP you select for OutGauge, but the OutGauge Mode has to be 1 or 2 in order for the LEDs mod to work.
I suppose it would be possible to make DirectSound think that LFS wants its sound buffers to be treated as global, which is exactly what would do the trick. If there's enough demand for it, it might look into ways how to accomplish this.
I'd rather not do that. If there is a problem with 1.03+, it'd rather get it fixed than provide some older version which has its own problems. As I'm not aware of anything that could interfere with AONIO, are you sure you just haven't somehow misconfigured it?
I should probably note that I'm quite curious myself what kind of results is this going to return on machines where the RTC seems to run incorrectly 
.
Assuming that everything works as I except it would mean that your RTC runs by 16,7 ns faster per one ms. Considering that crystals in common RTCs are set to 32 768 Hz (=> 30,5 us per one tick), it's well within the precision margins you could expect from an RTC clock.
.Assuming that everything works as I except it would mean that your RTC runs by 16,7 ns faster per one ms. Considering that crystals in common RTCs are set to 32 768 Hz (=> 30,5 us per one tick), it's well within the precision margins you could expect from an RTC clock.
That wouldn't quite work because LFS sounds can't be heard if its window looses focus.
It might be interesting to see if the laptop's clock really runs faster than it should. Apart from the obvious check against a stopwatch you could run the attached application.
It reads the system time using timeGetTime() function (which is what LFS uses), waits for a specified amount of time, reads the time again and checks how much time actually elapsed. The wait delay is controlled by HPET which should be much more precise and independent of the RTC. The test is run 10 times and the default delay is 60 seconds (the delay can be changed in the batch file). It'd be interesting to see if you can observe the incorrect speed of the RTC this way.
(MSVS 2010 Redist might be needed to run this)
It reads the system time using timeGetTime() function (which is what LFS uses), waits for a specified amount of time, reads the time again and checks how much time actually elapsed. The wait delay is controlled by HPET which should be much more precise and independent of the RTC. The test is run 10 times and the default delay is 60 seconds (the delay can be changed in the batch file). It'd be interesting to see if you can observe the incorrect speed of the RTC this way.
(MSVS 2010 Redist might be needed to run this)
Last edited by MadCatX, .
Although I'm sure you would have a lot of fun with a Raspberry Pi, AFAIK it doesn't have an ADC so unless the voltage on the leads is 3V3, it won't work. I once played around with an Atmel ATMega16 based board and we used its ADC to read analog inputs and do stuff with it like lighting a LED up or down.
I'm not sure if the board was some handcrafted thing, but a lot of parts came from Olimex.
I'm not sure if the board was some handcrafted thing, but a lot of parts came from Olimex.
1 GB RAM is really the lower limit for W7. If you want to run W7 on this machine, you should either add some RAM or slim W7 down as much as possible. That includes disabling Aero and switching to Classic desktop theme, disabling services you don't need and running as less background apps as possible.
As RAM shouldn't have any effect on framerate, I suspect a video card driver here. It's possible that you'd been using an older version on XP and the new one has different default settings or even a bug that causes the FPS loss in LFS.
As RAM shouldn't have any effect on framerate, I suspect a video card driver here. It's possible that you'd been using an older version on XP and the new one has different default settings or even a bug that causes the FPS loss in LFS.
Ad 1) That is a comparison of Intel's brand new design against at least a year old ARM A9 which has some memory bandwidth issues. Am I correct assuming that a SunSpider and BrowserMark tests don't really benefit from multithreading, so having a faster single core CPU with HT is actually more efficient than a slower quad core?
Ad 3) Power consumption at low load is no the best way to compare the energy efficiency of a CPU. Seeing how would an iPad 3 compare to that 530U3B during Full HD video playback would be more interesting.
Nobody disputes that x86 CPUs will stay on top for a while - at least performance wise - but the pace at which ARM is catching up is quite fast. You also have to consider the compilers which probably still generate more efficient x86 that ARM machine code. (And I'm sure Intel has put some serious work into tweaking stuff to make this reference demo design look as awesome as possible)
An interesting A9 vs. N270 benchmark can be found here: http://www.phoronix.com/scan.p ... ntu_1204_armfeb&num=6
Ad 3) Power consumption at low load is no the best way to compare the energy efficiency of a CPU. Seeing how would an iPad 3 compare to that 530U3B during Full HD video playback would be more interesting.
Nobody disputes that x86 CPUs will stay on top for a while - at least performance wise - but the pace at which ARM is catching up is quite fast. You also have to consider the compilers which probably still generate more efficient x86 that ARM machine code. (And I'm sure Intel has put some serious work into tweaking stuff to make this reference demo design look as awesome as possible)
An interesting A9 vs. N270 benchmark can be found here: http://www.phoronix.com/scan.p ... ntu_1204_armfeb&num=6
Plug the wheel in and type "grep", the last few lines in the log should tell you if and how was the wheel picked up.
EDIT: Whooops, I was quite tired when I wrote this, the correct command is of course "dmesg" (or you could use something like "dmesg | tail -n 10"). Thanks stan.distortion for warning me
EDIT: Whooops, I was quite tired when I wrote this, the correct command is of course "dmesg" (or you could use something like "dmesg | tail -n 10"). Thanks stan.distortion for warning me
Last edited by MadCatX, .
FGED GREDG RDFGDR GSFDG