* qu1j0t3 <3 'rampant layering violations' ... was it zfs that first provoked this phrase or is it an older meme?
<whitequark> it's not a meme, I am just using words.
azonenberg_hk has quit [Remote host closed the connection]
azonenberg_hk has joined ##openfpga
digshadow has quit [Quit: Leaving.]
woddy has joined ##openfpga
<pie_> azonenberg_hk gave my presentation today, it wasnt half bad though we were already over time so i didnt get to say much :(
<pie_> azonenberg_hk, btw silicon.sexy isnt registered afaict :P
<azonenberg_hk> lol
woddy has left ##openfpga [##openfpga]
<qu1j0t3> whitequark: Ah okay. Those precise words were used about ZFS by a Linux kernel dev, a few years ago
<azonenberg_hk> whitequark: basically i think the reason is, on older hardware CRCs were expensive to do in software
<azonenberg_hk> So the NIC vendors moved it to silicon
<azonenberg_hk> also because if an incoming packet has a bad CRC you dont want to waste time interrupting the CPU to process it
amclain has quit [Quit: Leaving]
digshadow has joined ##openfpga
<balrog> ha, the Apple AirPods each contain a PSoc4 and like 5 or 6 other ICs
<balrog> http://mindtribe.com/2016/12/apple-airpods-teardown/ - yikes that's a lot of stuff packed in there
<azonenberg_hk> So upon closer inspection
<azonenberg_hk> bidir SPI in greenpak is physically impossible
<azonenberg_hk> the hard IP has MOSI and MISO on the same pin
<azonenberg_hk> balrog: wow
<balrog> azonenberg_hk: yeah. no wonder they were having issues ramping up production
<azonenberg_hk> psoc, probably broadcom btle, accelerometer why?
<azonenberg_hk> why do headphones need an imu
<balrog> detect taps against the side I believe
<azonenberg_hk> Are they doing head tracking so you move your head and the sound keeps coming from the same virtual position in space?
<azonenberg_hk> because THAT would be cool
<balrog> and track when you pick them up
<azonenberg_hk> wouldnt work on stereo audio thouhg i think
<balrog> it would be interesting if they're using that for noise correction for the mics
<azonenberg_hk> it would need a lot of mono emitters with x/y/z coordinates relative to your head
<azonenberg_hk> and many channels of source data (like game audio)
<balrog> officially though it's to detect when you tap them twice
<balrog> anyway I did get a pair and they do sound pretty good (for some reason I can't stand in-ear and headphones are too bulky)
<azonenberg_hk> i normally prefer over-the-ear but i only use them at desks
<azonenberg_hk> In-ear is not something i would use for fun however they are effective for radio communication in high-noise environments
<azonenberg_hk> In which case its normally a one-ear acoustic tube setup
<balrog> yes
<azonenberg_hk> And i have yet to find one of those that has a good mic that allows intelligible speech
<balrog> :-/
<azonenberg_hk> If i am not doing something where I care about somebody else hearing the radio traffic (usually not a major concern)
<azonenberg_hk> I prefer the over-the-shoulder police style speaker mics
<azonenberg_hk> i have an IP67 one for my ham radio that works nicely when biking in the rain etc
Ardeshir has joined ##openfpga
<Ardeshir> Hello!
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 258 seconds]
[X-Scale] is now known as X-Scale
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
wpwrak has quit [Ping timeout: 260 seconds]
wpwrak has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Ardeshir_ has joined ##openfpga
Ardeshir has quit [Read error: Connection reset by peer]
Ardeshir_ has quit [Client Quit]
Ardeshir has joined ##openfpga
Ardeshir has quit [Remote host closed the connection]
woddy has joined ##openfpga
wodsworth has joined ##openfpga
woddy has quit [Disconnected by services]
wodsworth is now known as woddy
wodsworth has joined ##openfpga
woddy has quit [Remote host closed the connection]
wodsworth is now known as woddy
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Ping timeout: 248 seconds]
wodsworth has joined ##openfpga
woddy has quit [Ping timeout: 250 seconds]
woddy has joined ##openfpga
wodsworth has quit [Ping timeout: 250 seconds]
wodsworth has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
woddy has quit [Ping timeout: 250 seconds]
woddy has joined ##openfpga
wodsworth has quit [Ping timeout: 258 seconds]
woddy has quit [Ping timeout: 260 seconds]
woddy has joined ##openfpga
wodsworth has joined ##openfpga
woddy has quit [Ping timeout: 250 seconds]
woddy has joined ##openfpga
wodsworth has quit [Ping timeout: 260 seconds]
wodsworth has joined ##openfpga
woddy has quit [Ping timeout: 250 seconds]
woddy has joined ##openfpga
wodsworth has quit [Ping timeout: 246 seconds]
wodsworth has joined ##openfpga
woddy has quit [Ping timeout: 260 seconds]
azonenberg_hk has quit [Read error: Connection reset by peer]
Bike has quit [Quit: tfw]
azonenberg_hk has joined ##openfpga
massi has joined ##openfpga
kuldeep has quit [Quit: Leaving]
kuldeep has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 258 seconds]
<azonenberg_hk> whitequark: oh btw i implemented synthesis support for the SPI block on greenpak and documented the library primitive
<azonenberg_hk> Haven't done the bitstream generation side yet
<azonenberg_hk> I'm going to hold off on the parallel fabric output as that will require router changes
<azonenberg_hk> driving the DCMPs and DACs will be comparatively easy
<whitequark> ack
<azonenberg_hk> So current short-term greenpak plan is as follows
<lain> >driving the comparators will be comparatively easy
<azonenberg_hk> Get SPI slave working so you can drive DACs and DCMPs in DCMP (not PWM) mode from the SPI
<azonenberg_hk> fix up clock input routing to counters
<azonenberg_hk> Get DCMP working in PWM mode
<azonenberg_hk> finish DAC support
<azonenberg_hk> then ADC is last
<azonenberg_hk> and we're done with gp4 afaik
<azonenberg_hk> for the 4662x at least
<azonenberg_hk> still lots of tweaks and optimizations, but feature complete
<azonenberg_hk> lain: well so here's the thing
<azonenberg_hk> DACs take their inputs from either a synth-time constant or the DCMP input
<lain> I just liked the comparator/comparatively wordplay there :P
<azonenberg_hk> DCMP input is just a few muxes
<azonenberg_hk> But the parallel fabric output, well...
<whitequark> lain: lol
<azonenberg_hk> tl;dr is that the SPI parallel output block steals a bunch of fabric routing resources
<azonenberg_hk> specifically it knocks out a few clocks plus the DCMP outputs in one matrix
<azonenberg_hk> Which means if you use the SPI parallel output
<azonenberg_hk> you cannot use DCMP1 or DCMP2, only DCMP0
<azonenberg_hk> You also lose the matrix 1 buffered copies of all three oscillator outputs
<azonenberg_hk> Which means you have to use cross-connections to forward them from matrix 1 if you need them
<azonenberg_hk> this will be nontrivial to implement in the routr
<azonenberg_hk> b/c when i implement the graph right now i have the osc's in both matrices
<azonenberg_hk> so i need to parse the input netlist before i build the graph
<azonenberg_hk> then delete the matrix 1 copy of the oscillators if the spi parallel output is used
woddy has joined ##openfpga
wodsworth has quit [Ping timeout: 246 seconds]
woddy has quit [Ping timeout: 246 seconds]
wodsworth has joined ##openfpga
woddy has joined ##openfpga
wodsworth has quit [Ping timeout: 250 seconds]
woddy has quit [Ping timeout: 246 seconds]
wodsworth has joined ##openfpga
pie_ has joined ##openfpga
wodsworth is now known as woddy
pie_ has quit [Ping timeout: 240 seconds]
clifford has quit [Ping timeout: 265 seconds]
pie_ has joined ##openfpga
azonenberg_hk has quit [Ping timeout: 260 seconds]
azonenberg_hk1 has joined ##openfpga
azonenberg_hk1 is now known as azonenberg_hk
<qu1j0t3> whitequark: wow, did you take the snowflake pic?!?!
<whitequark> qu1j0t3: nope
<whitequark> found it on the net
pie_ has quit [Ping timeout: 268 seconds]
<qu1j0t3> ah. I know there are SEM owners in heree, are you one of them?
<whitequark> no
<whitequark> not really have the space for it
<qu1j0t3> we can dream though, eh
<lain> what snowflake pic :o
<lain> whoaa
<whitequark> qu1j0t3: maybe one day. my plate is more than full, I have no time to learn and run a SEM anyway
<whitequark> nor much use for it. I'm being practical
* qu1j0t3 nods
<whitequark> could probably fly to Japan to hackerfarm anyway, I think that has a SEM?
<whitequark> and it's pretty close
<whitequark> cheap 4h flight
<azonenberg_hk> whitequark: well if you visit the sf bay area
<azonenberg_hk> digshadow has one
<azonenberg_hk> not that you'd do it on a regular basis but if you're visiting, might be fun
<whitequark> azonenberg_hk: yeah I know
<whitequark> there are certainly SEMs for rent in shenzhen anyway
<whitequark> that might be the cheapest and quickest option anyhow
<whitequark> .. huh
<whitequark> http://www.istgroup.com/english/3_service/03_01_detail.php?MID=5&SID=93 provides SEM and FIB, I should ask them for a quote
pie_ has joined ##openfpga
<balrog> azonenberg_hk: re: earpods: "Beamforming microphones are coupled with an additional accelerometer in order to filter out unwanted noise"
<azonenberg_hk> balrog: o_O
<azonenberg_hk> So they do active noise canceling
<azonenberg_hk> accelerometer though... how does that work for noise?
<azonenberg_hk> they have mics too
<balrog> "Beamforming microphones are coupled with an additional accelerometer in order to filter out unwanted noise"
<balrog> I'm not sure.
<lain> huh.
<nats`> maybe low freq noise
<nats`> if you have a big bass sound it's almost impossible to avoid it
<nats`> so by putting an accelerometer on the setup you can cancel it in 3D
<nats`> just a theory
<qu1j0t3> sounds good
<nats`> low freq will make your microphone moves
<nats`> (not the case for higher freq sound)
<nats`> + if I'm not wrong beamforming should have same problem as directionnal microphone
<nats`> you take two mic put them at 90°
<nats`> but your passband is totaly depend of the space between the two mic along that 90° axe
<qu1j0t3> /b 5
<nats`> irssi fail :p
azonenberg_hk has quit [Ping timeout: 260 seconds]
<qu1j0t3> weechat
<qu1j0t3> i should make myself a coffee as punishment
<nats`> :)
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined ##openfpga
azonenberg_hk has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
wodsworth has joined ##openfpga
woddy2 has joined ##openfpga
woddy has quit [Ping timeout: 250 seconds]
woddy2 has left ##openfpga [##openfpga]
pie_ has joined ##openfpga
wodsworth has quit [Ping timeout: 246 seconds]
massi has quit [Quit: Leaving]
pie__ has joined ##openfpga
amclain has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
pie__ has quit [Ping timeout: 248 seconds]
* whitequark stares
<whitequark> so if you get unknown protocol, you're responding with ICMP Protocol Unreachable
<whitequark> if you get a packet to an unknown UDP port, you're rsponding with ICMP Port Unreachbale
<whitequark> if you get an unknonw TCP port then you're responding with an RST?
<whitequark> what a mess
<azonenberg_hk> Lol
<azonenberg_hk> i mean it kinda makes sense, TCP has state
<azonenberg_hk> and if you dont have the port open you want to close that state
<azonenberg_hk> UDP does not have state
<azonenberg_hk> and there's no standard way in UDP to say the port isnt available
<balrog> azonenberg_hk: what if ICMP is turned off?
<azonenberg_hk> or any way to distinguish unreachable/filtered from closed
<lain> https://en.wikipedia.org/wiki/Thousand-yard_stare <- the result of staring into the RFC abyss for too long
<whitequark> balrog: then you should find your network administrator and give him a kick in the ass
<azonenberg_hk> balrog: this is one of many reasons icmp should not be turned off :p
<azonenberg_hk> among other things, it means networks with weird mtus fail silently
<azonenberg_hk> vs sending smaller tcp segments
<balrog> azonenberg_hk: our security group likes to turn off ICMP because apparently having it on prevents them from using acceleration in their firewall appliance
<azonenberg_hk> wuuut
<balrog> or rather block it in the firewall
<azonenberg_hk> i have had lots of corp networks block OUTBOUND ping requests
<azonenberg_hk> no idea why
<balrog> I'm not sure if they're blocking all ICMP though or just pink
<balrog> ping*
<azonenberg_hk> And i once had a bug where certain websites wouldnt load at my parents
<whitequark> "certain websites won't load" instantly screams "MTU" at me
<azonenberg_hk> whitequark: yes, it does now
<azonenberg_hk> not then :p
<whitequark> loll
<azonenberg_hk> Anyway, yeah
<azonenberg_hk> 1500 byte MTU
<azonenberg_hk> PPPoE header meant actual link MTU was 1492
<azonenberg_hk> (ADSL)
<whitequark> I had no doubt whatsoever it was PPPoE
<azonenberg_hk> So any time a website sent a packet in the 1493-1500 byte size range it never made it
<balrog> ADSL is generally PPPoE
<azonenberg_hk> balrog: yeah well, this was my first time setting up ADSL
<balrog> so what's the solution?
<azonenberg_hk> this was years ago
<balrog> ahhh
<azonenberg_hk> balrog: Have the router advertise a 1492 byte link MTU
<balrog> oh, so it was lying?
<balrog> or did someone change it to "increase performance"?
<qu1j0t3> azonenberg_hk: +1, that's what i recall from my first ADSL setup
<whitequark> I think the way I solved is by using -j TCPMSS --clamp-mss-to-pmtu
<azonenberg_hk> ip tcp adjust-mss
<azonenberg_hk> it was a cisco
<whitequark> so this handles the case where..
<whitequark> the sender thinks that link MTU is 1500 because it's connected to ethernet
<azonenberg_hk> i think it just patches the tcp header in an outbound SYN to negotiate a slightly smaller MTU
<whitequark> something between the sender and the receiver drops th ICMP Size Exceeded packets
<azonenberg_hk> Yes
<azonenberg_hk> this is exactly what happened
<whitequark> then you have to hack the TCP packets to artificially restrict MSS
<azonenberg_hk> And packets in the 1493-1500 byte size range died
<azonenberg_hk> Correct
<whitequark> because the sender has no idea it has to do it
<azonenberg_hk> So i did it on the router
<azonenberg_hk> one line config change, problem solved
<azonenberg_hk> whitequark: "some websites didnt load" screamed DNS problem to me initially
<whitequark> qu1j0t3: are you @crzwdjk by any chance
<azonenberg_hk> i spent way too much time barking up the wrong tree
<lain> fragmentation can do weird things to firewalls if the admins are too lazy or the firewalls are too stupid to deal with it
<whitequark> screw fragmentation
<azonenberg_hk> Fragmentation means you set the MTU wrong
<azonenberg_hk> Fix your MTU and drop all frags
<whitequark> ... with TCP
<azonenberg_hk> UDP packets rarely if ever have to be bigger than a sane MTU
<whitequark> with UDP not so much
<azonenberg_hk> most protocols over udp are designed to cap max packet size for this exact reason
<azonenberg_hk> with TCP its easy to patch the mss
<whitequark> yeah
<whitequark> >When IPv6 is used as the network protcol, the MSS is calculated as the maximum packet size minus 60 bytes. An MSS of 65535 should be interpreted as infinity.
<whitequark> >infinity
<whitequark> really?
<whitequark> infinity?
<whitequark> this is the value you suggest?
* lain dies
<azonenberg_hk> whitequark: fwiw thats a SHOULD
<qu1j0t3> >.<
<azonenberg_hk> so at least you have the option of being smaller :p
<whitequark> lol
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Bike has joined ##openfpga
mifune has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 252 seconds]
pie__ has joined ##openfpga
digshadow1 has quit [Quit: Leaving.]
m_w has joined ##openfpga
woddy has joined ##openfpga
woddy has left ##openfpga [##openfpga]
Lord_Nightmare has quit [Ping timeout: 258 seconds]
digshadow has joined ##openfpga
Lord_Nightmare has joined ##openfpga
mifune has quit [Ping timeout: 248 seconds]
Lord_Nightmare has quit [Ping timeout: 250 seconds]
Lord_Nightmare has joined ##openfpga
<rqou> whitequark: i tried contacting the electrolab people about whether i need to arrange a visit and i got no replies
<rqou> do i just show up during their listed hours of 1400-1900?
<whitequark> yes
<rqou> unfortunately their website is basically 100% french
<nats`> rqou, yep
<rqou> anyways, we're leaving for france tomorrow
<nats`> they are pretty cool
<rqou> nats` are you in the paris area?
<rqou> meetup?
<nats`> I'm but not at the moment unfortunately
<nats`> :|
<nats`> where do yo ucome from ?
<rqou> i am currently in london
<nats`> I may travel to Silverstone in a near future
<rqou> from california USA originally
<nats`> ahhhh never went to USA
<nats`> :)
<rqou> anyways, being a "stupid american" in paris is going to be fun :P
<nats`> paris is not a complicated city
<nats`> but electrolab is not directly in paris
digshadow has quit [Quit: Leaving.]
<nats`> it's the north west
<whitequark> nanterre is not very hard to find
<whitequark> there's a train stop nearby
digshadow has joined ##openfpga
<nats`> yep
<rqou> so how does public transit work in Paris?
<whitequark> rqou: you buy a paper ticket
<rqou> is there a transit card I can get?
<whitequark> need to select depart/arrival station at the vending machine
<nats`> how long do you stay here ?
<whitequark> not sure about transit cards, I was only for 3 days in fr
<rqou> 3 days, then heading into Germany
<nats`> and you'll move a lot ?
<nats`> where is your hotel ?
<rqou> not sure, no real plan yet
<rqou> hotel is grand hotel saint michel
<nats`> ah cool directly in the center :)
<rqou> nats` what do you recommend we see or do?
<nats`> the electrolab is cool, there is the tmplab too
<nats`> if you never came here you have to see ;but not necessarily visit it, eiffel tower
<nats`> the Musee d'orsay and Louvre are must see too :)
<nats`> if you like modern art, beaubourg is cool :)
<nats`> it's not a legend there are so much things to do in paris
digshadow has quit [Ping timeout: 268 seconds]
digshadow has joined ##openfpga
pie__ has quit [Quit: Leaving]