Avalon ASIC users thread

[jermwerty]

i'm getting a fair # of these on one unit.  can someone tell me what they mean?

Code:

Thu Jul 11 14:56:03 2013 auth.emerg kernel: [16129.320000] usb 1-1: clear tt 1 (0030) error -71

Thu Jul 11 14:57:16 2013 auth.emerg kernel: [16202.240000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.140000] usb 1-1.1: USB disconnect, device number 3
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.280000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.730000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.870000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Detected FT232RL
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Number of endpoints 2
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Setting MaxPacketSize 64
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.910000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio 1-1.1:1.0: device disconnected

Turn off WiFi.

There's a fuse on the board that needs to be removed to fix it.  I am actually curious myself how to remove it.  The wiki says to remove the fuse but doesn't give any instructions.  I actually ran Ethernet and put a switch in for my boxes, so I don't need the WiFi anyway.

is this the F1 fuse they were talking about a while back?  i have a batch 2 delivered just last week which i thought had that fuse already removed.  am i wrong?  

plus i've already disabled dhcp and am running a direct ethernet connection.

This is a known issue, the solution is if you are plugged in via wired to disable the wifi interface as it sucks too much power while constantly searching for an AP.  I think some people uninstall the wifi package or something?  Not sure what the correct term is...

It was said you do NOT have to remove the F1 fuse on the newer B2 Avalons, as the flaw in the old board design has been fixed and the F1 fuse is correct in the current boards.

[1713421042]

1713421042

[1713421042]

1713421042

[NiteShdw]

You can disable the WiFi interface via the web interface.  Go to Network, then Interfaces and bring down the WWAN interface.  You may also want to go to WiFi tab and disable it there also.

[bitdude]

i'm getting a fair # of these on one unit.  can someone tell me what they mean?

Code:

