BitSyncom,
The mail for batch 2 reopening date was well received:)
Can you point us where we can register an account (http://store.avalon-asics.com) in advance before batch 2 opens?
How many units are left for batch2 reopening?
10X

+1
So we can count on that even trade-in is not available when batch2 reopens we will get some sort of discount?
 
PS. How about ordering ASIC PSC separately?
 
I have a lot of psu's available and will be no problem for me to assemble openwrt host?
 
Are you considering the option for ordering PCB asic boards separately when batch 2 reopens
 

BitSyncom,
As long as I want to order some Avalons when batch 2 reopens, I will ask you to confirm following:


1. Will you send us a letter notifications when batch 2 shall reopen?
2. Are we going to be able to trade-in lancelots? The trade-in is not still available on the store
3. Ca we pay as guest using walletbit - transfer BTC from our wallets?

I am waiting for your responses
Thank you

Kon,

There is a potential memleak introduced with latest commit:
Add timestamps to stratum_share structs as they're generated and copy
https://github.com/ckolivas/cgminer/commit/1bf1f4a2174c28a3ae358c6a8b9544e93f35bfac

work->sessionid = strdup(pool->sessionid);

However work->sessionid has been never freed.

Probably the right place to free it is:

void clean_work(struct work *work) {
  if(work->sessionid)
      free(work->sessionid);
....

}

More over it might be a memleak here also even though i am not quite sure about it

https://github.com/ckolivas/cgminer/commit/c851f3959894379b213cd81ecbf8317b2ad4f313

pool->sessionid = json_array_string(res_val, 3);

if json_array_string returns a copy pool->sessionid shall be freed also somewhere right?


PS: probably this is not an issue as long as  json_array_string - > json_array_get returns  Borrowed reference and there is no need to be freed

Thank you Kon! it has been fixed:
https://github.com/ckolivas/cgminer/commit/16c7c983ae9e5ce03a2adc2c573a0c62bfdfefde


 

Gyu's,
I am checking now and then my order status from batch 1. Unfortunately i am not able to open avalon store anymore. I am landing on a blue page saying avalon demo store. Does anyone have an idea how can we open batch 1 store?

Be prepared for CNY surprises soon:) hot news are knocking on the door

Kon,

I see you are making some speed optimizations to cgminer constantly. Here are two commonly used functions (utils.c) which are speeding things up. I am running them for a week with latest cgminer git on openwrt host and i386 just fine.

