Hi,
Maybe you could try not moving the mouse during VMWare?! How can you even test this in a VM?!? It doesn't make ANY SENSE. There are a MILLION things going on in the background of your VM whenever you test this.
*THREE* of your 5 tests all gave nearly the SAME answer, and the two different value are ALSO the same, simply meaning that some event happened 2/5th of the time which slowed down the VM (like an interrupt).
Your output shows that the code is working PERFECTLY.
The code is not complex at all, it's barely 10 lines of pseudo-code.
You people don't understand the very BASICS of hardware-level development, emulation, virtualization, timers and RTCs. it is outrageous that you're even posting these kinds of e-mails on a public e-mail list. You should be ****EMBARRASSED*****.
Hint: What results are better on a VM?
500, 490, 510, 8000, 7900, 8100, 5000, 4900, 5100
OR
500, 800, 1000, 1400, 1600, 1800, 2000
???
Based on your e-mail and comparing old/new output, it seems you believe #2 is better, because "the values are only between 500 and 2000, but new implementation goes between 500 and 5100!".
If you don't understand why #1 is better, please don't even bother replying.
And now, for the other geniuses on this list, there is a BIG BUG in ReactOS, that NOBODY CAN FIGURE OUT.
Can *YOU* solve it???
Here it is:
We have a function:
void a(int waitTime) { for (int i = waitTime * Factor; i > 0; i--); }
And a Factor that used to be 64 or some other low value.
People called a with a very large number.
Now, the Factor is a large number, in the thousands.
People have NO idea why, now, calling a "takes much longer now?!? :(".
5000$ if you can figure it out, paid straight out of ROS foundation! Only a genius could figure this out...
But you know what the STRANGEST thing is?
Windows behaves the same way in Vmware!
In fact, Windows drivers even DEPEND on this behavior!
Quick, someone, tell Microsoft! Their engineers are stupid too! This kind of code should give random values between 1000 and 4000 in a VM, not accurate timing counts based on interruptions of the VM emulation code!
On 2009-10-27, at 12:36 PM, Aleksey Bragin wrote:
I tested the new implementation in same vmware environment, 5 boot ups, here are values of the stall factor: 921 2426 873 2405 2405
I can't say it's a huge success over the old implementation (it provided values in the 1000 - 4000 range in the same environment), taking in mind how more complex the code became (it even has its own ISR handler embedded into the function!!).
WBR, Aleksey Bragin.
On Oct 27, 2009, at 4:15 PM, Alex Ionescu wrote:
And it continues to do its job today -- you added code telling UniATA "wait between 500ms and 5seconds", and it's working fine in trunk.
Why are people complaining "it takes UniATA up to 5 seconds to boot" when this is exactly the code you intended to add?
Also:
"Maybe theres a better way to get this done, but it was enough for testing and did its job well."
Is now my all-time favourite quote, ever.
I bet Hitler would've said the same at Nuremberg....
On 2009-10-27, at 8:50 AM, Daniel Reimer wrote:
These timers were added because some SATA adapters are fucking slow in initializing and uniata would continue too early for them and this results in failures. Maybe theres a better way to get this done, but it was enough for testing and did its job well.
Alex Ionescu schrieb:
The real problem is that UniATA is full of shit code from Aleksey that does things like StallExecution(100000). Microsoft says not to go over 50, but hey, this is ReactOS....reading docs?? HAHAHA!!
I've looked over Stefan's code and it is perfect, and sets a correct stall factor.
On 2009-10-27, at 8:24 AM, Sylvain Petreolle wrote:
It was present here in VirtualBox 3.0.8 for some time and disappeared after Stefan's change for exception management. Kind regards, Sylvain Petreolle
*De :* Gabriel ilardi <gabrielilardi@hotmail.it mailto:gabrielilardi@hotmail.it> *À :* ros-dev <ros-dev@reactos.org mailto:ros-dev@reactos.org> *Envoyé le :* Mar 27 Octobre 2009, 11 h 44 min 19 s *Objet :* Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation calculated the stall count factor incorrectly and produced
Hi Johannes,
It wasn't present for VirtualBox though, at least for me.
Best regards, Gabriel.
Date: Tue, 27 Oct 2009 11:34:03 +0100 From: janderwald@reactos.org mailto:janderwald@reactos.org To: ros-dev@reactos.org mailto:ros-dev@reactos.org Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 43789: - Replace
broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation calculated the stall count factor incorrectly and produced bogus resu
Gabriel ilardi schrieb: > 2) In second stage when loading UniATA, it stays there for
about 4-5
> seconds, there was no delay before. > Hi,
The UniATA delay in 2nd stage was already present before that
commit.
However, only in VMware. > > Best regards, > Gabriel. > Best regards, Johannes Anderwald
Best regards, Alex Ionescu
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu