Topic: [Announcement] Avalon ASIC Development Status [Batch #1] - page 36. (Read 155318 times)

Seems people have purchased those. I've just gone through and canceled a lot of pending orders from more than 10+ days ago that's still in the system, so there are some more units in stock now.

it magically disapeared???

Okay. Sorry, I seem to have gotten confused, the price changed and I figured this was not still the preorder batch. It makes sense if you need the cash to not do tradeins at this time.

There are no trade-ins for this first pre order batch, but trade-ins will be available for the first mass order batch, as far as I can interpret.

Okay. I have 5 Icarus I'd like to trade-in to reserve 5 Avalon. I've sent at least 3 emails asking how to do this and have not gotten any replies so I'm making my problems public. Was the talk about using Icarus as a credit fake or are you planning on honor it?

For anyone that's interested, it looks like there are 3 units left in the store that will ship with the first batch.

avalon-asic.com

final stage? This is hard to say at the moment, we will keep the community updated however.

In addition, I've been getting questions regarding our shipping schedule and which "batch" the Order on the shop belongs to.

Inventory. Avalon learned from the mistake of our competitors and since conception has decided to release small order batches of 300 ( a number solely based on our estimated capacity) and only when a batch is close to finished, we will begin the sales of the next batch. When a new batch is announced, there will be another thread. In short, any units ordered so far, until further notice is part of batch #1, which is currently scheduled to ship at Jan 14th. In addition, as people fail to follow up with their orders, there are still some units left in the store, so if you missed your chance originally, now it's the time.

Can first batch of Avalon ASIC reach even higher speed than current 66GHash at final stage?

It's called "nttcp" or "nuttcp" on my box (Debian squeeze)

Please use this only for Avalon ASIC Development Status

Regards
Thor

the errors you are squabbling over are insignificant, you could get half a million drops and not even notice it.

Well - if newer kernels hide errors - my older one (name hidden to protect the innocent) doesn't seem to:

... my internet connection (linux box bridged using rpppoe) that runs through an old switch to my ADSL modem

eth1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx 
          inet addr:10.xxx.xxx.xxx  Bcast:10.xxx.xxx.255  Mask:255.255.255.0
          inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:601281065 errors:37121 dropped:76234 overruns:37121 frame:0
          TX packets:565768303 errors:0 dropped:0 overruns:19 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:397893249118 (370.5 GiB)  TX bytes:282719849762 (263.3 GiB)
          Interrupt:18 Base address:0xa000

07:36:19 up 112 days, 15:43

I see errors there ... to be expected ...

But the link to the main switch at home (D-Link DGS-1016D)

http://media0.symbios.pk/d-link-16-port-gigabit-rackmountable-switch-10-100-1000-m-dgs-1016d-1001.jpg

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx 
          inet addr:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.255  Mask:255.255.255.0
          inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:687446826 errors:0 dropped:0 overruns:0 frame:0
          TX packets:719410978 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:315374024750 (293.7 GiB)  TX bytes:434255477859 (404.4 GiB)
          Interrupt:18 Base address:0x2000

I see none.

Kano is trolling, but he's a constructive troll, so his message is worth replying to. I was trying to find a link to the source code of utility I used for testing, but I can't seem to locate it. It was an offshot of "ttcp".

1) RX/TX statistics in many modern NIC are always zero, unless explicitly enabled. Somebody explained to me that it has something to do with passing WHQL certification. There are (or were) apparently two levels of it: normal and certified-for-clusters. At the "normal" level it is apparently much easier to get the "compatible with Windows X" certification if errors are reported only in specific circumstances. To get uncensored statistics you'll may need to place the chip in the "enterprise" or "diagnostic" or "cluster" mode. (Not to be confused with 802.3ad link aggregation or similar stuff).

2) To get a real feel for real packet loss use "ttcp" and monitor "netstat -s". For deepest understanding use both TCP/IP and UDP/IP mode with various buffer sizes.

3) There used to be a version of "ttcp" that supported one-sided testing by connecting on the remote side to the "simple IP services": echo, discard, chargen. Nowadays they need to be enabled explicitly. They aren't really usefull for benchmarking, but they are greatly useful to see if your network hub/switch/router can really cope with many hosts talking simultaneously. Please post here if you find such an utility.

4) If you see the statistics jumping in multiplies of 16777216 instead of 1 then don't assume that the driver is majorly broken. It may simply use incorrect byte order. So swap the byte order by hand or write a short script to do byte swap.

5) Some older Unix-compatible systems still have the spray/sprayd pair of programs used for packet loss testing. You may need to explicitly enable it, but it is a very easy to use program.

Have fun.

