Sorry, did not quite understood your question. For running with Windows the current official binaries are built with support for GPU and FPGAs, so you should be able to drive your 5830 and the Single.

As for tuning the card from an external tool (AB, ...), it should be doable when you do not use cgminer controlling options (--auto-fan --auto-gpu). If you are monitoring temps also externally, you can disable ADL completely (--no-adl). That's how it should be, but I'm not using Windows and YMMV.

Talked to a guy that reverse-engineered WiFi chips at register level to develop Linux drivers and realized that it will not be easy.

The approach to hook into the i2c communication and log command sequences is sure the way to go. But it won't be enough to just collect the info per-chip, it most probably will be required to have it per-card. Setting the clocks at controller for one card does not necessarily mean the same for a similar one (assembly options, scaling, offset, etc.). That's possibly the reason why bulanula can't set his params with radeonvolt.

If you string the Afterburner binaries there are IDs for supported cards, most probably they are using card-individual settings. Therefore we basically would have to rewrite AB to get reliable control over our mining cards - it is more a man-year task than a weekend's hack.

Given the remaining lifetime of mining GPUs of say 6-9 months (yeah, see DAT around the corner asking for my cards -- cheap ), I'd say it does not pay off to invest that effort.

Hi mod, OP not active for nearly a year, so its ok to hijack his thread I guess...

True, the latest campaigns for energy efficiency and green labels really pushed the manufacturers to save energy. My current 46" plasma is using as little as my previous 24" one during operation and only 0.3W in stand-by. But my other one wastes ~9W plus 12W for the cablecom STB for just being ready to watch the news once a day - just insane! Using a standby-killer for a month I can save enough to power one of my rigs for nearly 18hours -- insane²! (see the irony?).

To resolve the confusion here: my primary goal was not to further OC cards to squeeze out their last kH/s but to maximize the H/J, which with Linux is not possible with the given max delta between mem and engine clocks Con is describing.