Adopted from:
http://www.autohotkey.com/board/topic/19483-machine-code-functions-bit-wizardry/page-8
Thanks to Laszlo
bool hex2bin(unsigned char *p, const char *hexstr, size_t len)
{
   bool ret = false;
  unsigned char b, c, d;
  for(; {
      c = *hexstr++; if (c == 0) break;
      b = c >> 6;
      *p = ((c & 15) + b + (b << 3)) << 4;
      d = *hexstr++; if (d == 0) break;
      b = d >> 6;
      *p++ |= (d & 15) + b + (b << 3);
      len--;
   }

   if (likely(len == 0 && *hexstr == 0))
      ret = true;
   return ret;
}


 Adopted from ToHex:
http://nefigtut.ru/wp-content/uploads/2011/08/bitcoin-4diff.txt
Thanks to davids
char *bin2hex(const unsigned char *p, size_t len)
{
   unsigned int i = (unsigned int) len;
   unsigned char *iptr = (unsigned char *) p;
   static char hexmap[16] = { '0', '1', '2', '3', '4', '5', '6', '7',
                               '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
   ssize_t slen;
   char *s;

   slen = len * 2 + 1;
   if (slen % 4)
      slen += 4 - (slen % 4);
   s = calloc(slen, 1);
   if (unlikely(!s))
      quit(1, "Failed to calloc in bin2hex");
     int mm = 0;
      while (i-->  0)
    {
        s[mm++] = hexmap[*iptr>>4];
        s[mm++] = hexmap[*iptr&15];
        iptr++;
     }
     //s is calloced already - filled with zeros no need to terminate char
     //s[mm]=0;
   return s;
}

Kon (Kano),
Memleak is gone! I was mining with stratum and was hitting bug badly when submitting work


Thank you

Jeff,

You can take a look here:

https://github.com/ckolivas/cgminer/commit/7e2b1e80aafc431f8572ad57bb012f2dfe7f7c97


I am testing this on my openwrt and i am having zero memory leaks for almost 10 hours. I guess when you mine with stratum, Avalon memory will be exhausted very soon, which can cause system reboot.

Are you having cgminer patches (source) related to avalon?
Someone from Avalon team has to send you recompiled/updated cgminer package probably.

Yeahh sounds reasonably.
Choice is yours dude. But it may turn out that when you as a buyer pay shipping the discount is gone. And it does not worth the effort at all

Dude,
It does not really matter where is he shipping from. All you need to negotiate the price with him, and he will sent your board directly to avalon, because he is going to sent three already as posted above
Sounds logical to me

+1
But unfortunately i have a feeling that it is not going to work that way for batch 2

I am not native speaker but:

http://launch.avalon-asics.com/?page_id=778

Trade-Ins - Avalon will continue to honor our old customers providing trade-in programs of old generations units, FPGA, and in the future for first generation ASIC modules. The Trade-In Orders are not part of the 600 unit limitation existing in Batch #2.

Probably they are not taking them for batch 2 or or each one of us shall get refund sometime later. I have asked for clarification, but no one respond

Kano,

You can trust me on that with 2.10.4 before latest commit it was eating 45M of ram for 2-3 days maks:)

I know what i am talking about..
From the other hand:
top

                                          %VSZ
 1519  1513 root     S    64436 104%  20% /usr/bin/cgminer -o mint.bitminter.co

root@cgminer:~# free
             total         used         free       shared      buffers
Mem:         61752        29652        32100            0         3652
-/+ buffers:              26000        35752
Swap:            0            0            0

cgminer  VSZ stays untouched for 5 hours or so and free looks exelent

Kano,
Thank for your input.
I am not using GBT only stratum. The part of the problem may be related to latest kon git fix related to submitting stratum work. I am running latest git with fix and looks good for last 5 hours or so. I can be sure if that was major leak eating openwrt RAM after a day or two


Best

PS:if you can take a look at pool_active it will be great. I looked at it but there are some labels (jumps), and i do not know jsoon methods - which of them return pointer (no need to be freed) and which one of them return copies (like strdup). I suspect that in that function can be a memleak also but i am not sure

I know:)
I was wondering if pool_active is causing any additional leak. That is why I posted all the output

Kon,

I saw your memleak commit an i am testing it already.
However i am not sure though, there might be some other memleaks when calling pool_active which is happening quite often. I am attaching valgrind output just in case

The other stuff seemed not to be freed on cgminer exit which is not an issue:) Or i think so..
10X

