27 Oct
2009
27 Oct
'09
5:27 p.m.
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:
Best regards,
Alex Ionescu
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:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 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(a)hotmail.it
>> <mailto:gabrielilardi@hotmail.it>>
>> *À :* ros-dev <ros-dev(a)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(a)reactos.org <mailto:janderwald@reactos.org>
>>> To: ros-dev(a)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