Thu Jul 11 14:56:03 2013 auth.emerg kernel: [16129.320000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:04 2013 auth.emerg kernel: [16130.420000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:10 2013 auth.emerg kernel: [16136.490000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:15 2013 auth.emerg kernel: [16141.550000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:20 2013 auth.emerg kernel: [16146.600000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:25 2013 auth.emerg kernel: [16151.660000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:30 2013 auth.emerg kernel: [16156.720000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:35 2013 auth.emerg kernel: [16161.780000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:40 2013 auth.emerg kernel: [16166.840000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:45 2013 auth.emerg kernel: [16171.900000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:50 2013 auth.emerg kernel: [16176.950000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:55 2013 auth.emerg kernel: [16182.010000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:01 2013 auth.emerg kernel: [16187.070000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:06 2013 auth.emerg kernel: [16192.130000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:11 2013 auth.emerg kernel: [16197.190000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:16 2013 auth.emerg kernel: [16202.240000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.140000] usb 1-1.1: USB disconnect, device number 3
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.280000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.730000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.870000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Detected FT232RL
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Number of endpoints 2
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Setting MaxPacketSize 64
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.910000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio 1-1.1:1.0: device disconnected

You have exactly the same problems as I do. I tried to disable DHCP server and WiFi + install the latest ckolivas firmware + set max temp to 45C, but it was not enough. It is better now but there was a warm day where the temperature went up and that day the cgminer restartarted 4-5 times. Another day it did not restarted at all. The OpenWRT itself is up for almost 5 days now, but cgminer keeps restarting. However, it did not need manual intervention for those 5 days, which I am happy about.

If you ever manage to fully fix this, please let me know!

[Bitconian]

Hey there,

sorry if this question has been already asked, but couldn't find any answer.

My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:

slush: 36368.844 and 50btc: 37185.844

so, I got 73553 MHS total.... where are the other 8617.436?

are they lost? or those numbers are not exact? what is more reliable?

thanks!
B.

[SolarSilver]

My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:

slush: 36368.844 and 50btc: 37185.844

so, I got 73553 MHS total.... where are the other 8617.436?

are they lost? or those numbers are not exact? what is more reliable?

I prefer to use the Failover mode, so the first pool gets 100% and if it fails, the cgminer process moves over to the second pool.

But even then, there is variance in the numbers. My 365 MHz avalon displays
MHSav 86239.66, HMS5s 87079.58 and the pools shows 86586.54

I'm sure if I look at other machines, I'll see bigger difference based on how the moving averages are calculated

[NiteShdw]

Pools typically do averages over a certain time frame.  Why worry, there isn't anything you can do if your boxes are working properly and hashing. They are doing their work.

[cypherdoc]

You can disable the WiFi interface via the web interface.  Go to Network, then Interfaces and bring down the WWAN interface.  You may also want to go to WiFi tab and disable it there also.

i don't see any "disable" or "uninstall" options.  what's the right way to permanently take it down?

nvm

[cypherdoc]

asked earlier but never got an answer.

anyone know what a normal NMW/MWC should be?

[candoo]

asked earlier but never got an answer.

anyone know what a normal NMW/MWC should be?

HW Errors or NMW/NMC isnt very intresting. just look at the hashrate, if its fine then its fine.

[burlow]

My avalon is humming along nicely between 79000 MH/s and 85000 MH/s (usually around 82000). Current room temp is between 72-75 F (22-24 C). Would I get a higher hash rate if I cooled the unit even more? I've seen the hash rate spike to 87000+, and am wondering if it would stay around there, or higher, if it were cooled even further (ie - provide 68F air straight to the fans).

[sneef]

Does anyone have a useful means of contacting Avalon?

I have two orders from February 3rd, neither of which is showing in the store.  I also have two tickets in their system, neither of which has been answered.

I waited patiently when batch 2 was delayed for everyone.  But now that they are talking about batch 3 shipping, I'm pissed.

I am in a similar situation.
I received confirmation that my entire order was shipping, but what arrived was 1/2 the machines.

I have tried to contact them via tickets, PM's & email.... 9 days and not a single word from them.

I have started a thread dedicated to Batch 2 Buyers who have a current unresolved problem.

https://bitcointalk.org/index.php?topic=255130

[cypherdoc]

i'm getting a fair # of these on one unit.  can someone tell me what they mean?

Code:

Thu Jul 11 14:56:03 2013 auth.emerg kernel: [16129.320000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:04 2013 auth.emerg kernel: [16130.420000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:10 2013 auth.emerg kernel: [16136.490000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:15 2013 auth.emerg kernel: [16141.550000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:20 2013 auth.emerg kernel: [16146.600000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:25 2013 auth.emerg kernel: [16151.660000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:30 2013 auth.emerg kernel: [16156.720000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:35 2013 auth.emerg kernel: [16161.780000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:40 2013 auth.emerg kernel: [16166.840000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:45 2013 auth.emerg kernel: [16171.900000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:50 2013 auth.emerg kernel: [16176.950000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:55 2013 auth.emerg kernel: [16182.010000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:01 2013 auth.emerg kernel: [16187.070000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:06 2013 auth.emerg kernel: [16192.130000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:11 2013 auth.emerg kernel: [16197.190000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:16 2013 auth.emerg kernel: [16202.240000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.140000] usb 1-1.1: USB disconnect, device number 3
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.280000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.730000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.870000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Detected FT232RL
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Number of endpoints 2
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Setting MaxPacketSize 64
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.910000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio 1-1.1:1.0: device disconnected

You have exactly the same problems as I do. I tried to disable DHCP server and WiFi + install the latest ckolivas firmware + set max temp to 45C, but it was not enough. It is better now but there was a warm day where the temperature went up and that day the cgminer restartarted 4-5 times. Another day it did not restarted at all. The OpenWRT itself is up for almost 5 days now, but cgminer keeps restarting. However, it did not need manual intervention for those 5 days, which I am happy about.

If you ever manage to fully fix this, please let me know!

looks like Niteshdws recommendation was good.  up 5h now w/o the error.  also from the wiki:

About [usb 1-1: clear tt 1 (8030) error -71]

Not all 703n have this problem. ignore this section if you never meet this error
There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]
In order to fix it you need had to power down the WiFi modem by disable it, use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.

note that disabling the wifi by itself did not do it for me.  i had to go the extra step of deleting the WWAN.

[fpgaminer]

Would I get a higher hash rate if I cooled the unit even more? I've seen the hash rate spike to 87000+, and am wondering if it would stay around there, or higher, if it were cooled even further (ie - provide 68F air straight to the fans).

Not really, no.  Extra cooling will only marginally improve hardware error rates, power consumption, and longevity; probably not worth the extra electric bill.  Based on your quoted hashrates, it sounds like you've already clocked up to ~350MHz, which is all you will get out of a stock Avalon, cooling or not.  Going past ~350MHz will require overvolting, which cannot be done without modifying the electronics in the unit.

Regarding the spikes, those are just due to variance and don't indicate potential hashrates.  Remember, these are mathematical slot machines; sometimes you win a lot, sometimes you lose a lot.

[bitdude]

i'm getting a fair # of these on one unit.  can someone tell me what they mean?

Code:

Thu Jul 11 14:56:03 2013 auth.emerg kernel: [16129.320000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:04 2013 auth.emerg kernel: [16130.420000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:10 2013 auth.emerg kernel: [16136.490000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:15 2013 auth.emerg kernel: [16141.550000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:20 2013 auth.emerg kernel: [16146.600000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:25 2013 auth.emerg kernel: [16151.660000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:30 2013 auth.emerg kernel: [16156.720000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:35 2013 auth.emerg kernel: [16161.780000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:40 2013 auth.emerg kernel: [16166.840000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:45 2013 auth.emerg kernel: [16171.900000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:50 2013 auth.emerg kernel: [16176.950000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:56:55 2013 auth.emerg kernel: [16182.010000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:01 2013 auth.emerg kernel: [16187.070000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:06 2013 auth.emerg kernel: [16192.130000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:11 2013 auth.emerg kernel: [16197.190000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:16 2013 auth.emerg kernel: [16202.240000] usb 1-1: clear tt 1 (0030) error -71
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.140000] usb 1-1.1: USB disconnect, device number 3
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.280000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.730000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.870000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Detected FT232RL
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Number of endpoints 2
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.880000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.890000] usb 1-1.1: Setting MaxPacketSize 64
Thu Jul 11 14:57:17 2013 auth.info kernel: [16203.910000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Thu Jul 11 14:57:21 2013 auth.info kernel: [16207.300000] ftdi_sio 1-1.1:1.0: device disconnected

You have exactly the same problems as I do. I tried to disable DHCP server and WiFi + install the latest ckolivas firmware + set max temp to 45C, but it was not enough. It is better now but there was a warm day where the temperature went up and that day the cgminer restartarted 4-5 times. Another day it did not restarted at all. The OpenWRT itself is up for almost 5 days now, but cgminer keeps restarting. However, it did not need manual intervention for those 5 days, which I am happy about.

If you ever manage to fully fix this, please let me know!

looks like Niteshdws recommendation was good.  up 5h now w/o the error.  also from the wiki:

About [usb 1-1: clear tt 1 (8030) error -71]

Not all 703n have this problem. ignore this section if you never meet this error
There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]
In order to fix it you need had to power down the WiFi modem by disable it, use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.

note that disabling the wifi by itself did not do it for me.  i had to go the extra step of deleting the WWAN.

Interesting, will try deleting WWAN, will not use it anyway. However, it seems to me that the problems are occurring with my Avalon when it overheats and by overheating I am talking about >45C. I am not certain on this yet, but for example for last 24 hours the temp was below 45C and I have not experienced a single cgminer restart. OpenWRT is now up for more than 5 days. But will delete WWAN anyway. Thanks for the tip!

[bitdude]

My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:

slush: 36368.844 and 50btc: 37185.844

so, I got 73553 MHS total.... where are the other 8617.436?

are they lost? or those numbers are not exact? what is more reliable?

I prefer to use the Failover mode, so the first pool gets 100% and if it fails, the cgminer process moves over to the second pool.

But even then, there is variance in the numbers. My 365 MHz avalon displays
MHSav 86239.66, HMS5s 87079.58 and the pools shows 86586.54

I'm sure if I look at other machines, I'll see bigger difference based on how the moving averages are calculated

I thought about this a bit and it seems that having it connected to a single pool means that you want to bet on the pool's luck. Having it spread among 2 or more pools means to eliminate the luck factor a little bit. Of course that it works on both sides, if you have it spread and one of the pools is extremely lucky, you just lost a bunch of BTCs.

[SolarSilver]

I thought about this a bit and it seems that having it connected to a single pool means that you want to bet on the pool's luck. Having it spread among 2 or more pools means to eliminate the luck factor a little bit. Of course that it works on both sides, if you have it spread and one of the pools is extremely lucky, you just lost a bunch of BTCs.

If you mine longer than a few weeks (you'll have to do that for months to ever break even ;-), it all evens out. That is the nature of luck

[burlow]

Would I get a higher hash rate if I cooled the unit even more? I've seen the hash rate spike to 87000+, and am wondering if it would stay around there, or higher, if it were cooled even further (ie - provide 68F air straight to the fans).

Not really, no.  Extra cooling will only marginally improve hardware error rates, power consumption, and longevity; probably not worth the extra electric bill.  Based on your quoted hashrates, it sounds like you've already clocked up to ~350MHz, which is all you will get out of a stock Avalon, cooling or not.  Going past ~350MHz will require overvolting, which cannot be done without modifying the electronics in the unit.

Regarding the spikes, those are just due to variance and don't indicate potential hashrates.  Remember, these are mathematical slot machines; sometimes you win a lot, sometimes you lose a lot.

That makes sense- and maybe I'm splitting hairs, but at current conditions, an increased average from say 82k to 88k is about $270/month. If I pumped chilled air through the fans, that seems worth it. I just don't know if the variation is due to heat or simply chip design (I admit I don't really know how the chips work).

[kano]

Hey there,

sorry if this question has been already asked, but couldn't find any answer.

My avalon says 82171.28 MHS and I'm currently mining in two pools.... it's been mining all day. When I check the Mhash in the pools I got this:

slush: 36368.844 and 50btc: 37185.844

so, I got 73553 MHS total.... where are the other 8617.436?

are they lost? or those numbers are not exact? what is more reliable?

thanks!
B.

The pool figures don't really mean much since they can vary a lot and even vary by pool.

Your actual mined H/s figure is: 2^32 * ( Difficulty Accepted / Elapsed )

i.e. that is the hash rate that the pool is accepting so that is, in the end, all that matters.

If Elapsed is small then of course it will vary a lot.
If Elapsed is a day or more then it should be quite accurate depending upon your mining difficulty.
(Higher difficulty will of course mean a higher variance)

[snaxion]

Sorry if this has been asked already:

Is it possible to run just wired (ethernet, no WAN)? I tried disabling the WAN hoping the packets would route through ethernet, no dice.

--S

[cypherdoc]

i'm puzzled why my NMW and MWC are both so low even after being up for over 30 hours.  and NMW 0?