Lucky guy ! :))
I am just curious which was your original justification
for RMA of that Titan. How did you argued here ? Just
using Amber instability calc. arguments or you also found
some errors during another common tests like memtestG80,
cuda_memtest, gpu_burn and/or some common Win performance testers
(Heaven, 3DMark ...) ?
Would be nice to know the name of the test which returns technicians used
and which clearly and undoubtedly proved that the given GPU is defective.
How long after purchase you RMAed this card ?
I am also curious on your reproducibility Amber benchmark tests. Now I am
doing
500k steps long ones with updated driver 319.23 and for the moment
it does not seem that driver update solved the problems :((
Marek
Dne Thu, 30 May 2013 14:08:18 +0200 ET <sketchfoot.gmail.com> napsal/-a:
> An update:
>
> Just got a mail from ebuyer who said:
>
> Following extensive tests by our returns technicians, this item was found
> to be faulty. A replacement product will be dispatched as soon as the RMA
> is closed.
>
> For more details check the My Orders section of www.ebuyer.com
>
> Kind regards,
>
> Ebuyer Customer Support
>
>
>
> On 30 May 2013 09:33, ET <sketchfoot.gmail.com> wrote:
>
>> Hi,
>>
>> I believe this was the specific driver I used:
>>
>> http://www.nvidia.com/object/linux-display-amd64-313.30-driver.html
>>
>>
>> I'm running the benchmark now on the super-duper-clocked geforce that I
>> believe is "working". I can't do it on the other Titan as I've RMA'd it.
>> Dunno how long it will take as my CPU is only a quad core i7 :(
>>
>> Will post my results back when done.
>>
>> br,
>> g
>>
>>
>>
>>
>> On 30 May 2013 03:42, Jason Swails <jason.swails.gmail.com> wrote:
>>
>>> On Wed, May 29, 2013 at 6:00 PM, Marek Maly <marek.maly.ujep.cz> wrote:
>>>
>>> > Hi Jason,
>>> >
>>> > thanks for the explanation but to be frank I did not understand the
>>> main
>>> > idea.
>>> >
>>>
>>> I'll try to explain a little bit (but perhaps it's better to just take
>>> Scott's advice and trust him on that). The problem is that addition of
>>> floating point numbers in computers is not strictly associative. That
>>> is,
>>> a + (b + c) != (a + b) + c, due to round-off issues in the last decimal
>>> place or so. As a result, the numerical result of a summation on a
>>> computer depends on the _order_ in which those numbers are added. If
>>> you
>>> change the 'order of operations,' then you risk changing the exact
>>> value
>>> of
>>> the result in the last stored decimal. See the wikipedia page on
>>> Floating
>>> point accuracy:
>>> https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
>>>
>>> Since the force calculation and energy calculation follow different
>>> code
>>> paths, the 'order of operations' differs between the two routines. As a
>>> result, the exact forces may vary a tinytinytiny bit depending on
>>> whether
>>> the force or energy routine was called. This difference is tiny and
>>> negligible, but since classical systems of <2 bodies are chaotic these
>>> differences eventually manifest as completely different trajectories.
>>>
>>> As Scott said, this difference is expected, unavoidable, and
>>> conveniently
>>> unimportant. (In fact, some may argue it's a _good thing_).
>>>
>>>
>>> >
>>> > I understand that for system evolution by Molecular Dynamics is not
>>> > necessary to calculate energy
>>> > just forces and so that energy is calculated only when explicitly
>>> > requested (i.e. with NTPR step period) but what I have problem to
>>> > understand is why the printed (in mdout file) immediate energy value
>>> E(i)
>>> > at step "i" should be dependent on the number of my "Energy requests"
>>> > before the simulation reached step "i" (i.e. dependent on NTPR
>>> value)? I
>>> > naturally assume that my energy requests do not influence evolution
>>> of
>>> my
>>> > molecular system by Molecular Dynamics (e.g. do not influence forces
>>> ...).
>>> > I see NTPR parameter just as the period in which some function
>>> > "CALCULATE_ENERGIES" is called to calculate all the energy
>>> components of
>>> > the simulated system in given moment, that's all, but perhaps I am
>>> not
>>> > right here ?
>>> >
>>> > How exactly "ene_avg_sampling" parameter is connected with "NTPR"
>>> > parameter ?
>>> >
>>>
>>> Like the "ntpr" parameter, the ene_avg_sampling variable tells pmemd
>>> how
>>> frequently you _want_ it to calculate energies. If ene_avg_sampling is
>>> set
>>> to 10, then pmemd.cuda will compute energies every 10 steps so they
>>> can be
>>> averaged. If ntpr is any multiple of 10, then pmemd.cuda will still
>>> compute energies _only_ every 10 steps (so that it can be averaged that
>>> often). As a result, the code path is dictated by the fact that
>>> ene_avg_sampling is 10 rather than by the value of ntpr.
>>>
>>> I hope this clarified things a little bit...
>>>
>>> Jason
>>>
>>> --
>>> Jason M. Swails
>>> Quantum Theory Project,
>>> University of Florida
>>> Ph.D. Candidate
>>> 352-392-4032
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>
>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
> __________ Informace od ESET NOD32 Antivirus, verze databaze 8392
> (20130530) __________
>
> Tuto zpravu proveril ESET NOD32 Antivirus.
>
> http://www.eset.cz
>
>
>
--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu May 30 2013 - 06:00:03 PDT
