Jaky pocet nodu uvazujes a jake jsou prenosove naroky (rychlost, latence) ?
Co na tom hodlas provozovat za aplikaci?
Potrebujes opravdu cluster (s nizkyma latencema), nebo by ti postacil cloud (propojeni pres ethernet) ?
Chci začít se čtyřmi nody pro zkoušku a pak se uvidí. Chci na tom provozovat simulaci neuronové sítě, ale spíš jen tak pro zábavu. Ethernet bych chtěl vyloučit kvůli minimalizaci externích komponent.
Ja tohle resim s jinou deskou a nic praktictejsiho nez ethernet me nenapadlo. Vzhledem k minimalnim prenosum ktere tam planuji mit mi reseni se switchem vyhovuje. Da se udelat seriova linka, I2C atd ale tohle v clustru efektivne nevyuzijes. Treba ale nekdo ma jiny napad.
I2C vypadá jako dobrý nápad, ještě lepší by mohl být SPI. Díky za inspiraci.
I2C ? Chcete se opravdu masochisticky trestat za jakoukoli komunikaci mezi uzly, jako aby to fakt bolelo, aby ty algoritmy, co na tom chcete zkoušet, byly nuceny vyvažovat komunikaci mimo uzel zlatem? Pravda je, že tak de facto zní zadání u ANN s paralelizací na dnešním hardwaru, kde výkon jednotlivých uzlů není úplně marný, ale konektivita odkudkoli kamkoli v nějakém paralelizovaném uspořádání OPRAVDU BOLÍ - a konektivita je bohužel v ANN dost důležitá...
Přemejšlím, jestli má cenu trénovat topologii sítě genetickým algoritmem na takhle slabém železe, a jestli má cenu se na něčem takovém pouštět do dnešních trendy "deep" topologií, resp. jestli se na takhle slabém železe dá cosi hodnotně natrénovat (nasát zkušenosti) za účelem následné extrapolace na velký a drahý hardware, pokud cílová úloha bude o dva řády rozsáhlejší než Vaše domácí cvičení...
Možná byste při použití interconnectu přes i2C dokázal ANN natrénovat na telepatickou komunikaci mezi uzly :-)
Obecně v clusterech a NUMÁch se lidi v komunikaci snaží o maximální průchodnost a minimální latence mezi uzly. Takže hned po GPU je komunikační technologie druhý nejprůchodnější hardware. HyperTransport, Infiniband, switchovaná PCI-e s
NTB (non-transparent bridging) apod. Pokud bych stavěl cluster s nějakým "kozím dechem", tak RPi má pořád dost výkonný procesor, řádově srovnatelný s dnešním PCčkem, takže by měl dostat řádově srovnatelnou komunikační průchonost. Aspoň kdyby byl 1 lane PCI-e, a na to si něco pověsit. Nebo nativní Ethernet MAC on chip, ze kterého by šlo vytáhnout 100 nebo 1000 Mbps SERDES nebo 1000Base-KX (a bez PHY zapíchnout rovnou do switch matrix čipu) - tušímže s MII by to nešlo, switchovací matice sice umí MII na více portech, ale jenom v roli mastera=MACu (neumí se tvářit per port jako MII PHY). Na USB je blbé, že protější (device) konec nemá cosi jako nativní "many to many" bridge. Leda napsat něco do FPGA, co by se tvářilo jako N-krát USB Ethernet. Existují také PCI-e switche se schopností "netransparentního bridgování", takový šváb může mít třeba 96 linek, ale bude je mít sdružené po 8 nebo po 16 = nepůjde na něj pověsit 96x SoC s PCI-e x1. Hele koukám Broadcom (ex PLX?) má nějaký PCI-e switch, co umí 96 linek seskupit do do 24 portů.
Jako základní požadavek na propoj v clusteru bych viděl, že má umět bufferovaný přenos s trochu uměřeným využitím IRQ. Nikoli softwarový bit-banging. Tolik k nápadům s i2c nebo GPIO. Správně to má umět DMA, aby se s tím procesor fakt nemusel žužlat ani bajt po bajtu. A pokud se týče kapacity, jak rychle dokážete rozjet i2C? 100 kbps? No SPI by mohlo fungovat tak na 1 Mbps, ať nežeru. Ethernet v malých krabičkách dneska běžně 100 Mbps. A 1 lane PCI-e 2.5 Gbps. Takže oproti i2C jsme o 3-4 řády jinde...
P$delky stranou, ten Ethernet je podle mého zdaleka nejrozumnější možnost. I kdyby měl být navíc roubovaný na USB.
34 Odpovědí
6731 Zhlédnutí