LMAO that is the dumbest thing I've read all day. Yes ATI is going to focus their attention on a market that is less than 1% of the total graphics market. By the time Q4 rolls around bitcoin will be expired.
He's a troll, pay him no mind. Hopefully the mods will have terminated his account by the time Q4 2011 comes and goes, if not before. |
|
|
|
|
Maybe try with a different driver version, or different tool (like ATIOverdriveCtl).
|
|
|
|
LOLWUT they getting 200 MHs for some Spartan fpga !
Quit trolling you fuck. Go sell your 5870s, but do so quietly. |
|
|
|
|
Let's not hijack this thread with philosophical or emotional BS and keep it topical, shall we?
Count me in for hardware/software design, testing, and general input on scalability. My background is IT/datacenter management; have already implemented designs with Microchop and Digi microcontrollers. As an aside, you think crypto chips will yield superior results to the $16 Spartan 6's with 45k LEs?
|
|
|
|
I agree with the notion of "Miners, sell higher!". If BTCs were worth their high of $8.90ish before the difficulty increase, they ought to be worth at least $8 plus the proportion of increased difficulty, so just shy of $11 each, in my estimation. However, let's not forget that the market is already overpriced (obviously, as prices have been flat-to-descending for a while). It's fundamentals are hard to ascertain, as it's somewhat like gold, but better, yet not as well known and not as well traded. I made projections back in late April as to what I think the current BTC value would be now, based on the supply/demand fundamentals of difficulty increases and other predicted (even if only psychological) fundamentals. My original prediction for today's date was $3.23, vastly different from the $6.90 to $7 that we're seeing today. About a week later I revised that prediction (based on more information) upward to $4.76. Still a far cry from $7  Given that current prices are 47% higher than my last prediction, that'd put us at $8.62 by May 25th, $9.03 by May 31st and $11.55 by June 11th. As always, we'll see... |
|
|
|
The miner can be ran from the shell. However my understanding is that you need to start X to initialize the video card and that there's no getting around it. Fortunately you can run a very simplified non-intrusive version of X on the console. For example, this is the way I mine headless (without needing a keyboard/video/mouse) via an ssh session: # xinit -e twm &
# export DISPLAY=:0.0
# aticonfig --odsc=990,900
# screen -t (some name for this miner) python phoenix.py blah blah
That will start xwindows with twm running on the console (twm is not included in the X Window System group by default, you'll need 'yum -y install xorg-x11-twm'). Then you can screen the miner. This is particularly helpful when you have several mining rigs, or several GPUs in one box. Hope that helps. |
|
|
|
It's in RPM Fusion (again). Just install akmod-catalyst and it will pull in everything you need (except for the Stream SDK).
Yeah I discovered that a little earlier. What's odd is that none of my systems seem to be updating grub.conf to point to the updated 2.6.35.13 kernel (pulled in by the regular Fedora update repos). The RPM Fusion kmods need this version because of magic number congruency in the kernel. Thus the benefits of having an all-in-one kickstart script are somewhat nullified since you've got to hack on grub.conf manually. I haven't looked into the kernel RPMs to see if this is some kind of scripting error during the update, but in any event, I feel like it would confuse Linux newbies too much if I made such a guide under the circumstances :/ |
|
|
|
|
FYI, I've come up with a method under Fedora 14 that is _much_ easier, as it already has Python 2.7, NumPy and JSON support built into the existing OS RPMs. Same with git, python-twisted (needed for Phoenix) and probably some other things I'm not thinking of. I've gotten the provisioning down to a simple kickstart, ATI driver install, SDK install, PyOpenCL and the miner. The SDK is RPM'able, and the drivers do exist in the wild according to my googling (maybe included with FC14 also?).
Will produce a guide, including a kickstart file, when things settle down.. if that should ever happen.
|
|
|
|
|
Actually when I mentioned conventional tools, I was thinking along the lines of:
1) with a fully booted system, create a partition and fs on the new USB stick
2) dd if=/path/to/boot/blocks/for/usbstick.bin of=/dev/sdx (makes the USB stick bootable)
3) mount /dev/sdx1 /mnt
4) cp -ar /* /mnt
Presumably the boot blocks for the USB stick would've come from a 'dd' of the first 512 bytes of another working USB stick. Curiosity has now gotten the best of me; I think I should try this in my spare time.
|
|
|
|
|
Sweet. I've thought about using USB as well, I think the problem I'd run into is that it wouldn't work on some of my machines. You're probably thinking to yourself "if it has a PCI-E, I can't imagine why USB boot wouldn't work". Intel-made boards are screwy like that; everything I have that's DG965SSCK and later has issues booting and installing OSs from USB CDROMs in certain circumstances. It's not such a stretch to think that USB sticks might present a problem. I've found that Intel's motherboards are the highest quality hardware, and the worst quality BIOS. Go figure.
Out of curiosity, why was it necessary to use Clonezilla rather than conventional tools?
|
|
|
|
@stickman, thanks for the guide! If you're doing this frequently, you might wish to setup a kickstart file to choose all of your OS options for you, rather than having to specify things during setup. I run a dedicated hosting company; we use kickstart to provision every CentOS box. The procedure, even from a CD or DVD is really straight-forward. Assuming DHCP and a non-buggy installer, invoking the setup disk1 with 'linux ks=http://www.some.com/mykickstart/ks' is all you need (and maybe an 'ip=dhcp' somewhere in there, I forget because we manually specify ip=x, dns=x, gateway=x, etc). In our case, we use a PXE server to feed netboot images at the machines, rather than CDs, but the procedure is still the same. Speaking of PXE, if my mining operation gets any bigger, i'll be using PXE for diskless netboot of the OS pretty soon  |
|
|
|
It's my understanding that you can't get that information from multiminer - it's contingent upon the release of a certain python-to-html generation script (or the coding of your own script) which the developers have not yet released. Not sure why. There is another option, cdhowie's flexible mining proxy: http://bitcointalk.org/index.php?topic=5506.0Note that I am still not yet able to use it on a CentOS 5.5 based machine, it generates too many stale shares because long polling is broken, although others seem to have success with it. |
|
|
|
Hmm... I'm not going to discount this explanation, but I don't see any evidence that sending an HTTP 1.0 request is causing problems. My workers are issuing long-polling requests to deepbit through the proxy and they appear to be working just fine.
I just cranked up a new kind of sniffer, one that logs each unique tuple into a separate file. What I found is that upon receiving my input text (fed to your proxy via telnet) as follows: GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1
Connection: close
Host: bitproxy.xxxxx.com
Authorization: Basic xxx
User-Agent: phoenix/v1.2
(and one more trailing CR)
Your proxy actually connected to deepbit twice. The first time was apparently to setup the actual long-polling session for my telnet to the proxy. The second communication was completely blank - neither side said anything. After a couple of minutes, my telnet session spat back the following: HTTP/1.1 200 OK Date: Wed, 11 May 2011 09:59:01 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxySet-Cookie: PHPSESSID=bd8s2r4gnb80pgl6n3hd3ne606; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 78 Connection: close Content-Type: application/json-rpc {"error":"Invalid response from long-poll request.","result":null,"id":"json"} This was not in response to anything being sent from deepbit to the proxy - deepbit never at any time uttered another word. I ran the same testing iteration again and got a successful long poll when the pool jumped to the next block, but on the next iteration it was exactly the same behavior as above. (note that all of this is still based on a 2-day old pull, I did not pull the code again per your mention above). Does that help? |
|
|
|
Hmm. This capture is helpful, but without seeing the long-polling request and response that the proxy itself sends out, I can't really say why it's doing this. It is possible that deepbit itself is returning an error from the long-polling request and I'm just forwarding it on to the worker.
Ahhh I see the problem. From your proxy to deepbit: GET /listenChannel HTTP/1.0Authorization: Basic youcanthavemypassword;] Host: deepbit.net:8332 I watched it send this to deepbit once and it worked, but the next time it didn't. The request was the same, but it appears to be failing because you're sending the request as HTTP 1.0. Based on the reply from the pool, you can see that the pool wants to serve HTTP/1.1. So my guess is we're hitting nginx, which is setup as a loadbalancer, and one of the backend machines is configured to work with HTTP 1.0 and the other is not. You can also see from my previous post that the client normally asks in HTTP/1.1 (though in the long polling specification at deepbit's website, they don't mention that it needs HTTP/1.1). If that all looks sensible, can you commit a fix to make the long polling requests in HTTP/1.1? Thanks! |
|
|
|
Yeah, this is probably something that could be done. The red display is pretty easy to do; the shell script will require DB schema changes and a bit more work, but will still be possible. I assume this would be used to, for example, email you if one of the miners stops requesting work? Correct. One could specify a shell script in the database, and perhaps two other user-defined arguments which would be called like: `$script $minerip $timedelta $userdefinedarg1 $userdefinedarg2` And would hopefully cause the script to send me an email letting me know that miner 1.2.3.4 has been down for 300 seconds. I could define three new configuration options: one for the amount of time a miner must have not requested work for it to display differently, one for the amount of time a miner must have not requested work for the script to be run, and one for the script to run. Or the script could be a field in the database for workers, i.e. if the miner is a Windows box you might want a simple email, but if it's Linux, you might want to execute a different script that runs 'expect' and attempts to restart the miner by logging in via ssh and giving it a kick. For that matter, the other two could be database arguments, but if it's too difficult to be practical from a programmatical standpoint, no worries. Thanks again for all of your hard work!
No problem! I'm glad you find the software useful. [/quote] Useful indeed, if only I could make it function as flawlessly in my environment as it does in yours. So as I mentioned, Phoenix 1.2 prints periodic "disconnected" messages. Phoenix 1.45 seems to sporadically connect to the long-polling URL. Phoenix 1.2 will connect, but it disconnects after a period of time. I think I see why. I hit my local mining proxy and fetched the long polling URL. The first time it worked, and actually sent me info on a new block. But the next time I tried it, I encountered a problem that almost surely explains what I'm seeing in Phoenix: GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1 Connection: close Host: bitproxy.xxxxx.com Authorization: Basic xxx User-Agent: phoenix/v1.2 (((2 minutes elapse, and then...))) HTTP/1.1 200 OK Date: Tue, 10 May 2011 06:00:12 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxySet-Cookie: PHPSESSID=4j2r53dsse5afoa5u9k3oratn0; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 78 Connection: close Content-Type: application/json-rpc {"error":"Invalid response from long-poll request.","result":null,"id":"json"}Connection closed by foreign host. Based on the 3 or 4 times I've done this, it seems to happen when there is in fact a new block. This should be easily duplicable for you. If not, I can PM you the info on my proxy and let you see for yourself. Hope that helps. |
|
|
|
|
Just wanted to update this to let you know that Phoenix 1.2 (version I've run for the last couple weeks) seemed to exhibit the problem, while version 1.45 has not yet exhibited the problem during several hours of testing. I'm going to let this thing run for several more hours, then switch over a few more miners to the proxy and see how it goes.
Two additional feature requests:
1) Can you add in code (maybe configured by config.inc.php) to adjust the timestamp according to a user-defined timezone? I've become accustomed to looking at UTC and knowing the offset, but still would be a nice thing to have.
2) The purpose of my push for your software, and what makes it valuable to me, is being able to know if a miner stops pulling and submitting shares (in addition to all of the wonderful features you've coded in so far). Is this a feature you plan to add in the future, i.e. with simply listing all of the miners in red/green status like deepbit does, and having the option to act on it somehow, like with a shell script?
Thanks again for all of your hard work!
|
|
|
|
Ok further to my issue, I captured one of those sessions per below: 13:43:46.455793 IP xxx.113.52046 > xxx.170.http: S 744407596:744407596(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
E..4.^@.~.ewD..qD....N.P,^.,...... . ...............
13:43:46.455904 IP xxx.170.http > xxx.113.52046: S 3067826941:3067826941(0) ack 744407597 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4>
E..4..@.@...D...D..q.P.N..R.,^.-.... B..............
13:43:46.456045 IP xxx.113.52046 > xxx.170.http: . ack 1 win 16425
E..(._@.~.e.D..qD....N.P,^.-..R.P.@) ...
13:43:46.456723 IP xxx.113.52046 > xxx.170.http: P 1:489(488) ack 1 win 16425
E....`@.~.c.D..qD....N.P,^.-..R.P.@)....POST / HTTP/1.1
Connection: close
Content-Length: 302
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2
{"method": "getwork", "params": ["00000001bc66976a156c69045f8108574a73efd268ee2faed010d66f00000672000000003d9dd833b0ac46504204b3be7b9dfa2ce1295409970ac51eab2b8e0ed66d12b34dc827ba1b0098fa02ec2550000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"], "id": 1}
13:43:46.456743 IP xxx.170.http > xxx.113.52046: . ack 489 win 432
E..(W.@.@.X.D...D..q.P.N..R.,^..P...]I..
13:43:46.956705 IP xxx.170.http > xxx.113.52046: P 1:484(483) ack 489 win 432
E...W.@.@.V4D...D..q.P.N..R.,^..P.......HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:43:46 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=badcm71qo331pfnu8b9420med3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 37
Connection: close
Content-Type: application/json-rpc
{"result":true,"error":null,"id":"1"}
13:43:46.956767 IP xxx.170.http > xxx.113.52046: F 484:484(0) ack 489 win 432
E..(W.@.@.X.D...D..q.P.N..T.,^..P...[e..
13:43:46.956948 IP xxx.113.52046 > xxx.170.http: . ack 485 win 16304
E..(.c@.~.e~D..qD....N.P,^....T.P.?..e..
13:43:47.330166 IP xxx.113.52046 > xxx.170.http: F 489:489(0) ack 485 win 16304
E..(.e@.~.e|D..qD....N.P,^....T.P.?..d..
13:43:47.330189 IP xxx.170.http > xxx.113.52046: . ack 490 win 432
E..(W.@.@.X.D...D..q.P.N..T.,^..P...[d..
13:43:55.614063 IP xxx.113.52047 > xxx.170.http: S 3321044043:3321044043(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
E..4..@.~.eSD..qD....O.P...K...... ..I..............
13:43:55.614082 IP xxx.170.http > xxx.113.52047: S 3074415693:3074415693(0) ack 3321044044 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4>
E..4..@.@...D...D..q.P.O.?.M...L....................
13:43:55.614375 IP xxx.113.52047 > xxx.170.http: . ack 1 win 16425
E..(..@.~.e^D..qD....O.P...L.?.NP.@).N..
13:43:55.615008 IP xxx.113.52047 > xxx.170.http: P 1:230(229) ack 1 win 16425
..@.~.dxD..qD....O.P...L.?.NP.@).I..POST / HTTP/1.1
Connection: close
Content-Length: 44
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2
{"method": "getwork", "params": [], "id": 1}
13:43:55.615027 IP xxx.170.http > xxx.113.52047: . ack 230 win 432
E..(.f@.@..zD...D..q.P.O.?.N...1P.......
13:43:56.104782 IP xxx.170.http > xxx.113.52047: P 1:1133(1132) ack 230 win 432
D...D..q.P.O.?.N...1P....u..HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:43:55 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=qt55pon5dn780ipddvv5b5b6i3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1
Content-Length: 596
Connection: close
Content-Type: application/json-rpc
{"error":null,"result":{"midstate":"dfbbd14c8d2c37fbcc47bc795c40fe6c8785fe34516942c390fd3fc51ad5eda5","data":"00000001bc66976a156c69045f8108574a73efd268ee2faed010d66f0000067200000000684f3b8dea52cfbfb263679b2f60b4852a54003f9a515ba1fd86c967ea4c79c54dc827d61b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"}
13:43:56.104936 IP xxx.170.http > xxx.113.52047: F 1133:1133(0) ack 230 win 432
E..(.h@.@..xD...D..q.P.O.?.....1P....u..
13:43:56.105108 IP xxx.113.52047 > xxx.170.http: . ack 1134 win 16142
E..(..@.~.e\D..qD....O.P...1.?..P.?.....
13:43:56.487939 IP xxx.113.52047 > xxx.170.http: F 230:230(0) ack 1134 win 16142
E..(..@.~.eZD..qD....O.P...1.?..P.?.....
13:43:56.487966 IP xxx.170.http > xxx.113.52047: . ack 231 win 432
E..(.i@.@..wD...D..q.P.O.?.....2P....t..
13:43:59.944022 IP xxx.170.http > xxx.113.52026: P 2946665288:2946665812(524) ack 1221764226 win 432
E..4*\@.@..yD...D..q.P.:...HH...P.......HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:42:03 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=dtmsljts7gfebhij4jhkt76e75; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 78
Connection: close
Content-Type: application/json-rpc
{"error":"Invalid response from long-poll request.","result":null,"id":"json"}
13:43:59.944091 IP xxx.170.http > xxx.113.52026: F 524:524(0) ack 1 win 432
E..(*]@.@...D...D..q.P.:...TH...P...-^..
13:43:59.944370 IP xxx.113.52026 > xxx.170.http: . ack 525 win 16294
E..(..@.~.eND..qD....:.PH......UP.?..g..
13:43:59.981456 IP xxx.113.52026 > xxx.170.http: F 1:1(0) ack 525 win 16294
E..(..@.~.eMD..qD....:.PH......UP.?..f..
13:43:59.981474 IP xxx.170.http > xxx.113.52026: . ack 2 win 432
E..(*^@.@...D...D..q.P.:...UH...P...-]..
13:44:00.417881 IP xxx.113.52048 > xxx.170.http: S 387224838:387224838(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
E..4..@.~.e4D..qD....P.P.......... .Ll..............
13:44:00.417910 IP xxx.170.http > xxx.113.52048: S 3089436255:3089436255(0) ack 387224839 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4>
E..4..@.@...D...D..q.P.P.%._........................
13:44:00.418212 IP xxx.113.52048 > xxx.170.http: . ack 1 win 16425
E..(..@.~.e?D..qD....P.P.....%.`P.@).z..
13:44:00.418829 IP xxx.113.52048 > xxx.170.http: P 1:230(229) ack 1 win 16425
..@.~.dYD..qD....P.P.....%.`P.@).u..POST / HTTP/1.1
Connection: close
Content-Length: 44
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2
{"method": "getwork", "params": [], "id": 1}
13:44:00.418849 IP xxx.170.http > xxx.113.52048: . ack 230 win 432
E..(..@.@..)D...D..q.P.P.%.`....P.......
13:44:00.948140 IP xxx.170.http > xxx.113.52048: P 1:1133(1132) ack 230 win 432
E.....@.@...D...D..q.P.P.%.`....P....u..HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:44:00 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=63481nkntcud9f6m4pagb9b1t7; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1
Content-Length: 596
Connection: close
Content-Type: application/json-rpc
{"error":null,"result":{"midstate":"b182bf7d65f2d20ac82d0d4b565784c2068e9d74540395d99371d401a3771bd3","data":"000000010bf5756fc40209bedd2d96da3a11c0c58e17ead100c5b17f000092cc000000008580d382a53b5854437590690a3931aef8099d83a94942bf6394ac2fc7a09a9b4dc827de1b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"}
13:44:00.948266 IP xxx.170.http > xxx.113.52048: F 1133:1133(0) ack 230 win 432
E..(..@.@..'D...D..q.P.P.%......P.......
13:44:00.948593 IP xxx.113.52048 > xxx.170.http: . ack 1134 win 16142
E..(..@.~.e=D..qD....P.P.....%..P.?..C..
13:44:01.297377 IP xxx.113.52048 > xxx.170.http: F 230:230(0) ack 1134 win 16142
E..(..@.~.e;D..qD....P.P.....%..P.?..B..
13:44:01.297402 IP xxx.170.http > xxx.113.52048: . ack 231 win 432
E..(..@.@..&D...D..q.P.P.%......P.......
13:44:01.734129 IP xxx.113.52049 > xxx.170.http: S 3138450324:3138450324(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
E..4..@.~.e D..qD....Q.P.......... .I...............
13:44:01.734154 IP xxx.170.http > xxx.113.52049: S 3082134796:3082134796(0) ack 3138450325 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4>
E..4..@.@...D...D..q.P.Q.............:..............
13:44:01.734452 IP xxx.113.52049 > xxx.170.http: . ack 1 win 16425
...)..@.~.e+D..qD....Q.P.......
13:44:01.734985 IP xxx.113.52049 > xxx.170.http: P 1:203(202) ack 1 win 16425
P.@)....GET /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1 HTTP/1.1
Connection: close
Host: bitproxy.xxxxx.com
Authorization: Basic xxx
User-Agent: phoenix/v1.2
13:44:01.734999 IP xxx.170.http > xxx.113.52049: . ack 203 win 432
..._P...K`..D...D..q.P.Q...
13:44:02.170888 IP xxx.113.52050 > xxx.170.http: S 2138553343:2138553343(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
...............qD....R.P.w........ ..
13:44:02.170915 IP xxx.170.http > xxx.113.52050: S 3093645464:3093645464(0) ack 2138553344 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4>
E..4..@.@...D...D..q.P.R.eH..w.......,..............
13:44:02.171211 IP xxx.113.52050 > xxx.170.http: . ack 1 win 16425
E..(..@.~.e'D..qD....R.P.w...eH.P.@)....
13:44:02.171933 IP xxx.113.52050 > xxx.170.http: P 1:230(229) ack 1 win 16425
..@.~.dAD..qD....R.P.w...eH.P.@)....POST / HTTP/1.1
Connection: close
Content-Length: 44
Host: bitproxy.xxxxx.com
Content-Type: application/json
Authorization: Basic xxx
User-Agent: phoenix/v1.2
{"method": "getwork", "params": [], "id": 1}
13:44:02.171954 IP xxx.170.http > xxx.113.52050: . ack 230 win 432
E..(\.@.@.S.D...D..q.P.R.eH..w..P....7..
13:44:02.670896 IP xxx.170.http > xxx.113.52050: P 1:1133(1132) ack 230 win 432
E...\.@.@.O^D...D..q.P.R.eH..w..P....u..HTTP/1.1 200 OK
Date: Mon, 09 May 2011 17:44:02 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
X-Source-Code: https://github.com/cdhowie/Bitcoin-mining-proxy
Set-Cookie: PHPSESSID=m3et5o4vie44qhibp48aol5ge0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Long-Polling: /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=1
Content-Length: 596
Connection: close
Content-Type: application/json-rpc
{"error":null,"result":{"midstate":"50c28d3c275afafd87eed724bd0d5b1847e9dbdda7e79e12ed0e6418ff49766f","data":"000000010bf5756fc40209bedd2d96da3a11c0c58e17ead100c5b17f000092cc00000000cb9cc4fb77da766429a30281b126ccec2aa1e6675f45a1067d56ff2c3bf1be654dc827de1b0098fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"},"id":"json"}
13:44:02.671014 IP xxx.170.http > xxx.113.52050: F 1133:1133(0) ack 230 win 432
E..(\.@.@.S.D...D..q.P.R.eM..w..P.......
13:44:02.671333 IP xxx.113.52050 > xxx.170.http: . ack 1134 win 16142
E..(..@.~.e.D..qD....R.P.w...eM.P.?..k..
13:44:03.047103 IP xxx.113.52050 > xxx.170.http: F 230:230(0) ack 1134 win 16142
E..(..@.~.e.D..qD....R.P.w...eM.P.?..j..
13:44:03.047124 IP xxx.170.http > xxx.113.52050: . ack 231 win 432
E..(\.@.@.S.D...D..q.P.R.eM..w..P.......
13:44:03.483509 IP xxx.113.52049 > xxx.170.http: F 203:203(0) ack 1 win 16425
P.@)....~.e D..qD....Q.P..._...
13:44:03.520512 IP xxx.170.http > xxx.113.52049: . ack 204 win 432
...`P...K_..D...D..q.P.Q...
This is mid-stream, i.e. I let the miner run for maybe 2 minutes, then turned on the sniffer when I thought it would throw the error, so it sent in maybe 2 or 3 successful shares, then the miner threw a disconnection error per below: [09/05/2011 13:43:22] Result: f780500d accepted [09/05/2011 13:43:53] Result: 98a41184 accepted [09/05/2011 13:44:06] Disconnected from server [09/05/2011 13:44:07] Connected to server The capture looks completely normal to me, based on my (very lay) knowledge of the protocol. |
|
|
|
|
Yes it's already disabled in php.ini:
;
; Safe Mode
;
safe_mode = Off
Though I think it would be a good idea to go back and mention as dependencies (in the INSTALL file) that safe_mode should be disabled, and that this (quite obviously) requires php json support, which is an add-on for PHP versions prior to 5.3.
Anyway this could very well have something to do with long polling. I tried setting my max execution time (php.ini) to 1500 seconds, up from 30 seconds. It did the following:
[08/05/2011 23:21:44] Connected to server
[08/05/2011 23:21:49] Result: be0189d3 accepted
[08/05/2011 23:21:54] Result: 62cffe98 accepted
[08/05/2011 23:21:58] Result: 65b66b0e accepted
[08/05/2011 23:22:31] Result: 2ca96088 accepted
[08/05/2011 23:22:38] Result: 8bd7c27e accepted
[08/05/2011 23:22:39] LP: New work pushed
[08/05/2011 23:22:47] Result: c662da7b accepted
[08/05/2011 23:23:20] Result: b9b3a17f accepted
[08/05/2011 23:23:30] Result: 889e14f2 accepted
[08/05/2011 23:23:31] Result: 1b237f90 accepted
[08/05/2011 23:23:38] Result: 9da72831 accepted
[08/05/2011 23:24:33] Result: ca84878c accepted
[08/05/2011 23:24:40] Disconnected from server
[08/05/2011 23:24:41] Connected to server
[08/05/2011 23:24:43] Result: 1b1964ce accepted
[08/05/2011 23:24:57] Result: 6b5df998 accepted
[08/05/2011 23:25:41] Result: 86510be4 accepted
Any other ideas?
|
|
|
|
Fix just got pushed to the Git repository; please pull and see if the problem goes away.
Thanks, that gets connected and accepting work now, but after maybe 3 minutes of mining, I see a random disconnect: [08/05/2011 20:27:46] Connected to server [08/05/2011 20:28:30] Result: 9f0a0a6e accepted [08/05/2011 20:28:31] Result: 6731f6a4 accepted [08/05/2011 20:28:55] Result: a0527e09 accepted [08/05/2011 20:28:59] Result: 196f2c04 accepted [08/05/2011 20:29:17] Result: 65173661 accepted [08/05/2011 20:29:21] Result: 564ba46a accepted [08/05/2011 20:29:47] Disconnected from server [08/05/2011 20:29:48] Connected to server [08/05/2011 20:30:05] Result: 40071f20 accepted [08/05/2011 20:30:24] Result: a6206ab4 accepted [08/05/2011 20:30:33] Result: 73d3021d accepted [08/05/2011 20:30:34] Disconnected from server [307.16 Mhash/sec] [9 Accepted] [0 Rejected] [RPC (+LP)] Let me know how I can help diagnose this. |
|
|
|
|
Show Posts
