|
Sorry, I misread. LTC wasnt part of merged mining on e.g. Bitparking; it was BTC, DVC, NMC, I0C, IXC
LTC makes use of another algorithm for the proof of work where more memory is needed, thats why FPGAs make no sence for it as GPUs dont. That was by design as I understood.
Also I woulnt holt other coins than BTC and NMC. Have Fun ...
|
|
|
|
What happens if there is a faulty USB cable in a 100 board cluster and the boards are not labeled? No BTCMiner command will help ... It would be nice to use the setserial-function via some "blinkserial"-option so that the called serial(s) begin to blink leds (for e.g. 3min or a time in seconds set via the option) without disconnecting. Also this could help identifying all boards while running and enabling the admin to (re)label them if needed.. |
|
|
|
can the btcminer used with ztex single/quad for litecoin mining ? I mined multichain on two quads without any problem. AFAIK there plainly is no difference in means of hashing, that's why it just works and also should with LC only. |
|
|
|
|
usually the timezone displayed via block-timestamps on ozcoin.net was MEST -2 (UTC), now it is MEST -12. Any Idea why?
edit: I'm on eu-server
also confirmations are not right: block 189172 still on 0 while it should be >=6 on 11:46 UTC
|
|
|
|
|
perhaps this could be a starter to make logins less necessary for just watching stats - one could link to a site/api showing stats für userid without giving personal information (e.g. the receiving hash).
|
|
|
|
there is a ToDo, cool - that'd be another nice page users could be interested and could stop asking same questions / making requests  (of course without security-issues if disclosures is healthier) I appreciate your pool working now for some days (since I signed up) without any problem, hadn't that in a while with several other pools  and your service also is quite nice, beside you care about the network not only your benefits. |
|
|
|
|
Ich hatte eine Mail mit einer Nummer zur Verfolgung erhalten. Insofern gab es keine Probleme oder Überraschungen.
|
|
|
|
another example due to the linked thread: bitcoinwatch.com tells us average for 24h, 7d and 30d - that could be a different call on api for lightening your traffic. Not regarding the api but the webinterface I'd prefer if I could set my timezone, I always get confused due to your UTC - timestamps. keep up your good work |
|
|
|
is there a way to see how much BTC i earned within the last 24 hours ? you could take a look on payouts - and calculate the average for 24h. @great what about wider api to request such data? doan know if thats interesting to more ppl. could be simpler to add 24h-earnings to current api (?) |
|
|
|
|
because he wants to use the card-systems in shops.. but i doubt its that easy. in my country the systems are not that much in use as in the us, but a shop-owner decides which systems (aka networks, such as ec, visa, mastercard, amex ..) he supports on basis of his customers needs and will not be happy puchasing another service/network-api.
also the time/delay-issue isnt dealt with - transactions are instant most of the time, but they take their time - aproximately 10min/block. so still aproximateley 1 hour to complete. it could take longer.
|
|
|
|
When complete, you'll be able to spend your bitcoins directly (no intermediary organization is necessary) at any merchant, POS, ATM, gas station etc that takes Visa or Mastercard. sorry, really dont see that point in your description. If it where to work pro bitcoin, your POS would have to accept (visa-)debt and pay bitcoin to some public key - which could be locked and verified in some way. But certainly there is no reason to trust some POS with private keys - thats the point with bitcoin. here the POS can earn trust. Reverse for paying at shops where the trader accepts visa and we want to drop bitcoin, you'd offer a public key and connect it to some virtual visa and create advice as soon as your account sees the bitcoin-amount asked for. here the customers gain trust. Chip and PIN is somewhat oldfashioned as we are used to that on creditcards, I miss the innovation. I think it is really simple, but there cannot be any chargeback what makes it a hard business for your POS. They will need good inshurance and a good customer management with trust-levels allowing higher debts. Just take a closer look to what ppl already use to trade bitcoin. Until now I did not find any (small) payments processor to take the risk, it would need a big player I think. A main problem is, that the advice for the shop is wanted to be seen immediately. But to have some certainty bitcoin takes ~10min. There you might innovate things. My point was to limit the usage to online-payments in the beginning. That would be natural. And as soon as the payment is confirmed the delivering can be started. Thats how shops are used to it. As soon as customers have gained trust-levels they also can pay with the CC offline with reasonable amounts. Verifying the customer with some card is then still needed the same way it is for oldfashioned banking. But nothing of this can be done without a central authority which comes in where your CC does. /*break*/ innovative in my eyes would be a NFC-system "mailing" encrypted messages and handling "one time" private keys directly using some bitcoin-wallet. but thats much more than a smartcard. |
|
|
|
the attacks have their downsides.. we small users on the pools get hurt and have to monitor our (less dedicated) fpga-setup. but i also see advantages.. - pools will get more robust - field gets mixed a bit as one can see in the blockchain (solving pools) or e.g. bitcoinwatch.com - improving the own setup to get backups in charge - sensitizing pool-users to withdraw regularly (prevent losses on uncommon event - if pool stops working) bit it doesnt seem to have a real impact on difficulty or global hash rate |
|
|
|
|
Did you try another pool?
Also try to use another software (cgminer with the fpga or others with yout cpu/gpu) to verify that the problem is not you or the pools connection.
I had to change them several times yesterday (seems ongoing DDOSon some pools). BitParking had problems and BTCGuild too.
The problem of BTCMiner stopping when connection-problems arise has to be fixed, also occurred during my testing of pools and somelike every 2 days in the morning on BitParking - couldnt identify the problem but think its the software (e.g. string handling with unhandled exceptions).
Right now mining at osco.in with no problem since yesterday evening.. looking forward to the next morning and monday morning...
/*break*/
besides: one of my quad-baords now is mailed to ztex due to one downclocking core, looking forward to be told I am too stupid using mx4 :\ or cleaning with isopropanol .
|
|
|
|
K, so I am not failing with my understanding of pipes.  I mean thanks to this forum and of course ztex and ppl like you it is all fine, we can read and ask .. also I could read the code myself - but for now I prefer just to document my silly ideas. just edited my suggestions-post .. perhaps it inspires someone |
|
|
|
Because it goes to stderr and not to stdout. Thanks for clarification - but now it sounds even more like a bug to me |
|
|
|
for the early morning problem.. my log says dsl connection was (re)established 12.06.2012, 04:31 - so I dont think that was the problem  miner was startet (not regarding the login data) with that one: java -cp /home/wolf/btcminer/ZtexBTCMiner-120417.jar BTCMiner -f ztex_ufm1_15y1.ihx -host http://mmpool.bitparking.com:15098 -u vv01f -p testpw -b http://de.btcguild.com:8332 vv01f_fpga testpwd -b http://eu.ozco.in:8332 accnumber testpw -l /home/wolf/btcminer/fpga.log -bl /home/wolf/btcminer/fpga-submitted.log -m c -oh 0.08 resulting finally in full stop with error msg 2012-06-12T05:03:48: Stopped thread for bus 001-0 after some problem with pool data / a string (not sure how to read that properly): 2012-06-12T04:59:28: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T04:59:32: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:10: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:16: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:30: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:57: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:23: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:40: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:56: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Invalid length of string: Disabling device
2012-06-12T05:01:56: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Invalid length of string: Disabling device
2012-06-12T05:01:57: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Invalid length of string: Disabling device
2012-06-12T05:01:57: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Invalid length of string: Disabling device
2012-06-12T05:02:11: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Invalid length of string: Disabling device
2012-06-12T05:02:41: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:02:46: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Invalid length of string: Disabling device
2012-06-12T05:02:59: Warning: Invalid length of string
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Invalid length of string: Device disabled since 2012-06-12T05:02:46
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-2: Error: Hash rate drop of 10,0% detect. This may be caused by overheating. FPGA is shut down to prevent damage. 50.0: Device disabled since 2012-06-11T06:43:14
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:57
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:57
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Invalid length of string: Device disabled since 2012-06-12T05:02:11
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:56
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-3: f=216,00MHz, errorRate=0,11%, maxErrorRate=1,23%, hashRate=215,8MH/s, submitted 10 new nonces, luckFactor=0,91
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:56
2012-06-12T05:03:29: 001-0: poll loop time: 236ms (USB: 11ms network: 225ms) getwork time: 362ms submit time: 407ms
2012-06-12T05:03:29: 001-0: Warning: 3 overflows occured. This is usually caused by a slow network connection.
2012-06-12T05:03:29: Total hash rate: 215,8 MH/s
2012-06-12T05:03:29: Total submitted hash rate: 195,7 MH/s
2012-06-12T05:03:29: --------
2012-06-12T05:03:48: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Invalid length of string: Disabling device full log for that run: Log 4 BTCMiner failing on some string error - it will expire in ~30d. Thanks for the hint with c-command while runtime.. it seems I didnt read that help properly. But for now I see no lasting effekt. Just randomly the # of 2nd fpga on the problematic board (also slowing down) changes, right now #4 is slowed down to 200 MHz and #3 I also saw disabled at first try until manual q-command. For some time the hash rate will go up, but I fear it having bad impact done to often. No offence, I will not change the setup to your firmware until ztex says its Ok for same reasons I will not set -oh above 0.1 - just prevent further damage he has nothing to do with. Instead I will try to keep at least 3 cores of that board running stable until Friday.
|
|
|
|
|
just ideas .. nothing worth, but probably sth others would also like to have
*edit due to the explanation of r0bi42
correct piping of stdout/stderr Help-output for usage with pipes
I tried -h command line switch either on Windows 7 and Ubuntu 12.04.
Not surprisingly I got the help-output for commandline switches.
As I am lazy I like to print such things into a textfile for better access.. but that doesnt work the pipe-way I am used to.
command at mine was ending:
-h >BTCMiner-help.txt
That file still is empty afterwards, but why?
- IMHO errors should be pointed to stderr instead of mixing them with 'normal' output-msg, so we could pipe just errors in some log
- e.g. help instead belongs to stdout in my mind
- help could be printed when the jar / BTCMiner is called with unexpected switches or none (just starting the jar right now results in error msg)
/edit
Error-handling
I'd like to have some possibility to actively handle errors during runtime automatically.
One could repeatingly scan the log-file for errors.. but it appears to me a simple reporting as (documented) error-numbers and exiting BTCMiner would (optionally?) be a far better solution than running nevertheless there are problems that could be dealt with.
Even better would be to communicate with another (repeating temporary) instance of BTCMiner and the running one, so that the cluster has not to stop anytime.
Changing -oh at runtime
As the runtime-commands are waiting for string-input and release by hitting [Enter]:
can you implement some runtime-command like oh=#.##
where users can (re)set overheat protection for testing without stopping the BTCMiner?
Changing pool (using -host and -b) at runtime
Same thing like the other runtime-option:
perhaps via: pool=2
could change to 1st -b and: pool=1
back to the one given by -host
Thanks for now..
|
|
|
|
70% hashrate drop per what second? As I understand it, yes - but thats not really important. Its 70% of the Number in MHz. And that one translates (counting in luck and errors) estimated 1:1 into MH/s. So due to the hash rate counted in MH/s it is estimated 70% of that. If you would count it in MH/h it still would be relative to your calculation/numbering in MH/h. The only term I do not really understand in regards of calculation is "submitted hash rate". Is it the number of total nonces translated to MH/s ? |
|
|
|
@ztex: I dont think he "complains" but only tries to point out for understanding although I estimate him having bad luck on country borders without knowing about his place - cant imagine other reason to run it that way all the time. /*! break !*/Another question due to possible failing on long (ok, here it was <24h with -oh 0.08) running the boards: Is it possible to exit BTCMiner on errors and read some error-number or parse the logs for dealing with the problem? Until now BTCMiner wont exit but trying to keep running (waiting for input q or s) and throwing error msg .. so I had to rerun manually I will add another log in the evening where such a problem with bad string stopped BTCMiner of working - could be due to the pool (but neither of the two backup pools was used) or my internet connection (error message does not say so) .. or perhaps my failing core is into that .. (will first check reconnect time of the router and get the log). But perhaps you have already some idea ... One simple solution coming to my mind, though not sure it is sufficient: running the startup-script $0 again after exiting BTCMiner (until now I stop it doing that until user agrees with some key using read -s) Or simpler: How to run clusters automatically (e.g. headless without monitoring) and handling errors best? Or: How to monitor another way than checking the logs?
|
|
|
|
|
Show Posts