I can't really fault your theoretical analysis. What you wrote is quite right, especially about the benefit of multicasting. But I really doubt that you've actually run such configuration for any significant period of time.

I actually have production experience with multiple clusters in multiple physical/organizational locations with quite similar properties to the ones you've described: about 50/50 mixture of multicast/unicast packets, traffic non-peaky but near-uniform, short packets.

It is our observation that to achieve effective 0% packet loss we needed to specify either Cisco Catalyst (or similar class) switches or
(quite strangely) old Allied Telesyn/NetGear ProSafe/Intel InBusiness/etc. fixed-speed (or managed) hubs. The popular unmanaged office switches like NetGear/D-Link/Cisco Linksys were all showing anywere from serval through several tens to hundred-something occurences of packet corruption/loss per day. The steady-state packet rate is 50Hz-100Hz (or pps).

Our conjecture about those rare but steady failures is that this is somehow related to how the small/cheap switches pass as FCC Class B. To get home-office rating vendors use spread spectrum clocking, which is in effect an intentional jitter. So in order to get best performance use either FCC Class A data-center grade devices or cheap obsolete hubs that passed FCC Class B because they work under CSMA/CD principle.

Oh, and an additional free piece of advice who want to build cheap multicast clusters with hubs: test whether your network adapters actually do support half-duplex. Quite a number of devices claim to support half-duplex but actually don't and need upgraded firmware or simply a replacement. Various versions of popular LNE100TX & KNE100TX are common culprits; but there are so many variants of them that you'll really need exact part numbers. Some versions of Intel PRO/100+ line drivers for Windows don't correctly work with half-duplex.

Then there is something very very wrong with your network or switch source (HuaWei?)...........

A hub sends packets to EVERY connection, making it ideal for single channel network mass communication, but fairly shite for anything else, because like USB, ethernet can only have one conversation on the wire at a time.
So if every connection is shouting to the hub, then the hub is backing off ALL the connections whilst it duplicates ALL the damned packets, to EACH connection.


 (which rules out your point Two above as well), since if you route ALL the traffic (IN/OUT) via 1  hub, then the returning hashes from the miners will prevent work being distributed and disrupt your stream.......

A switch is far more elegant, it knows the source/destination and so produces an exponential REDUCTION of traffic based on the number of connections VRS a hub.

Meanwhile on my not very expensive D-Link DGS-1008D GBit switch my desktop is connected to:

http://media.gdgt.com/img/product/12/9ry/dgs-1008d-oqx-460.jpg

p9p1: flags=4163  mtu 1500
        inet xxx.xxx.xxx.xxx  netmask 255.255.255.0  broadcast xxx.xxx.xxx.255
        inet6 xxxx::xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x20
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 62921947  bytes 33087058738 (30.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63627380  bytes 48378527420 (45.0 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

16:10:52 up 4 days,  2:51, 33 users,  load average: 1.36, 1.43, 1.48

Yep I prefer switches ...

Actually if you measure the packet loss statistic you'll find that using only hubs (or even just one hub) will give you best results. Run-of-the-mill Ethernet switches have unfortunately quite bad error probabilities.

Even the top-of-the-line Ethernet switches with 802.3x and 802.1p are just about equaling error rates of a cheap fixed-speed 10BaseT or 100BaseTX hubs with all cards correctly supporting the collision detection/exponential backoff/retry.

I'm not?

Wrong!!!!... it has little to do with the controller and far more to do with the inherent protocols and what you will use them for.

Maximum chain for the USB is 127 devices.
BUT........
Since the USB spec is SINGLE point to point communication, the limiting factor is going to be the bandwidth of the USB MINUS connects/disconnects over the speed of the number of devices.

That is to say that EVEN with 250MB/s of bandwidth OR USB3 , the shear act of connection & disconnection per device is going to be the overall limiting factor. ESPECIALLY for small packets of data (nonce result/key).

Which is WHY the absolute best way to do this would be with TWO ethernet/WIFI ports.
You could use  IP address X.X.X.254 to broadcast a STREAM of jobs continually on one ethernet port.
Then use the second Ethernet port to return results to the controller (smaller bandwidth with buffered results).
Absolutely NO need to connect/disconnect the work communication channel.

HUB the first ethernet connection. (an ETHERNET hub duplicates the same data packets on ALL connection without intervention, very high speed ESP. for a single stream.)
SWITCH the second ethernet connection.(more intelligent but induces slight switching delay)
As the secondary channel reported completion, then the primary communication channel would modify the stream to add new jobs & remove old ones.

Since it is a stream, it can scale well over multiple hubs....... USB will get buried at an exponential rate due to the speed of the ASIC clients need for WORK.


HC

Full Disclosure: This account is not one of my sock puppets, albeit I like how he thinks.