<electronic_eel>
the interesting thing is that it is a 1U half width rack unit and has a SFP+ slot
<electronic_eel>
otherwise 2 GHz and 10 GSPS, 4 ch and 8 bits
<electronic_eel>
but if they really manage to make use of the 10 gig ethernet that would be a very nice scope for scopehal
<Degi>
I disassembled one of those really cheap SMA cables with the red-pinkish transparent jacket (about 3 mm thick coax) and it seems to contain silver coated copper wires and PTFE insulation
<electronic_eel>
i just browsed a bit through the programming manual for the DS8000-R. it seems they are using their regular scpi stuff for the 1gbase-t interface and the sfp+ interface is totally separate from that
<electronic_eel>
there is a special :SFP command to enable the sfp+ interface. and you set a *remote* ip and port
<electronic_eel>
so it seems like they are pushing raw data to that port or something. the programming manual doesn't tell.
<electronic_eel>
so it could be that the sfp+ interface is internally connected to a fpga to get good throughput and not to the applications processor
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
<GenTooMan>
actually SCPI takes a huge amount of time to process over a TCP connection because of TCP overheard. So it is more likely they switched to that because it's a heck of a lot faster. In fact the turn around time is pretty slow, if you send the data through the same TCP pipe so a secondary network connection greatly improves data capture performance.
<GenTooMan>
I experienced this when writing an FTP client as well so it's a known issue when working with TCP.
<azonenberg>
yeah this is why in my scope stuff i use scpi for control plane traffic
<azonenberg>
and waveforms separately
<GenTooMan>
I wish they had experience writing function TCP code. azonenberg my suggestion if you are willing to listen is to copy FTP's PASiVe mode communication. This sends an IP and socket address for the client to connect to for receiving data.
<GenTooMan>
that simplifies what the client needs to do and allows you to following a well proven convention.
<GenTooMan>
well that and it allows you to support ANY IP address to boot LOL
<azonenberg>
GenTooMan: in the picoscope bridge i have two server sockets on well known ports
<azonenberg>
one for control and one for data plane
<azonenberg>
no need to send IPs and ports over the scpi interface
<azonenberg>
the client just connects twice
<_whitenotifier-a>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JRpmj
<_whitenotifier-a>
[scopehal-apps] ncicek opened issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://git.io/JRp11
<_whitenotifier-a>
[scopehal-apps] ncicek commented on issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://git.io/JRpMv
<_whitenotifier-a>
[scopehal-apps] ncicek commented on issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://git.io/JRpMI
<_whitenotifier-a>
[scopehal-apps] ncicek edited issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://git.io/JRp11
<electronic_eel>
i can understand why rigol chose to separate the sfp+ for data and the 1gbase-t for scpi. they don't need to forward the scpi from the fpga to the applications processor then, simplifies the implementation a bit.
<electronic_eel>
but they don't support setting a netmask and default gateway on the sfp+, and that i think that is cheaping out
<electronic_eel>
also they don't support ipv6, just ipv4 and their understanding of ipv4 is a bit questionable to me
<electronic_eel>
quoting their programming manual about the format of ipv4 addrs: "The format of <string> is nnn,nnn,nnn,nnn. The range of the first section of "nnn" is
<electronic_eel>
from 0 to 223 (except 127), and the ranges of the other three sections of "nnn" are from
<electronic_eel>
0 to 255."
<electronic_eel>
i don't think that a proper implementation of this in gateware is that much much work
<electronic_eel>
azonenbergs solution where the client just connects to two different ports on the same ip is much more elegant though
<_whitenotifier-a>
[scopehal-apps] azonenberg commented on issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://git.io/JRpHQ
<azonenberg>
Yeah exactly
<azonenberg>
and in hardware the fpga will take anything destined to the apps processor and foraward it
<azonenberg>
by port number
<electronic_eel>
yeah, but you need to mux the ip packets into the datastream between fpga and apps processor. so the people developing the gateware and hardware have to work together on this. if the manager enforces this, it is possible, but if time to market is top prio, then they might skip it because of the necessary internal coordination work
<electronic_eel>
*and apps processor software i meant
<azonenberg>
Yeah
<azonenberg>
My plan is to basically have it be a 3-port switch internally
<azonenberg>
but instead of using mac address to determine the destination for each packet it will use the tcp port number
<azonenberg>
all non tcp, plus any tcp port the fpga doesnt want, goes to the AP
<electronic_eel>
the switch is implemented as part of the gateware, right?
<miek>
i suspect they wanted to keep a normal ethernet port for basic uses, so it made sense to split it like that
<electronic_eel>
i guess you don't want some broadcom part in there...
<electronic_eel>
the 1gbase-t is ok and makes it more versatile. but allowing to stream up to 1gbit over it with the exact same protocol as over the 10gibt would be the proper solution
<electronic_eel>
maybe they ran out of pins on their fpga. or they don't use an fpga for the fast data handling but an asic, and didn't properly think this part through when designing the asic
<electronic_eel>
other than that the rigol scope looks interesting to me. but they don't have a actual network throughput figure in the datasheet. so that would have to be tested
<_whitenotifier-a>
[scopehal-apps] ncicek commented on issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://git.io/JRp5m
<azonenberg>
That is the plan
<azonenberg>
miek: in my case, my plan is to support either 1000base-T, 1000base-X, or 10Gbase-R on the uplink
<azonenberg>
there will be an SFP and an RJ45
<azonenberg>
if the optic is connected it will use that port preferentially
<azonenberg>
if not, it will fall back to copper
<electronic_eel>
wouldn't it be cheaper to plug in a copper sfp module in the sfp+ slot?
<electronic_eel>
these modules are like 20 bucks
<electronic_eel>
and you don't need extra lines on the fpga then
<electronic_eel>
or are you planning ahead and want to keep the option of adding a qsfp port?
<azonenberg>
That is an option but then it requires i be able to fall back to sgmii mode vs just 1000base-X. also it means you can't hook to both
<azonenberg>
and yes qsfp is an option too
<azonenberg>
I havent figured out details yet. MAXWELL will have qsfp and rj45 ports
<electronic_eel>
qfsp28 for 100gbit...
<azonenberg>
the qsfp will also be able to operate lane 1 in 10g mode with a breakout cable
<azonenberg>
qsfp28 needs higher speed serdes than kintex7 can provide
<electronic_eel>
gruetzkopf recently posted in ##whitequark about a 100gbit switch he bought for about 500 bucks
<electronic_eel>
celestica dx010, some datacenter seems to have retired a big batch
<azonenberg>
oh cool
<azonenberg>
I'm keeping my nexus 3064x as my core switch for the foreseeable future