sb0 changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs :: Due to spam bots, only registered users can talk. See: https://freenode.net/kb/answer/registration
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined #m-labs
gruetzkopf is now known as gruetze_
vup has quit [Quit: Ping timeout (120 seconds)]
vup has joined #m-labs
gruetze_ is now known as gruetzkpf
gruetzkpf is now known as gruetzkopf
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
attie has quit [Ping timeout: 246 seconds]
attie has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/bc4a8157c0c8f27b18af35ed7cb93c1268d3b7f9
<GitHub-m-labs> artiq/master bc4a815 Sebastien Bourdeauducq: kasli: add tsinghua2
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined #m-labs
sb0 has quit [Quit: Leaving]
<bb-m-labs> build #1950 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1950
<bb-m-labs> build #1951 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1951
<bb-m-labs> build #2650 of artiq is complete: Exception [exception board_unlock_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2650 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub61> [smoltcp] dlrobertson commented on issue #211: After spending some time reviewing the linux kernel, it seems that the linux kernel does not allow for repeated NDISC options.... https://github.com/m-labs/smoltcp/issues/211#issuecomment-435029243
<GitHub79> [smoltcp] dlrobertson commented on issue #211: After spending some time reviewing the linux kernel, it seems that the linux kernel does not allow for repeated NDISC options.... https://github.com/m-labs/smoltcp/issues/211#issuecomment-435029243
sb0 has joined #m-labs
<GitHub-m-labs> [artiq] jordens opened issue #1187: urukul: support per-channel IO_UPDATE https://github.com/m-labs/artiq/issues/1187
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
<kristianpaul> o/
mauz555 has joined #m-labs
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
mauz555 has quit [Remote host closed the connection]
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
key2 has joined #m-labs
<key2> I'm thinking about making something between a logic analyzer and an oscilloscope using http://www.ti.com/lit/ds/symlink/lm97600.pdf and record the stream on 16 SSD sata disk
<key2> basically to sniff high speed signal for debugging PHY's for example
<key2> any thought ?
<cr1901_modern> SIXTEEN SSDs?
<key2> yeah
<key2> its 40Gb/s of data :)
<whitequark> key2: not gonna work
<key2> so i thought using 16 mSATA disk on a xc7a200
<key2> whitequark: ?
<whitequark> modern SSDs are SLC-buffered MLC
<whitequark> write performance goes to hell very quickly
<whitequark> now streaming to 16 HDDs, now we're tlaking
<key2> HDD take much more room
<whitequark> they also work
<whitequark> unlike SSDs
<whitequark> in this application
<key2> whitequark: those msata ssd announce sequencial write of 320 to 520 MB/s, it's bs ?
<whitequark> for how long?
<whitequark> maybe a few GB or a dozen
<whitequark> not the entire thing for sure
<whitequark> try it
<key2> mh
<key2> ok :/
<whitequark> yeah thats MLC
<key2> another option is MVNe, but I believe the flash inside is more or less the same at the end?
<whitequark> yes
<key2> any thechnology of SSD would work ?
<key2> or only HDD would do it
<whitequark> SLC SSD would work
<whitequark> very expensive
<whitequark> look for "industrial" "heavy duty" "high reliability" SSDs
<whitequark> they're also much smaller for obvious reasons
<whitequark> actually you could just buy a bunch of SLC NAND flash and stream directly there
<whitequark> why bother with SATA?
<key2> because sata is just 4 pins :)
<whitequark> and what happens when one of your SATA flashes is slower because it wants to reallocate some sectors?
<whitequark> with NAND you will never have such an issue
<whitequark> you do not have guaranteed latency response on SATA SSDs
<key2> yeah but if all disk are the same, and we write equal amount of raw data on all of them at the same time, why would one disk do something while other are not ?
<whitequark> because all the NAND flashes on them are different
<whitequark> some have more bad blocks on them than others
<whitequark> so, disks are not all the same
<whitequark> they also degrade differently
<whitequark> with 2 maybe it would be ok, with 16 you will observe this immediately
<whitequark> NAND flash gateware is like 100 lines... also you can share the data buses to some extent
<whitequark> need to check whats the max capacitance there
<key2> yeah but you run out of IOs
<whitequark> so, you need 8/16+3+2*n lines per flash bank
<whitequark> let's say that SSD has four NAND flashes
<whitequark> assume you can stick 16 of them on a single bank
<whitequark> you need 204 lines
<whitequark> if you can only put 8 of them (this is definitely possible) then you need 408 lines
<whitequark> ah sorry no
<whitequark> 280
<whitequark> so even less
<whitequark> thats at 16 bit wide
<key2> 8/16+3+2*n ?
<key2> u mean 8 + WE+RE+BLE..
<key2> things like this ?
<whitequark> i mean IO+CE+CLE+ALE+(RE+WE)*n
<whitequark> per bank
<whitequark> where n is count of flashes in a single bank
<whitequark> so
<whitequark> (IO+CE+CLE+ALE+(RE+WE)*flash_in_bank)*bank_count
<whitequark> I've seen NAND flashes that can do 200 MHz DDR
<key2> am checking micron
<whitequark> that's 800 MB/s per bank
<whitequark> writes take some time so you interleave writes within a single bank
<key2> how do u calculate 800MB
<whitequark> 200 MHz * 16 bit * DDR
<whitequark> thats the interface rate
<whitequark> not write rate
<whitequark> for write rate see DS
<whitequark> but you want to feed them much faster than they write so you can interleave within bank
<whitequark> so maybe even faster than 200 MHz, not sure what's the fastest bus there yet
<whitequark> ok, add a few clock pins, the DDR rates need a dedicated clock
<whitequark> one per bank i think
<key2> mmh
<key2> it ends up being more expensive at the end :)
<key2> also I wonder if it's more interesting to get 8bits or 16bits
<whitequark> more expensive than a non working design?
<key2> also am not sure you can have them all on the same bus
<key2> if you want to interleave, then you still need to be a certain amount of time on the data you are clocking
<cr1901_modern> What do you mean by interleaving writes within a single bank?
<whitequark> key2: you can have them on the same bus
<whitequark> open up any CF card
<whitequark> cr1901_modern: write page to chip A (this is fast)
<whitequark> let chip A commit page to NVM (slow)
<whitequark> while it's doing that
<whitequark> write page to chip B
<key2> ok
<key2> i see
<whitequark> let chip B commit page to NVM
<whitequark> repeat
<whitequark> key2: you can even interleave individual bytes
<whitequark> there's the "CE Don't Care mode"
<cr1901_modern> oh so you need enough chips in parallel so that chip A is done committing by the time you get back to it
<key2> so it becomes efficient when the "let A commit page" is entirely covered by other write
<whitequark> yes
<whitequark> i think with 4 chips you will already cover it
<whitequark> but calculate it yourself
<cr1901_modern> Huh, that little?
<whitequark> based on specific chip
<whitequark> cr1901_modern: page writes are fast
<whitequark> block erases are hella slow
<key2> and that is more interesting than connecting 4 of them to a SATA controller ?
<whitequark> well, if you can get a SATA controller that just does ECC
<whitequark> no remapping ever
<whitequark> then do that
<whitequark> but I do not know how to get it
<key2> mmh
<whitequark> and the savings are pretty marginal IMO
<whitequark> but I guess that makes sense
mauz555 has joined #m-labs
<whitequark> without remapping
<whitequark> it would at least work
<key2> the other option is to use a XC7A50 on a board
<key2> as a module