27 Oct
2009
27 Oct
'09
6:07 p.m.
I didn't say old implementation was correct, it wasn't really.
Neither I try pretend to be a non-understanding troll.
I'm just nitpicking to the commit message which named a number of
reasons, none of them being correct except the first one:
Subject: [ros-diffs] [sginsberg] 43789:
- Replace broken implementation of HalpCalibrateStallExecution
with a new
implementation by a mysterious HAL ninja and myself. The old
Yes, it was broken.
implementation calculated the stall count factor
incorrectly and
produced bogus results that were off by several thousand, and
varied
by as much for
each boot, and can best be described as "rand()
made complicated".
The new implementation installs its own RTC interrupt
handler to
accurately
Total lie, Alex explained why. It can't be called "totally broken" if
tested in a virtual machine! Though results were used to judge the
implementation I committed previously. Did anyone test in real
hardware, collected stall factors statistics and performed the tests
attached to the end of this function? Noone? You should be
****EMBARRASSED*****!
calculate the stall scale factor, all done in
assembler instead of
broken C.
Let's write whole OS in assembler, it's gonna be less broken then!
This is the lamest excuse ever.
Fixes the hang at boot when initializing Uniata as
stalls no
longer takes 10 times or more as long to execute then they should.
As I quoted in my test results, it was only ~2.5-3 times more than
necessary, not 10. So another part of a problem is in uniata having
too long delays (I took the figures from reference Microsoft DDK
storage drivers, if I recall correctly).
WBR,
Aleksey Bragin.
On Oct 27, 2009, at 8:27 PM, Alex Ionescu wrote:
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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 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(a)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