Re: [ros-dev] Re : [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

[Aleksey Bragin]

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:
> > > 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 <[e-mail]
> > > > > >   mailto:[e-mail]>
> > > > > >   *À :* ros-dev <[e-mail] <mailto:ros- 
> > > > > > [e-mail]>>
> > > > > >   *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: [e-mail] mailto:[e-mail]
> > > > > > > To: [e-mail] mailto:[e-mail]
> > > > > > > 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Best regards,
> Alex Ionescu
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev