OmniMancer has quit [Read error: Connection reset by peer]
<bubble_buster>
different friend (works in HFT now) tells me nowadays they just look at the raw packet at the (idk, physical layer? data link layer? one of the low ones, it wasn't clear which) and just guess what it means without properly decoding
GuzTech has joined ##openfpga
m_w has joined ##openfpga
<azonenberg_work>
bubble_buster: lol
<azonenberg_work>
another dirty trick i heard from HFT folks, they send packets out asking for trades before they even know if they wanted to execute the trade or not
<azonenberg_work>
decide what to do during the sending of the packet
<azonenberg_work>
then corrupt or send the correct FCS at the end
<azonenberg_work>
TD-Linux: also i think if you pipelined enough you could do multiple bytes per cycle and saturate 10/40GbE with xml parsing
<whitequark>
there are XML accelerator appliances that do this kind of thing
<azonenberg_work>
on a more serious note i plan to implement protobuf in fpga, i already did some testing
<TD-Linux>
azonenberg, it's a highly serial process so it gets gross really fast
<azonenberg_work>
i'm targeting 1 cycle per byte at the moment
<TD-Linux>
if you have long tokens it might be ok
<azonenberg_work>
It's not for hardware offload though
<azonenberg_work>
it's for using protobuf as the framing format for data going to/from an fpga
<azonenberg_work>
i wrote the varint parser and did some preliminary work then got too busy with billable work to finish
<whitequark>
I feel like that's a wrong direction entirely
<whitequark>
generate serializers and deserializers from protocol descriptions that are optimal for FPGAs, not shoehorn protobuf into that
<TD-Linux>
especially if you can always guarantee the bitstream and software pair are the same version
<azonenberg_work>
you're both missing the point
<azonenberg_work>
this is for talking to an fpga over a lan
<azonenberg_work>
from a client which could be written in anything from c++ to python
<TD-Linux>
I mean parts of protobuf (varints) make sense, but the key/value bit is ehhh
<davidc__>
TD-Linux: thats what I've done in the past, but there's something to be said for not having to reimplement the serializer/deserializer code for every existing language
<azonenberg_work>
it's not meant for minimum gate overhead
<azonenberg_work>
i'm not trying to cram things into an ice40 like whitequark, this is going to run on a kintex7
<TD-Linux>
davidc__, sure, I would have just picked a serializer with rigid schema
<whitequark>
^
<whitequark>
it doesn't have to be a bespoke format
<davidc__>
TD-Linux: Sure. And I think we all know azonenberg likes to tilt at windmills.. but he seems to make it work usually!
<davidc__>
(I mean, it could be worse. He could be implementing something based on JSON!)
emeb has quit [Remote host closed the connection]
<azonenberg_work>
davidc__: i'm going to be dealing with json in the near future re fpgas
<azonenberg_work>
but not parsing it on the fpga
<azonenberg_work>
the vivado LA "ltx" symbol file format that maps probe IDs to symbol names is json
<azonenberg_work>
some time in the next few weeks i want to reverse the xilinx debug core jtag protocol
<azonenberg_work>
And once i do that, i need the symbol file to get signal names
<azonenberg_work>
because unlike the antikernel LA, chipscope doesn't put the symbols in a jtag-readable rom
<azonenberg_work>
(use case: talking to chipscope probes from my own software)
m4ssi has joined ##openfpga
Asu has quit [Ping timeout: 246 seconds]
Asu has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
wbraun has joined ##openfpga
emeb has joined ##openfpga
<kc8apf>
apparently there is a company that built a DNS accelerator that serves line-rate 100Gbps with negative latency
<kc8apf>
unsurprisingly, absolutely no one needs this
<catplant>
negative latency?
<kc8apf>
the process the packet as it arrives. The can guess the record being requested and send the response before the whole packet has arrived
<azonenberg_work>
kc8apf: lol
<azonenberg_work>
who needs to handle that much dns traffic?
<azonenberg_work>
(ignoring the negative latency bit)
<azonenberg_work>
was this a bay area startup?
<swedishhat[m]>
kc8apf: lol that's excessive but still pretty cool. Do you remeber the company name?
<azonenberg_work>
it seems like one of those "we spent so much time figuring out how to do it we didn't stop to think if we should" deals
<azonenberg_work>
some quick googling suggests that google public DNS server ~1M requests/sec
<bubble_buster>
I imagine they set out seeking the low latency and the high throughput just sort of happened?
<azonenberg_work>
say 512 byte DNS packets is 512 MB/s
<azonenberg_work>
Or about 4 Gbps
<swedishhat[m]>
Or maybe it was something that came out of a silly fintech project. They have lots of money for things like nation-wide microwave networks for stocks and such
<azonenberg_work>
swedishhat[m]: yes but they can cache dns
<azonenberg_work>
i hiiighly doubt HFT has dns in the critical path
<azonenberg_work>
anyway my point is, i calculate that one 10GbE pipe would suffice to keep basically any imaginable DNS server more than occupied
<azonenberg_work>
100GbE would probably be enough to serve most of the internet's DNS traffic lol
<kc8apf>
I'd have to ask my friend. It was some company trying to sell to all the network operators at NANOG
<azonenberg_work>
lol
<azonenberg_work>
i'm just thinking, if 10 Gbps of DNS traffic is more than Google has to handle
<azonenberg_work>
who the HELL needs 100?
<azonenberg_work>
like, a 100GbE static content HTTP server? that's something CDNs would probably eat up
<azonenberg_work>
but 100G DNS is insane :p
<TD-Linux>
you know it's bad when azonenberg_work calls it overkill
<TD-Linux>
would have been mildly more interesting if it could have done DNS over TLS or DoH which is more computationally intensive
Asu has quit [Remote host closed the connection]
GuzTech has quit [Ping timeout: 246 seconds]
genii has quit [Remote host closed the connection]
gnufan_home has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]