==8359== HEAP SUMMARY:
==8359==     in use at exit: 908,508 bytes in 4,143 blocks
==8359==   total heap usage: 31,624 allocs, 27,481 frees, 41,232,886 bytes allocated
==8359==
==8359== 10 bytes in 2 blocks are definitely lost in loss record 24 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x5C83D71: strdup (strdup.c:43)
==8359==    by 0x41F7F0: extract_sockaddr (util.c:871)
==8359==    by 0x404DB3: detect_stratum (cgminer.c:558)
==8359==    by 0x404EA0: set_url (cgminer.c:582)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 32 bytes in 1 blocks are definitely lost in loss record 73 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x403F4A: string_elist_add (miner.h:528)
==8359==    by 0x404C7F: add_serial (cgminer.c:507)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 35 bytes in 2 blocks are definitely lost in loss record 75 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x5C83D71: strdup (strdup.c:43)
==8359==    by 0x41F810: extract_sockaddr (util.c:872)
==8359==    by 0x404DB3: detect_stratum (cgminer.c:558)
==8359==    by 0x404EA0: set_url (cgminer.c:582)
==8359==    by 0x433E98: parse_one (parse.c:110)
==8359==    by 0x4336B9: opt_parse (opt.c:213)
==8359==    by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 44 bytes in 1 blocks are definitely lost in loss record 82 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x41D624: resp_hdr_cb (util.c:129)
==8359==    by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E61527: (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x41E3A9: json_rpc_call (util.c:377)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 49 bytes in 1 blocks are definitely lost in loss record 89 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x41D624: resp_hdr_cb (util.c:129)
==8359==    by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x4E61527: (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359==    by 0x41E3A9: json_rpc_call (util.c:377)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 160 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359==    by 0x4149F6: pool_active (cgminer.c:4794)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 161 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x41F338: thr_info_create (util.c:767)
==8359==    by 0x41C965: main (cgminer.c:6790)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 162 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x41F338: thr_info_create (util.c:767)
==8359==    by 0x41CBDD: main (cgminer.c:6850)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 163 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359==    by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359==    by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359==    by 0x4149F6: pool_active (cgminer.c:4794)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 531 (504 direct, 27 indirect) bytes in 1 blocks are definitely lost in loss record 176 of 212
==8359==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x405E0D: make_work (cgminer.c:1361)
==8359==    by 0x41CCEC: main (cgminer.c:6886)
==8359==
==8359== 727 (104 direct, 623 indirect) bytes in 1 blocks are definitely lost in loss record 180 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414AC1: pool_active (cgminer.c:4807)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 1,383 (104 direct, 1,279 indirect) bytes in 1 blocks are definitely lost in loss record 187 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414CA2: pool_active (cgminer.c:4852)
==8359==    by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 65,432 bytes in 1 blocks are definitely lost in loss record 210 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x425CF6: _io_new (api.c:652)
==8359==    by 0x42DC0D: api (api.c:3684)
==8359==    by 0x412662: api_thread (cgminer.c:4348)
==8359==    by 0x52A1E99: start_thread (pthread_create.c:308)
==8359==    by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 672,368 (104 direct, 672,264 indirect) bytes in 1 blocks are definitely lost in loss record 212 of 212
==8359==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359==    by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5092C74: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x50930A2: (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359==    by 0x41E6F1: json_rpc_call (util.c:425)
==8359==    by 0x414CA2: pool_active (cgminer.c:4852)
==8359==    by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== LEAK SUMMARY:
==8359==    definitely lost: 66,418 bytes in 12 blocks
==8359==    indirectly lost: 674,193 bytes in 3,866 blocks
==8359==      possibly lost: 1,152 bytes in 4 blocks
==8359==    still reachable: 166,745 bytes in 261 blocks
==8359==         suppressed: 0 bytes in 0 blocks
==8359== Reachable blocks (those to which a pointer was found) are not shown.
==8359== To see them, rerun with: --leak-check=full --show-reachable=yes
==8359==
==8359== For counts of detected and suppressed errors, rerun with: -v
==8359== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 2 from 2)
 valgrind --lea
ak-check=full ./cgminer --api-port 9999 --per-device-stats --api-
-network --api-listen  -S/dev/ICA0 --icarus-timing=1:38
==8748== Memcheck, a memory error detector
==8748== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8748== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8748== Command: ./cgminer xxxxxxxxxx --api-port 9999 --per-device-stats --api-network --api-listen -S/dev/ICA0 --icarus-timing=1:38
==8748==
 [2013-02-02 12:00:23] Started cgminer 2.10.4

Super!
My hash rate is about 9200 Mh/s on that host. Probably that is the reason why jgarzik has frequent restarts with his Avalon...

Thanks once again ..I am watching git closely and will compile/upgrade new version immediately and let you know how it goes
10X

Guy's

I am running my lancelot cluster on tp-link openwrt platform with 64M of ram. I am noticing the restart of my system because cgminer 2.10.4 slowly and steadily eats all of the available free RAM about 45M.

And when cgminer eats all memory (45M) it takes about 2-3 days following happens

Feb  1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Kernel kills cgminer because system is running out of ram

Is there a way to reduce mem usage when cgminer is compiled for openwrt?

10X
PS: Otherwise it runs perfect same as when my pc i386 was used. No hashing speed decrease. The only difference was that my PC had 4G of RAM

Exactly..
pls do excuse my English sucks:)

root@cgminer:~# free
             total         used         free       shared      buffers
Mem:         61752        28748        33004            0         2928
-/+ buffers:              25820        35932
Swap:            0            0            0
root@cgminer:~# top
Mem: 28772K used, 32980K free, 0K shrd, 2928K buff, 8432K cached
CPU:  23% usr   0% sys   0% nic  76% idle   0% io   0% irq   0% sirq
Load average: 0.39 0.22 0.11 2/79 14414
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
14414 14397 root     R     1536   2%  15% top
 6062  6056 root     R    69864 113%   8% /usr/bin/cgminer

And when cgminer eats all memory folowing happens

Feb  1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0