nvidia rtx-2080

[nomead]

Originally Posted by ET_

Did anybody test the new RTX 2060 on a Ubuntu 18.04 LTS PC?

It isn't even out yet, release date January 15...

[nomead]

Originally Posted by kriesel

Have RTX20xx become reliable yet? (Reduced, low probability of return for repair within months, weeks, or days) The initial going seemed to be sort of dismal, with some users indicating 2 of 3 or 2 of 2 early failures, including replacements failing.

The problems were mostly on early Founders Edition cards. People with problems scream the loudest. And early adopters are also more likely to be well connected online, so news of these failures maybe spread a bit faster and wider than the number of actual failures would otherwise warrant. Nvidia also admitted there were some "test escapes" among the early boards, but no failure rates were ever given in public. When the board partner cards came out, RMA rates haven't been exceptionally high, in fact, even a bit lower than usual. Some sources connected to these failure news say that about 3,5% has been the norm for earlier generations.

[ET_]

Originally Posted by nomead

It isn't even out yet, release date January 15...

I know there are a lot of testers out there...

[Mark Rose]

Originally Posted by ET_

Did anybody test the new RTX 2060 on a Ubuntu 18.04 LTS PC?

https://www.phoronix.com/scan.php?pa...60-linux&num=1

Those benchmarks are done on 18.04.

[LaurV]

Originally Posted by Xyzzy

Which 2xxx card is equivalent to the old 1080 Ti?

Talking about RTX series, I think?
The 2080 Ti is the same for LL, and 2 to 2.6 times faster for TF.
The 2080 and 2070 Ti are about 75% for LL and 2 times for TF.
The 2070 is about 50% for LL and 1.5 to 1.8 times for TF.
Your mileage may vary. Our mobo has 7 PCIE from which 4 are x16 (this matters for data transfer)

[LaurV]

Originally Posted by kriesel

Have RTX20xx become reliable yet?

No. And I don't believe they can fix it soon. Maybe we will see some new microcode (the Specter fashion) which will restrict its performance by 5% or so.. But I don't think it will be a hardware fix (political reasons, it would need a lot of recalls, "why his card is working and mine not?", etc). Of course, all this is wag (wild ass guess), but it comes from my 30 years of electronic design experience.

[kriesel]

Originally Posted by LaurV

No. And I don't believe they can fix it soon. Maybe we will see some new microcode (the Specter fashion) which will restrict its performance by 5% or so.. But I don't think it will be a hardware fix (political reasons, it would need a lot of recalls, "why his card is working and mine not?", etc). Of course, all this is wag (wild ass guess), but it comes from my 30 years of electronic design experience.

It's hard to see how a software change would prevent infant electronics hardware failures. Not dealing adequately with a product design or manufacturing defect can be damaging to market share and future.

Intel tried long ago to use PR to handle the FDIV bug in the Pentium, a much lesser issue than early total failure, got a black eye in the press, relented and did a full and free voluntary chip exchange, then capitalized on standing behind their hardware, earning positive press worth more than the exchange program's cost, and making keychains of the bad chips. I still have one of those keychains.

[LaurV]

Originally Posted by kriesel

It's hard to see how a software change would prevent infant electronics hardware failures. Not dealing adequately with a product design or manufacturing defect can be damaging to market share and future.

Totally true and agree for the second part. Related to the "infant electronic" part, nowadays that is mostly microcode (yes, I do that for a living, and I do not talk about discrete resistors and transistors, but you will be amazed to know that even a banal opamp may have some microcode inside, to adjust its gain or offset, etc). Talking Intel and CPUs, their "water in the cpu, please stop it for 10 minutes to dry" bugs that gave us Meltdown, etc., are also "infant electronic failures", due to which somebody can pick your pockets (memory/registers) during he is searching his own pockets, if your left hand is not in your right pocket, or so. But they fixed with a microcode. Maybe not the best example, but you got the idea.

I still have one of those keychains.

For sale? We would buy one... (if the seller don't rob us off).

[kriesel]

Originally Posted by LaurV

Totally true and agree for the second part. Related to the "infant electronic" part, nowadays that is mostly microcode (yes, I do that for a living, and I do not talk about discrete resistors and transistors, but you will be amazed to know that even a banal opamp may have some microcode inside, to adjust its gain or offset, etc). Talking Intel and CPUs, their "water in the cpu, please stop it for 10 minutes to dry" bugs that gave us Meltdown, etc., are also "infant electronic failures", due to which somebody can pick your pockets (memory/registers) during he is searching his own pockets, if your left hand is not in your right pocket, or so. But they fixed with a microcode. Maybe not the best example, but you got the idea.


For sale? We would buy one... (if the seller don't rob us off).

Microcode changes don't fix blown circuits (opens or shorts). (Especially if the circuit is so blown, it won't load a new microcode.) If they did, cpu core yield on a fab line would be 100%.
Pentium keychain: you probably can't afford it / don't want to pay the price in high end reliable gpus for it.
We've sure come a long way since two or four matched-properties transistors packaged in the same metal can with completely separated lead pinout, for better analog circuit performance.

[LaurV]

Sure, all electronic circuits work with magic smoke, and they are good as long as the magic smoke stays inside. I was talking only about the situation "as long as the magic smoke is inside". When the magic smoke gets out, even the mother of the microcode can't fix it.

In this particular case, Nvidia said repeatedly that "we are working with each user individually like we do always", which actually means first the problem is not wide, then they do not really have a (general) solution (maybe there is none, and the defective cards are indeed separate things, like blown transistors), and there is no whisper of a recall, or things being wrong with the architecture, etc. Which is good and bad, in the same time.

I delayed buying my own 2080Ti (s) for two months already...

[dcheuk]

I have two machines running Turing graphics cards, they both seem to stuck in a zero residue loop while running CUDALucas 2.05.1. However on 2.06beta the problem seem to go away.

Meanwhile with the same NVIDIA driver and CUDA version (10.0) on the same computer, with a Pascal graphics card CUDALucas 2.05.1 seem to function normally. So this is isolated, at least locally on my machines, to the Turing cards.

1, So, is this a known issue with the Turing graphics card running CUDALucas?

2, Should I worry about the reliability of the residue at the end of the test if their error is somewhere in the neighborhood of 0.2000?

Thanks.