Hi drgr33n, starting screen in 0.2b gives user@linuxcoin:~$ screen Directory '/var/run/screen' must have mode 777. this is on a usb key after enabling persistence (and removing kexec and that annoying read x < /dev/console inside /etc/init.d/live-boot.sh)  best regards. spiccioli |
|
|
|
I don't know how to change MSL in Linux, though I think it's possible by patching the kernel. This will however not fix the issue completly. I'm using tcp_max_tw_bucket (or something similar) atm - that limits TW-sockets to 10k max. It works, but it does not solve the problem Jine, I've google around a little, tcp_max_tw_bucket puts a limit (default 180000) on the maximum number of sockets in TIME_WAIT, if this limit is exceeded sockets entering TIME_WAIT state are closed without waiting and a warning issued... but first you have to reach the limit. tcp_fin_timeout, or net.ipv4.tcp_fin_timeout, on the other hand, seems to be what you need. Lowering it (it could be 60 seconds right now) you should be able to limit TIME_WAIT sockets to a lower number without/before reaching the bucket limit. I mean, if you set it to 3 second, you'll end up having as many TIME_WAIT sockets as your incoming connections in a 3 seconds period, so your 25K sockets should go down to 1500-2000. spiccioli. |
|
|
|
But we're seeing 20-30k TIME_WAIT connections due to this.
It's not the overhead, it's the amount of new sockets/connections.
This is a known problem for both us, eligius and btcguild (This is why they got multiple nodes with maximum ~500GH each)
Jine, maybe I'm saying something that is known to everybody here... but, I'll say anyway since I had a similar problem long ago (not bitcoin related, though). Every socket spends some time in TIME_WAIT to correctly handle the closing of itself. You can change the time it spends in TIME_WAIT which is set too long for a localhost only socket. Per RFC every client waits 2*MSL (maximum segment life) before finally closing a socket, if you lower this time (default should be at least 120 seconds) to 10 seconds (for example) you should see that you have a lot less sockets waiting, and this should help you avoid reaching this 25K waiting sockets limit. I don't know how to change MSL in Linux, though Best regards. spiccioli |
|
|
|
That count is your shares for this round only, not your total shares ever.
Since we found a block around 7 hours ago, your local count will contain shares from the old block as well as the new block, whereas the count on the site is only since 3:30am this morning!
Thanks, I did not realize this simple issue... time to take a sleep spiccioli. |
|
|
|
|
Wuked,
I'm testing mineco.in since last night, I have two miners on it, looking at my miners I have submitted more or less 3600 shares, but my account statistics show a lot less of them
# Current rate: 49 GH/s
# Time: 0 days 08:34:05
# Total Shares: 339234
# Difficulty: 1379192
# Server Load: Low
# Your Shares 2362 (0.6963 %)
# Your Reward: 0.34835371 BTC
I'm subtracting stale shares, of course.
Is this page updated seldomly or what?
Regards.
spiccioli.
|
|
|
|
I haven't got a clue why this hasn't worked for you ? I won't be adding 11.6 to linuxcoin anyway it's very VERY unstable, stick with 11.5 for now. I got it working now and 11.6 does allow you to overclock outside of BIOS limits. The problem is that I was not installing the drivers properly. The driver seems stable in Ubuntu 11.06, but I guess it has different versions of X and other software. hugolp, can you share how you installed catalyst 11.6 on a linuxcoin 0.2a? TIA spiccioli |
|
|
|
I have no idea, but yes - hashkill tends to generate underperforming code on some hardware/SDK combinations. My best advice would be to use SDK2.4. Any older one increase the chance of fucking it up and it would like not work at all with SDK 2.1.
gat3way, linuxcoin has SDK2.4 only, so it has to be something else, sadly. best regards. spiccioli. |
|
|
|
poclbm does not work, it gives an error about access rights and I did not bother to look at it more deeply.
I've made a few more tests with your work and it always freezes or traps after a few minutes of work. The longest run has been less than half an hour. Did you chmod +x poclbm.py? yes, but it gave same error Either way, sounds like your setup doesn't like poclbm for some reason. I can't think of anything else to try. I normally don't develop GPU miners  Me neither Anyway, thanks for helping me. spiccioli. |
|
|
|
gat3way, I've made several more tests with hashkill the other night, on my system (running linuxcoin 0.2a from USB stick) I underclock memory (dual sapphire 5850 at 885/295 core/mem at 1.08V) to save energy, with these settings latest hashkill-gpu gives 555-560 MHash/s Same pc, same settings, two instances of phoenix give around 350-352 MHash/s _each_. If I increase memory speed hashkill increases output, but around 620MHash/s (885/470-500) system locks up solid, so maybe my cards can't overclock core and memory at the same time (they're stock cards, no changes to bios). Do you know what makes hashkill slower on such a system? Is there something (apart from rising memory clock) which you can change in hashkill to be able to run it on GPUs with underclocked memory ? I like the idea of a single miner handling all GPUs and I'm tired of phoenix hangings, but losing 150MHash/s is a little too much TIA spiccioli. |
|
|
|
Sadly it causes a kernel trap after a few minutes of work, I'm using it onto a LinuxCoin pc with two 5850s which has been working ok with phoenix (apart from the hang problem) for more than three weeks. Woah, weird. Have you ever run poclbm on that machine before? Hi fpgaminer, poclbm does not work, it gives an error about access rights and I did not bother to look at it more deeply. I've made a few more tests with your work and it always freezes or traps after a few minutes of work. The longest run has been less than half an hour. So I decided to go back to phoenix. Best regards. spiccioli. ps. I'm running a 2x5850s rig with linuxcoin 0.2a as operating system and I start two instances of poclbm, one for each gpu, inside a screen session like this: DISPLAY=:0 ./poclbm.py -v -d 0 -a 2 --user=... --pass=... -o api.bitcoin.cz --backup=user:pass@useast.btcguild.com:8332 My 5850s are running 885/295 (core/mem) at 1.08V and produce around 350Mh each. |
|
|
|
Let me know if it works okay. I've been running it since I posted and so far none of the instances have failed. However I haven't measured stale share ratio yet; I was getting 0.1% with the old version of phoenix I had which was very nice.
Sadly it causes a kernel trap after a few minutes of work, I'm using it onto a LinuxCoin pc with two 5850s which has been working ok with phoenix (apart from the hang problem) for more than three weeks. And when it traps I have to power-cycle the pc.  best regards. spiccioli. |
|
|
|
I have had a lot of trouble with phoenix. The biggest issue being that it oftens gets stuck on "[0 Khash/sec] blah blah" and never reconnects to the server. This is especially bad when I have torrents running, even when I limit torrent traffic. The only reason I put up with it is because phoenix supports the phatk kernel, which gets me an extra 20MH/s per card. Well, I got tired of it, so I forked poclbm and hacked it to support phatk. Here's my fork: https://github.com/progranism/poclbmSo far so good, poclbm is happily running without any issues whereas my phoenix instances are freezing up MH/s is about the same. 339 MH/s instead of the 340 MH/s I get on phoenix. Close enough. Lemme know if this helps anyone else. Thanks so much, I have the very same issue with phoenix getting stuck and making me lose hours of mining (even running several copies for each gpu is not enough since all one of them can hang if left running long enough). I'm going to test this right now. spiccioli. |
|
|
|
I got fed up with the upstart script/conf, so I managed another way to automatically start the miners. here's the solution, in case it helps someone else.
in /etc/rc.local
snipped text....
dudel42, I'm using linuxcoin and I've made something very similar to your solution, but, instead of having several detached sessions each with a miner inside (for a multi gpu setup, of course), I have shell script inside my home called 'mining.sh' which is called by rc.local and has inside su user -c 'cd $HOME && screen -dmS miners -c /home/user/screenrc.miners'
This starts a detached screen session called 'miners' and makes screen call screenrc.miners which has something like this: source $HOME/.screenrc
screen -t bitcoin.cz0 ./bitcoin.sh 0
screen -t bitcoin.cz1 ./bitcoin.sh 1
screen -t temp.0 watch -n 10 "DISPLAY=:0 aticonfig --adapter=all --odgt"
screen -t temp.1 watch -n 10 "DISPLAY=:0.1 aticonfig --adapter=all --odgt"
and what this does is to calls .screenrc, if it exists, and then creates several sessions (like C-A c) named with the word following -t each of which runs a script which calls the real miner passing a '0' or '1' to differentiate between gpus. It also calls watch -n 10 "...." which shows every 10 seconds the temperature of the GPUs The advantage of this solution is that you have a single screen session to attach to (screen -r) when you log in from remote and then you switch between the various 'windows' with C-a n (where n is a number from 0 to your last session -1) or C-A " (which shows you the session list). Hope this helps. spiccioli. |
|
|
|
The "four hours online" part is probably excessive, but seriously people, we were getting spammed really really hard. I assume this is just an emergency change to stop the flooding while they figure out a better solution.
The login 'window' offers a 'log me in forever' option, so four hours online don't mean nothing. Best regards. spiccioli. |
|
|
|
It's is quite chiken and egg issue... Hmm, more options: Allow passing these limitations with small "donation", 0.02-0.05 BTC, supports the currency and new miners  I second this; a tip of .01/.10 BTC to the forum maintainers if you have something to say, otherwise read on and shut up :O spiccioli. |
|
|
|
I think that instead of coming up with names for 0.001 and 0.000001 bitcoins we should seriously consider changing the value of 1 bitcoin. I propose that what now is 0.000001 bitcoins becomes the new bitcoin. If we want bitcoin to be widely used we have start thinking about how to make things simple for Average Joe. So, a couple of reasons why this would be better: - Bitcoin sounds like a small amount.
- While milli- and micro- is very simple to understand for a scientific community, "a thousand" and "a million" is understood more intuitively by Average Joe. So instead of having "a microbitcoin", "a millibitcoin" and "a bitcoin" in everyday use it would be better to have "a bitcoin", "a thousand bitcoins" and "a million bitcoins".
- No currency that I have used have smaller amounts than 0.01 main units. Using the new definition of a bitcoin the smallest possible amount would be just that, 0.01 bitcoins.
I don't think that it's too late to make a change like this. I'm completely with D.H. all these prefixes and suffixes are a mess to handle by average Joe. I've never seen a currency with more than two decimal places; how are you supposed to pay for you daily loaf of bread or newspaper? How much for that .... (you name it)? You need to answer such a question with something which can be spelled easily; try to ask your grandma for some coins, are you going to ask her a few milli/nano something (not to mention a few btches)? So, the bitcoin HAS to be equivalent to 100 satoshis (or 1000, if we want to use some of those decimal places), and from there we simply go up until we reach 1 million (new) bitcoins where we simply remove the decimal place which is there now and keep going up. 1 billion new bitcoins == 1,000.00 current bitcoins 1 trillion new bitcoins == 1,000,000.00 current bitcoins and so on . my 2s (satoshis) |
|
|
|
My 120MH/s rig in action:
Great!! What kind of FPGA is this? And, it seems to be a pci-e 1x board, while do you access it from a serial (?) cable? Best regards. spiccioli. |
|
|
|
A new version, this time beta quality. Fixed: * progress indicator issues (sigh) * better queueing mechanism * ADL thermal monitoring stuff now works correctly - you should have thermal monitoring and stats for all your GPUs * fixed bug on some systems causing hashkill to stop properly submitting shares * improved multi-gpu support * mining.bitcoin.cz now properly reports account info when -a is used with the correct API key New feature: * progress now autosaved in a text file, json format. It is autosaved in ~/.hashkill/bitcoin.json . This file can be parsed in order to implement external tools that collect statistics, draw graphs, provide web interface and stuff. This feature will be extended in the future to provide GPU temps info and pool stats. Download: 64-bit: http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz32-bit: http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgzPlease use sudo ./install.sh or run install.sh as root. This is especially important if you have previously installed hashkill - older files need to be overwritten. Hi gat3way, I've just downloaded it and started it on a pc with linuxcoin on a usb stick where I'm solo mining with 2x5850 against a bitcoind server (win32) in my office, the program segfaults soon after the BFI_INT magic thing. [hashkill] Version 0.2.5 [hashkill] Using GPU double mode [hashkill] Plugin 'bitcoin' loaded successfully [hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress [hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress [hashkill] Temperature threshold set to 90 degrees C [hashkill] This plugin supports GPU acceleration. [hashkill] Initialized hash indexes [hashkill] Initialized thread mutexes [hashkill] Spawned worker threads [hashkill] Successfully connected and authorized at XXX.XXX.XX:8332 [hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl) [hashkill] Binary size: 349524 [hashkill] Doing BFI_INT magic... Segmentation fault I can run it against mining.bitcoin.cz, but it spends a lot of time doing nothing. [hashkill] Version 0.2.5 [hashkill] Plugin 'bitcoin' loaded successfully [hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress [hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress [hashkill] Temperature threshold set to 90 degrees C [hashkill] This plugin supports GPU acceleration. [hashkill] Initialized hash indexes [hashkill] Initialized thread mutexes [hashkill] Spawned worker threads [hashkill] Successfully connected and authorized at mining.bitcoin.cz:8332 [hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl) [hashkill] Binary size: 349524 [hashkill] Doing BFI_INT magic... Mining statistics... Speed: 144 MHash/sec [cur: 16%] [proc: 5] [subm: 3] [stale: 0] [eff: 60%] Speed: 579 MHash/sec [cur: 84%] [proc: 6] [subm: 3] [stale: 0] [eff: 50%] Speed: 135 MHash/sec [cur: 100%] [proc: 6] [subm: 3] [stale: 0] [eff: 50%] Speed: 0 MHash/sec [cur: 100%] [proc: 6] [subm: 4] [stale: 0] [eff: 66%] with the 0 MHash/sec which happens after every 'unit of work' reaches 100%. Do you have any hints? spiccioli. ps. writing to .hashkill/bitcoin.json on a usb drive could cause wear on the unit, it would be better to have a way to stop it from writing bitcoin.json |
|
|
|
|
Show Posts