Patching BIOS to surpass the absolute max ranges is fine to push the card to the limit (which I won't do any more after bricking one 6950 trying to unlock it  ), the 7970s I lastly added to my rig do not really need patching - they just run fine with cgminer (see [1]). But reading people are able to reduce energy consumption by 20% lowering memclock and core voltage makes me wanting go back to Windows.
(OT: Hell, not long ago I bought standby-killers to turn TV off over night instead of letting it consume 5W in standby-mode, now I'm burning kWatts 24/7  , different story).

My pragmatic idea was to record the i2c-commands issued by Afterburner when controlling popular mining cards and to build up a library for directly accessing the controller chips (like radeonvolt does for the vt1165). But thinking further, with that lib you'd give the user the perfect tool to fry their cards. Counter measures (like use it only for reducing values) are not applicable in the open source world - we'll soon have folks yelling at cgminer/Linux for bricking their cards.

Con, you're often not happy with AMD's Linux drivers (who is), but you'd also agree better to live with the limitations at the safe side than having the freedom to kill miner's cards, right?


OP, sorry for hijacking this thread. Closing here.


[1] https://bitcointalk.org/index.php?topic=67283.msg824652#msg824652

Thanks for clarification.

Whether ADL is limiting ranges or the BIOS does, effect remains the same: getting full control goes only by bypassing AMD provided interfaces and accessing HW directly (please correct me if I'm wrong assuming those controller chips are I2C accessible).

I doubt that MSI as manufacturer had to reverse engineer to get Afterburner done, but GPU-Z folks for sure had to. That's why I proposed social engineering approach, i.e. maybe some guys from OC scene are also bitcoiners and have access to specs or source code willing to share. Maybe you as one of the technically most competent bitcoiner are the one?

Are you saying that the limitations with Linux can be bypassed by just patching the BIOS? I understood that the values kept in BIOS are the absolute min/max ratings, but that the ADL imposes additional relative limitations (like delta(core, mem) <= 150MHz on Tahiti).

Other thing is that Linux ADL functionality is probably years behind on what's doable in the Windows world (not because of ATI being more active there but because of manufacturers providing low-level access). Access to 79xx-VRM controller might not find its way into ADL during the use of those cards for mining

Therefore an I2C sniffer would be a valuable one-time-investment to port low-level control functionality over to Linux. Since this should be a commonly useful tool for common devs, I was hoping to find some existing sniffers or bus loggers. No luck so far...

Thanks for the commitment, any support will help. I think most Linux fellows sooner or later feel this desire to move back to Windows, being it that LibreOffice is not able to open some DOCX or your fav game not working under WINE, right

We should at least try to make miners equally happy with Linux.


No, if we succeeded to reverse engineer the thing we would have some mean to gradually add support for any card that is supported by Windows tools. So assume the outcome of this effort was an I2C-sniffer and you need to get your card supported. You'd just have to switch to Windows, run the sniffer, set some parameters with Afterburner and collect the commands sent over the bus. If communication is not crypted or intentionally crippled, you just take the command sequence over to the Linux library and voila - your card got supported.

Thats without the minor details First step would be to hook into Afterburner and log its access to the I2C display adapter interface (see [1]). Interested?


[1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff567381%28v=vs.85%29.aspx

Folks,

sorry to bump this almost-dead thread.

It really bothers me to be restricted to fully control my GPUs when driving them with Linux. Most serious miners should agree that operating their GPUs with cgminer under Linux is the ideal setup (free, robust, head-less, efficient, etc.) -- if one could control clocks and voltages as freely as it is doable with Windows tools.

Right now cgminer uses the ADL library to control those values, but it is restricted to what AMD finds to be 'sane' values, that is e.g.: a max clock delta of 125MHz between core and mem clocks for 69xx and 150MHz for 79xx. From manufacturer's perspective there for sure are good reasons to restrict users' access to the controlling chips and prevent him from frying his cards, while OTOH it is completely insane to burn significantly more energy for mining on Linux than on Windows.

The latest Tahiti cards are equipped with the CHiL CHL8228G VRM. MSI Afterburner and GPU-Z recently added support for the latest AMD cards when those devices got supported. For Linux we'd need the same direct I2C-support to all controlling chips. Sadly, for that VRM only a product brief document is available at [1]. I poked around and it is not possible to get the full data sheet, even under NDA. Obviously MSI as card manufacturer has access to the specs to support it in Afterburner, but evenly obvious the GPU-Z folks had to reverse engineer to get their support implemented.

It is illusory to assume Linux folks will get access to the specs, even if we hint that bitcoin miners love ATI cards and we promise to be very careful (its just too dangerous to give users access at that HW level). Therefore, reverse engineering is the way we must take. We could:

• reverse engineer MSI Afterburner or GPU-Z to unveil the command sequences required for full control
• hook into Windows I2C driver and trace the I2C commands issued
• social engineering (know someone at ATI research, MSI, CHiL, etc.)

The first approaches require deep Windows system knowledge, plus some cracking capabilities for the first approach or some DDK experience for the second (assuming there are no I2C sniffer already available).

My active times with Windows passed by long ago, but I know that this is a many-weeks job - no way to get the efforts compensated by bounties or crowd funding. Anyone willing to support here needs to do it for the glory (and you'd help saving the world by greatly reducing mining energy consumption ). Ideally we should end up with an ADL replacement that gives unrestricted access to the controlling chips. BTW, my own capabilities are limited to the Linux side, i.e. as soon as I get the specs I would work out a library to be included in cgminer (if OP or runeks aren't to take the glory).

Any supporters?


[1] http://www.irf.com/product-info/datasheets/data/pb-chl8225.pdf

Wie sähe es mit der MwSt. bei einer Lieferung in die Schweiz aus? Müsste ich die erst bezahlen und dann gegen Vorlage der Verzollungsunterlagen wieder ausbezahlen lassen, oder fällt bei einer Lieferung ausserhalb der EU keine MwSt. an?

Ich könnte mir die Boards alternativ auch nach Konstanz liefern und mir beim dortigen Zollamt die Ausfuhr bestätigen lassen. Erfahrungen oder Tipps?

Damit die 100 sicher erreicht werden, wäre ich mit 20 Stück dabei. Lege auch noch 10€ pro Board drauf, wenn ich sie im Mai bekomme. Wenn es allerdings mit der Lieferung bis Juli dauert, wäre mir das zu lang (bis dahin sind die 4-6 Wochen bei BFL um ).

Gruss

imsaguy,

something seems to be wrong with your mail forwarder. Could you please check for my recent PMs?

You wanted to come back with conditions for longer term (bond or CD like) investments more than a week ago. With you not reacting on my inquiries I put larger portions of my coins to hashking but still need to dump some more.

Could you please clarify if you're still interested in ~100BTC over a longer investment period? Thanks.

To what core clock can you drive them long-term stable with 100% fan? Not sure about lifetime expectations when blowing max., but remember some senior bitcoiners mentioning better not to do it...

Thanks for confirmation. Could you maybe add deposit receipt and due dates to the Google doc spreadsheet?

It took some time for my HD7970 to arrive, nevertheless here my measures:

Previous setup: 3*6950, 1.1GH/s, ~500W

New setup: replaced 2 6950 with

• 1 XFX HD7970 Black Edition (the reference design one)
• 1 Gigabyte GV-R797OC-3GD (three fan design)

Now pulling 1.7GH/s at ~750W

Linux rig is driven by cgminer with cards configured to operate within stock ranges, i.e. the XFX at core 1000-1125 and the Gigabyte at 1000-1200, voltages untouched at 1.170 and the memclock set as delta of 150 to core clock (can't be downclocked further on Linux ). All cards with powertune of 5%, auto-fan enabled with 85% target, auto-gpu enabled with temp-target of 75°C.

cgminer stats after running 48h:

GPU	Temp	Fan%	core	mem	MH/s	HW-errors	utility	intensity
XFX	77	85	1090	940	644	0	8.95	11
Gigabyte	72	69	1200	1050	698	224	9.56	11
6950	73	--	870	745	357	0	4.94	9

What you see from the table is that the three fan cooling of the Gigabyte card is way better, at max stock clock of 1.2GHz it never reaches the target temp of 75°C and therefore always runs at full speed. The XFX on the other hand gets hot with the fan always blowing at 85% (which btw. compared to the Gigabyte is unacceptably loud to sit in the same room), cgminer never pushes it to its max stock core of 1.125 GHz. Not sure what the reasons for HW errors with the GV are, but all in all it performs better than the XFX Black.

If I should stay with GPUs and ever need another HD7970 for mining, I'll stick with the Gigabyte. If you plan to buy a card also for gaming, do yourself a favor and go listen to a XFX BE before you decide to

200BTC sent to 1EBVafhEqvT6aMXWEJsTGQFHesR9n4ypum for 8 weeks at 2.5%

Thank you for putting my concerns in this easy to understand sentences. Still not clear if 10/61 from new shares go directly to THE RESERVE or not, however 1/61 always go directly to the officers...

Anyhow, its useless now, ask prices doubled to 2BTC meanwhile.

Yes, I meant I need go back studying, you for sure are right. Sorry for confusion.

Thanks, need to go back and read more how primary vs. secondary shares are handled in the 'real' world. Will need to hurry to come back, only 295 shares left...

Sorry, I might be wrong by being stuck to the traditional stock market. There the market capitalization does not correspond to the sum of company assets but also reflects the investors' hope and expectations (Apple has never ever assets worth half a trillion US$, right).

Therefore your claim is true if the FUND exactly matches the market cap. But how about this: assume you're ueber successful with your IPO and people are buying SS shares like crazy => 10BTC/SS. You issue another 610 shares, get 1100 from new investors and put 100 aside as risk fund => your profit 1000BTC

Or you don't expect SS shares to sky-rocket?

I see, but this is not how it usually goes. If new shares are issued, the existing holders get the chance to buy new shares with a given ratio according to already held ones. But typically none (including management aka the OFFICERS OF THE FUND) get shares for free.

Say I'd jump in big and buy 306 shares today. Next week you decide to issue 6100 new shares, you then have 1210 shares and I can't do anything about it with my previously 50%+ held shares getting down to 4.5%. Sounds fishy to me...

Sorry for being noob here, but I don't get what 'maintain the ratio of shares offered to the public and shares withheld for its officers' means here. Say I hold 10% or 61 shares and THE FUND decides to issue another 610 shares, does this mean the OFFICERS OF THE FUND get their new 110 shares for free to maintain the ratio and I need to buy another 61 of the new shares to stay at 10%