s34n has quit [Quit: ChatZilla 0.9.93 [Firefox 49.0.2/20161031074316]]
<whitequark>
please post the complete cmake output
<ohsix>
whitequark: tcp/ip thing, perf has tracepoints for ~all the network stuff, you could record it and see which part :D
<ohsix>
you'd think 4 bytes would be the fast path
<whitequark>
I'm not using linux
<ohsix>
shaaaaaaaaaaaaame ;]
<whitequark>
it's a bare metal device using a custom OR1K CPU
<ohsix>
ah
<ohsix>
which ip stack?
<whitequark>
well, two, really, it's an asymmetric multiprocessing system
<whitequark>
linux is far too fat for our goals
<ohsix>
i need to look at the small ip stacks, the ones in contiki and junk
<whitequark>
lwip
<whitequark>
contiki *is* junk
<whitequark>
everything that adam dunkels wrote is awful
<ohsix>
ehh
<ohsix>
except lwip?
<ohsix>
huhu
<whitequark>
lwip is total garbage
<whitequark>
every single feature it has, is broken in some way
<ohsix>
yea i dunno how many people use contiki or lwip, if it's nto many there are likely huge obvious bugs
<whitequark>
supposedly many major corps (according to wiki) use lwip
<whitequark>
no one cares about uip, contiki, or the rest of the stuff he wrote, except a handful of hobbyists who don't know better
<ohsix>
yea, i think that's what's in stm32cube's ip stack stuff
<whitequark>
i'm sorry you had to use that
<ohsix>
i havent', yet
<whitequark>
try picotcp
<ohsix>
i've just seen it in there
<ohsix>
so the use of lwip is out of your control?
<whitequark>
soooort of
<whitequark>
we went LGPL
<whitequark>
if you can tolerate GPL, picotcp seems like a good choice
<whitequark>
we did not extensively use it but it seems fine, and anyhow it would be really hard to write a TCP/IP stack worse than lwip
<whitequark>
we are going to migrate to a good BSD stack, but it is for now unpublished, and the deal is still in the works
<whitequark>
there are no other OSS stacks
<whitequark>
so just not much choice here
<ohsix>
yea that i know
<cr1901_modern>
I keep confusing the guy who did Contiki with the guy who did TempleOS
<cr1901_modern>
Booooy, that's a doozy of a character...
<ohsix>
have you kept notes of why lwip sux, or filed bugs or something i can look at
<ohsix>
dunno if i'll ever realistically get to use it
<whitequark>
mostly random breakage
<whitequark>
it will call you with broken pointers even after the connection is closed
<whitequark>
the nagle algorithm is broken
<ohsix>
oh wait, it is used on the esp8266 i think
<whitequark>
the keepalive alorithm is broken in extremely subtle ways
<whitequark>
the PPP support had some bugs, I think
* whitequark
shrugs
<whitequark>
for us it's a never-ending stream of headache. obscure bugs that you never fully know how to fix
<ohsix>
i have teh stevens networking book,c ould just write a new one out of that ;]
<whitequark>
pffffff hahaha good luc
<whitequark>
the thing about tcp is that you aren't writing it to the RC
<whitequark>
*RFC
<whitequark>
you are writing it to the zillion buggy implementations out there if you want your packets to reliably traverse networks
<ohsix>
yea
<whitequark>
this is the real complexity in tcp impl
<cr1901_modern>
You write it to whatever wireshark picks up ;)
<whitequark>
that's just a way to write another buggy implementation
<whitequark>
maybe u shouldn't
<cr1901_modern>
Well is the RFC "wrong by design" or "wrong by nobody bothered to follow it"? Or both?
<whitequark>
the RFC isn't wrong
<whitequark>
that doesn't help you though
<cr1901_modern>
b/c there's 10,000 impls all incompatible w/ each other?
<ohsix>
there's more ml/bug traffic than i expected
<cr1901_modern>
It's really sounding like "portable simple TCP/IP impl" is kinda an oxymoron. I.e. the only ones that work reliably have tens of thousands of person-hours put into it. In other words, the major OS stacks.
<whitequark>
you don't need tens of thousands of hours
<whitequark>
but it's not a weekend project either
<whitequark>
mostly, you need to test it in diverse environments, by which i mean shitty environments
<whitequark>
few people actively seek out those
<whitequark>
there are also some subtleties in congestion control and such
<cr1901_modern>
Fair enough. This reminds me of an X/YMODEM impl I wrote as my first major C programming project. Testing against a number of different impls that handled "start and stop of xfers" differently (and not to spec) was fun.
<cr1901_modern>
(And XMODEM is a joke of a protocol)
<ohsix>
yea there's some ip stacks that can only have one frame or other weird restrictions due to memory or other limitations, and they only ~work with a 'full' stack
<ohsix>
if you have two of those devices talking to eachother you have to really simplify stuff
<cr1901_modern>
Hrm... :/
<cr1901_modern>
Yea, reading about uip, it only stores enough for a single packet
<ohsix>
like, windowing is entirely disabled or set unusually small
<whitequark>
uip is unusable for real stuff
<ohsix>
that kinds of turns unusual edge cases in stuff to 'all cases'
<ohsix>
well, so are the micros you'd use it on
<whitequark>
yup
<ohsix>
something brutally simplified but still talking ip is useful even in stuff that is cost sensitive
<whitequark>
there's 6lowpan, which actually works properly in these circumstances
* cr1901_modern
reads Wikipedia article on TCP/IP
<cr1901_modern>
huh, TCP/IP is a bit younger than I expected. Back then, 512kB-1MB machine RAM were the norm in the PC world. So I guess TCP/IP really was just not meant for extremely constrained systems
mumptai has quit [Ping timeout: 256 seconds]
<ohsix>
a lot of that is from the tcp part, but yea
<ohsix>
each connection has a relatively large buffer area
<cr1901_modern>
You mean a large number of 1536-whatever byte buffers, or?
<ohsix>
ah, ethernet stuff, yea maybe
<ohsix>
or at least one,d epends on how you issue them to the phy
<cr1901_modern>
I was asking b/c "a relatively large SINGLE buffer area" doesn't make that much sense to me based on how I've seen TCP/IP stacks allocate buffers. In the sample one I'm thinking of, there's a ring buffer for both the hardware when an interrupt arrives from the NIC, and a second >>
<cr1901_modern>
ring buffer for the application that's shared for send/recv.
<ohsix>
well, it's layered, you need an allocator that can append stuff and possibly grow the segment
<cr1901_modern>
When an app wants to send, the stack will look for a free buffer from the pool and let the app copy to that after which it will send the data to the NIC. When the NIC gets ack that the data was sent, the application buffer is marked as free again
<ohsix>
like bsd' stacks have mbufs
<cr1901_modern>
ohsix: I could possibly be misremembering. It's been months since I looked at the stack in question ;). I remember bits and pieces of design choices
<ohsix>
and you basically just read them out linearly or copy a chain of buffers into contiguous memory to issue to phy
<ohsix>
for reference, there's an enc80jsomethingsomething from microchip, it's an spi ethernet phy
mumptai has joined #solvespace
<cr1901_modern>
Yea I want a few of those as a Christmas gift to play with
<ohsix>
phy and mac
<cr1901_modern>
seems like the fastest way to add Ethernet to an FPGA dev board
<cr1901_modern>
or a micro*
<ohsix>
a lot of fpgas have ethernet if they're on the larger side, just need the phy/magnetics
<ohsix>
er rather they have rmii interfaces or whatever it is called
<cr1901_modern>
If I REALLY wanted to push my luck, I could do 10BASET from FPGA pins directly
<cr1901_modern>
It's a horrible idea, but I've seen it done
<ohsix>
yea i've seen bit banging w/o magnetics on an avr
<ohsix>
cnlohr i think
<cr1901_modern>
this stack I'm thinking of has a predetermined free pool of buffers just big enough to hold an Ethernet packet. Stack decides when to send application buffers out, and waits for interrupt to read in data into device-specific buffers before copying back to application specific buffers. >>
<cr1901_modern>
I'm not aware of a case where it decides to linearize a bunch of packets and send them all at once. Prob b/c the machine in question isn't running a multitasking OS :P
<ohsix>
yea
<ohsix>
the buffer weirdness doesn't need to be done on big stacks
<ohsix>
some phys are zero copy and can do gather dma to get the whole mbuf or whatever without being contiguous in memory
<ohsix>
the ones you'll use with a micro don't
<cr1901_modern>
(80286 machine ;), but close enough)
<cr1901_modern>
In any case, if I tried I prob could write my own TCP/IP stack, thanks to studying that weird one optimized for old systems. Just not something I want to undertake.
DocScrutinizer05 has quit [Disconnected by services]