Search content
Sort by
Showing 20 of 25 results by kaosbit
Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, async networking, multipool)
OSX user here, new version is working steadily for 15 mins now, no more running wild behavior. I will keep it going for a day and see what happens, but I believe you fixed it, thanks! Do you use a variant of your original kernel again, or this this still phatk?
BTW I am still using Snow Leopard since I don't believe in 1.0 OS versions. Can anyone confirm the miner working on Lion?
BTW I am still using Snow Leopard since I don't believe in 1.0 OS versions. Can anyone confirm the miner working on Lion?
Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, async networking, multipool)
Yeah, but you also lose a ton of important fixes.
Agreed. What I do is, I patch the current master head version so that it uses the kernel and support code from before the change. Works nicely, but admittedly not a solution for the masses.
Regarding performance loss on OSX, well, I mine for fun not for profit, and I'd rather have something that works at reduced efficiency than nothing at all.
Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, async networking, multipool)
This running-wild behaviour is a well known problem with the somewhat broken OSX OpenCL implementation and the phatk-style miner kernels. No proper solution yet. However, you can use an earlier version of Diablo miner with a different kernel. If you check out the sources, do a "git log" and look for the time the switch to the phatk occurred (iirc Jun 24), and use that one. You can also find an older version packaged in a Mac-friendly app by someone else here on the forums: http://bitcointalk.org/index.php?topic=8994.0
This really should be an FAQ entry somewhere...
This really should be an FAQ entry somewhere...
Vielen Dank an redhatzero für Deine Mühe und das 1A Design der Webseite - schön aufgeräumt und alles Wesentliche sofort im Blick, Hut ab! Mit PPLNS hattest Du ausserdem aus meiner Sicht die richtige Richtung eingeschlagen hattest, sprich pro Gemeinschaft und contra Ausbeuter. Darum bedauere ich Deine Entscheidung, obwohl ich sie verstehen kann.
Ich wünsche allen treuen x8s-Minern hier für die Zukunft alles Gute, viel Erfolg, schnelle Runden, und natürlich Tee und Kekse!
Ich wünsche allen treuen x8s-Minern hier für die Zukunft alles Gute, viel Erfolg, schnelle Runden, und natürlich Tee und Kekse!
Re: [Mac/DiabloMiner] Issues with 6970M 2GB card and DiabloMiner!
My pleasure.
Regarding performance, try playing with loops and worksize (-z and -w), you can get a bit more out of it if you manage to find the optimum settings for your GPU. Check the the wiki and forum for that.
Also, regarding responsiveness, try adjusting the FPS (-f), at something like 60 or 120 you may loose a few MHashes but your UI experience will be smoother.
Regarding performance, try playing with loops and worksize (-z and -w), you can get a bit more out of it if you manage to find the optimum settings for your GPU. Check the the wiki and forum for that.
Also, regarding responsiveness, try adjusting the FPS (-f), at something like 60 or 120 you may loose a few MHashes but your UI experience will be smoother.
- Sekundär der Handel mit Bitcoins selber (Taschbörsen etc).
Da bin ich mal gespannt, ob jetzt Pools auch unter Handel fallen :|
Das halte ich eher für unwahrscheinlich, da ja beim Mining die Bitcoins unter sich bleiben. Sobald aber "echtes" Geld ins Spiel kommt, oder Bitcoins dessen Rolle einnehmen, ists klar dass Vater Staat da ein Auge drauf haben will. Juristisch sind Bitcoins wahrscheinlich sowas wie Sammelkarten - tauschen ist eine Sache, gewerblicher Handel eine andere.
Mir geht die Diskussion mittlerweile ziemlich auf den Sack!
Tschö erstmal...
Tut mir leid, Du hast natürlich recht, das führt natürlich wieder mal zur philosophischen Grundsatzdiskussion um die Bedeutung von Werten und Moral. Das Bitcoin-Forum ist daher kaum der richtige Ort um das zu klären, also bin ich ja schon ruhig. Tschö erstmal...
Wenns dich aufregt das Poolhopper mehr verdienen, dann mach doch auch Poolhopping.
Diese Argumentation ist bestenfalls fragwürdig, was vielleicht durch eine einfache Substitution klar wird: "Wenns dich aufregt dass Straßenräuber mehr verdienen, dann werd doch auch Straßenräuber."Musst dich halt entscheiden, ob du der Wolf oder das Schaf sein willst. Solange wie es das System hergibt, ist es einfach nur "clever" diesen Mehrertrag auch mitzunehmen.
Eine schöne Metapher, gestatte dass ich darauf aufbaue. Was ich sagen möchte ist, ich finde es gut wenn die Schafe um ihre grüne Weide eine Mauer errichten, damit die Wölfe draussen bleiben. Wenn das hoffentlich bald alle Schafe machen, sind die Wölfe unter sich und können sich gegenseitig fressen. Denn wer zuvor als großer Wolf aufgetreten ist, der wird dann so schnell nicht wieder auf die Weide gelassen.Ich weiß nicht...das ist alles ganz schön scheiße. Kam hier im Forum nie so genau rüber und dann auch ganz kurzfristig. Und wann war die Rede von n=2mio? Man bekommt keine Mail, es steht nichts in den faqs, 2/3 Mehrheit in der Umfrage...
Ich hab auch schon so einige Shares beigetragen und den Großteil davon nicht nur zu Rundenanfang. Und bloß weil ich die Pools auch mal wechsel und dann zum günstigen Einstiegspunkt zurückkomme, ist es nicht gerechtfertigt ohne klare Information mein Geld auf Leute der letzten Runde aufzuteilen.
Das ist, trotz deiner bisherigen bemerkenswerten Arbeit, nicht transparent und letztlich unseriös. Ich würde wirklich auch gern konstant im pool bleiben, aber wer weiß was als nächstes kommt. Ich schätze, gerade diese Unsicherheit und das ganze Hickhack um die Auszahlungsmethode schrecken viele miner ab - denn wer hat Zeit permanent Forenbeiträge zu lesen.
Ich hab auch schon so einige Shares beigetragen und den Großteil davon nicht nur zu Rundenanfang. Und bloß weil ich die Pools auch mal wechsel und dann zum günstigen Einstiegspunkt zurückkomme, ist es nicht gerechtfertigt ohne klare Information mein Geld auf Leute der letzten Runde aufzuteilen.
Das ist, trotz deiner bisherigen bemerkenswerten Arbeit, nicht transparent und letztlich unseriös. Ich würde wirklich auch gern konstant im pool bleiben, aber wer weiß was als nächstes kommt. Ich schätze, gerade diese Unsicherheit und das ganze Hickhack um die Auszahlungsmethode schrecken viele miner ab - denn wer hat Zeit permanent Forenbeiträge zu lesen.
Ich weiss nicht genau wie du das gemeint hast, aber bei mir kommt es (etwas überspitzt ausgedrückt) gerade so an:
"Ich finde es scheisse, dass ihr Looser euch nicht beliebig ausnutzen lasst. Ich bestehe auf meine Profit-Maximierung ohne nennenswerte Arbeit beizusteuern. Und wenn Ihr schon so einen Zwergenaufstand wagt, dann warnt mich gefälligst vorher ausgiebig, ich bin zu wichtig um öffentliche Foren zu lesen."
Sollte hinter deinem Beitrag eine andere Gesinnung/Weltanschauung stecke, so entschuldige ich mich für den rüden Ton.
Ansonsten kann ich daraufhin PPLNS nur begrüssen, selbst wenn ich als Gelegenheits-Miner dadurch vielleicht einen statistisch unwesentlichen Nachteil habe.
Re: [Mac/DiabloMiner] Issues with 6970M 2GB card and DiabloMiner!
The problem is that OpenCL in OSX is ... not very good. I get the same error on a current DiabloMiner and any other GPU miners based on the phatk kernel. From what I see, the OSX OpenCL-compiler seems to optimize the entire kernel away, so it runs in zero time but zero results as well.
You can try the Mac app solution from this thread: http://forum.bitcoin.org/index.php?topic=8994.0
This is based on an earlier DiabloMiner with a non-phatk-Kernel, it works nicely for me, but won't give maximum hash rates compared to Windows or Linux mining.
So, you may either switch your OS for mining, or hope that the OpenCL in Lion will fix the issue...
You can try the Mac app solution from this thread: http://forum.bitcoin.org/index.php?topic=8994.0
This is based on an earlier DiabloMiner with a non-phatk-Kernel, it works nicely for me, but won't give maximum hash rates compared to Windows or Linux mining.
So, you may either switch your OS for mining, or hope that the OpenCL in Lion will fix the issue...
Meine Güte, der hat uns ja ganz schön warten lassen. Wenn man allerdings die Historie betrachtet, passt er immer noch prima rein, als Ausgleich für die Glücksfälle sozusagen. Trotzdem wünsche ich mir für die Zukunft doch eher die niedlichen kleinen kurzen Blöcke
Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, async networking, multipool)
And the argument that a JSON-RPC request has to be a POST is irrelevant because the LP request as defined by the Deepbit spec is not a JSON-RPC request just because its response looks like a JSON-RPC response.
A a protocol is mutual agreement on proper procedure, so yeah, you can pretty well do anything you want if people play along. But you should not call it HTTP or JSON-RPC then, if it merely happens to look similar.Diablo chooses to follow the very well established HTTP standard and the somewhat established JSON-RPC standard, rather than the quite ad-hoc LP spec. This is a good thing, even if current pool practice also accommodates the JSON-RPC-ish GET LP, as you indicate:
Fortunately, it's easy enough for pools and proxies to support both by not caring if there is a POST body or not.
But, my GUIMiner just sitts there and says "starting..." without actually doing anything. It did this for 16 hours. Yes my Slush login info was entered, yes it works on their website. Hopefully an advanced or intermediate user can tell me why my miner won't mine...
Not sure about Slushs Pool specifically, but in other pools you also need to configure a "worker access" for you miner program, which is usually different from your pool account. You use the pool login to manage your intermediary BTC account and such, while the miner uses the worker access to request work and submit solved hashes.Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking)
You can post completely arbitrary data, and it will still respond with a JSON-RPC response. Or you can post nothing. It is clearly not JSON-RPC.
Probably a case of "be strict in what you send, but generous in what you receive". And good practice too for some piece of pool software, considering there are so many ways to interpret the LP spec.Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking)
The LP spec doesn't say "the LP request is not a JSON RPC request" explicitly. If it did, then, yes, I could get away with doing GET. Receiving a JSON RPC response is questionable at best in the case that this is true (although normal JSON over HTTP obviously is GETtable).
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
Agreed, this would be questionable at best. The JSON-RPC spec clearly states "A response may only be sent in reply to a request." Just to see what happens, I modified the miner to actually use GET without a request body on the LP connection. The response from pushpool is still a JSON-RPC response, just as if it had received the request:
Code:
GET /LP HTTP/1.1
Authorization: Basic a2FvX2dwdTpmUjMzbDAwN3I=
Accept-Encoding: gzip,deflate
Content-Type: application/json
Cache-Control: no-cache
User-Agent: Java/1.6.0_26
Host: pit.x8s.de:8337
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.1 200 ok
Content-Type: application/json
X-Roll-NTime: Y
Date: Mon, 11 Jul 2011 11:54:01 GMT
Content-Length: 591
{"id":1,"error":null,"result":{"midstate":"d3eed22cc5909d76ac118412da850d8dfabc49687f1674fbcc73cecc45166cbd","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"00000001faca27b55e2524d24df3ab7ef9392b5c85a11bb006de813b000001d00000000035940bd70e45c1e87c69af951db0705d893945dda73c0202ad691730070e15044e1ae4571a0abbcf00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
Authorization: Basic a2FvX2dwdTpmUjMzbDAwN3I=
Accept-Encoding: gzip,deflate
Content-Type: application/json
Cache-Control: no-cache
User-Agent: Java/1.6.0_26
Host: pit.x8s.de:8337
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.1 200 ok
Content-Type: application/json
X-Roll-NTime: Y
Date: Mon, 11 Jul 2011 11:54:01 GMT
Content-Length: 591
{"id":1,"error":null,"result":{"midstate":"d3eed22cc5909d76ac118412da850d8dfabc49687f1674fbcc73cecc45166cbd","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"00000001faca27b55e2524d24df3ab7ef9392b5c85a11bb006de813b000001d00000000035940bd70e45c1e87c69af951db0705d893945dda73c0202ad691730070e15044e1ae4571a0abbcf00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
Bottom line: It seems that pools really don't care one way or another. So let's stick with proper JSON-RPC.
Re: When GPU mining, does quality of the rest of the components matter?
Pardon me, "Windows XP", really? Not to start a flame war, but every Windows release has been a resource hogger in its days. If you go for just mining (which I assume you do), I suggest a stripped down version of Linux as OS. From my own experiments with Linux router, this works even on the most ancient kinds of hardware.
Mir ist vorhin etwas seltsames aufgefallen, als ich mal aus reiner Neugier auf die Kommunikation zwischen Worker und Pool geschaut habe.
Irgendwann will der Worker die HTTP-Verbindung schliessen (Java, seufz), schickt dazu ein FIN/ACK-Paket. Unmittelbar darauf antwortet der Pool mit
Äh, ja. Wahrscheinlich hat die Pool-Software beim Schließen der Verbindung nur noch eine Leerzeile gelesen, die natürlich keinen gültigen HTTP-Request darstellt, geschweige denn JSON-RPC. Aber trotzdem sollte sie dann nicht sowas senden, zumal die Verbindung ja schon halb zu ist! Das Ganze ist natürlich nicht weiter schlimm, nur komisch, und verbrät sinnlos etwas Bandbreite die man sicher besser nutzen könnte.
Ist irgendwem sonst sowas mal aufgefallen? Steht was im Logfile des Pools dazu?
Irgendwann will der Worker die HTTP-Verbindung schliessen (Java, seufz), schickt dazu ein FIN/ACK-Paket. Unmittelbar darauf antwortet der Pool mit
Code:
HTTP/1.1 400 Bad Request
Content-Type: text/html
Connection: close
Date: Sun, 10 Jul 2011 17:13:38 GMT
Content-Length: 134
400 Bad Request
Invalid method in request
Content-Type: text/html
Connection: close
Date: Sun, 10 Jul 2011 17:13:38 GMT
Content-Length: 134
Method Not Implemented
Invalid method in request
Äh, ja. Wahrscheinlich hat die Pool-Software beim Schließen der Verbindung nur noch eine Leerzeile gelesen, die natürlich keinen gültigen HTTP-Request darstellt, geschweige denn JSON-RPC. Aber trotzdem sollte sie dann nicht sowas senden, zumal die Verbindung ja schon halb zu ist! Das Ganze ist natürlich nicht weiter schlimm, nur komisch, und verbrät sinnlos etwas Bandbreite die man sicher besser nutzen könnte.
Ist irgendwem sonst sowas mal aufgefallen? Steht was im Logfile des Pools dazu?
Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking)
Quote
Something is extremely wrong with OSX. Its saying its executing kernels, but then not, and then doesn't emit any errors.
DM will wildly spin like that when kernels take zero time to execute. Problem is, the implementation MUST emit errors.
I so very much hate OSX.
DM will wildly spin like that when kernels take zero time to execute. Problem is, the implementation MUST emit errors.
I so very much hate OSX.
Well, yeah, OSX is special. I am experiencing the same problem with the master of DiabloMiner. Strangely enough, a previous version (the one packaged as a Mac App) works nicely! Playing around a bit, I found the problem seems to have occurred between these git commits:
Quote
commit 354b53286af2e982e5c8aa030784a785ebc5032b
Date: Sat Jun 25 02:17:14 2011 -0400
Switched to an unholy union of the current kernel and phatk. Dear Lord,
forgive me for I have sinned.
commit 2d0ed8523c17d011ae5e755936baab01becab171
Date: Fri Jun 24 01:22:45 2011 -0400
Move execution threads to 2 down from 3 since getwork can no longer
block execution threads
Date: Sat Jun 25 02:17:14 2011 -0400
Switched to an unholy union of the current kernel and phatk. Dear Lord,
forgive me for I have sinned.
commit 2d0ed8523c17d011ae5e755936baab01becab171
Date: Fri Jun 24 01:22:45 2011 -0400
Move execution threads to 2 down from 3 since getwork can no longer
block execution threads
I branched from the "pre-phatk" checkout and patched all later non-kernel changes into it. Works great!
So the new kernel must at least be part of the issue. Figures, poclbm with phatk actually freezes my WindowServer, grrr.
But you're right, OSX really should do a better job at error reporting. With the way it behaves now, I have no idea how to fix this.
Oh well, praise git. I'll stick with my branch for now.
Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking)
Quote
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
You are correct regarding the HTTP spec, of course. The LP specification is rather ambiguous at this point. However, a GET would actually make sense when the reply is a JSON-RPC notification (id: null). Then the procedure would be like this:
- The client does a simple GET on the LP URL, indicating its interest in "interruption" by notification
- Once the network finds a new block, the server replies with the fresh hash, as if the client just issued a getwork request
- The client aborts/discards the obsolete calculation and starts on the received fresh one - no need for a getwork on the main connection!
- The client re-reisters for "interruption" by starting again with the first GET step.
Of course this is just my interpretation of the LP spec. But it seems that at least poclbm agrees with me, from a quick glance at the sources.
Anyway, thanks for this nice piece of software, keep up the good work!