Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

saminiir.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#31

Post by kazen44 »

pjmlp wrote: post #29
legulere wrote: post #27

Earlier quoted context omitted.

Isn’t garbage collection going to introduce jitter?

Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, nev…

> For example, on performance critical paths always use a standard for loop, never a for range one.

i am curious, why would one use a normal for loop, instead of a range one?

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#32

Post by TickleSteve »

pjmlp wrote: post #29
legulere wrote: post #27

Earlier quoted context omitted.

Isn’t garbage collection going to introduce jitter?

Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, nev…

GC will always introduce jitter.

You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter.

Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it.

There is a reason why the GC-enabled OSs aren't used for anything in reality.

BTW: There should be no difference between for and for-range loops given an optimiser thats working.

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#33

Post by pjmlp »

TickleSteve wrote: post #32
pjmlp wrote: post #29

Earlier quoted context omitted.

Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, nev…

GC will always introduce jitter. You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it. There is a reason why the GC-enabled OSs aren't used for anything in reality. BTW: There sho…

> GC will always introduce jitter.

> You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter.

It only introduces jitter if it runs at all.

If one really wants to be drastic in performance critical code, in most GC runtimes it is possible to just turn it off.

On Go's case a runtime.SetGCPercent(-1) will take care of that.

> There is a reason why the GC-enabled OSs aren't used for anything in reality.

And me thinking I had two running on my phones, go figure.

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#34

Post by pjmlp »

kazen44 wrote: post #31
pjmlp wrote: post #29

Earlier quoted context omitted.

Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, nev…

> For example, on performance critical paths always use a standard for loop, never a for range one. i am curious, why would one use a normal for loop, instead of a range one?

A range one might introduce boxing depending on the types being iterated.

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#35

Post by jacksmith21006 »

Written three TCP/IP stacks and the first was pretty bad as wrote off of RFCs before the Comer books.

But then purchased the Comer books and made it so much easier. Highly recommend buying the Comer books if really interested in writing a TCP/IP stack.

Also if you really want to learning something you write an implementation. To this day makes it so much easier to deal with IP problems, configuration, buying products, etc.

https://www.amazon.com/Internetworking-TCP-IP-One-6th/dp/013...

https://www.amazon.com/Internetworking-TCP-Vol-Implementatio...

https://www.amazon.com/Internetworking-TCP-Vol-III-Client-Se...

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#36

Post by jacksmith21006 »

i_don_t_know wrote: post #24

Operating System Design: Internet Working With Xinu by Douglas Comer (1987) is a nice explanation with lots of C code of how to add a networking stack to an operating system, in this case his educational unix-inspired XINU.

Highly recommend. The first TCP/IP stack wrote was before this book and had to write off of RFCs.

But man the three volume Comer books made things so much easier.

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#37

Post by GenericsMotors »

pjmlp wrote: post #34
kazen44 wrote: post #31

Earlier quoted context omitted.

> For example, on performance critical paths always use a standard for loop, never a for range one. i am curious, why would one use a normal for loop, instead of a range one?

A range one might introduce boxing depending on the types being iterated.

Or use a language with reified generics :)

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#38

Post by tonyg »

TickleSteve wrote: post #32
pjmlp wrote: post #29

Earlier quoted context omitted.

Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, nev…

GC will always introduce jitter. You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it. There is a reason why the GC-enabled OSs aren't used for anything in reality. BTW: There sho…

> GC will always introduce jitter.

Hard real-time garbage collectors (including real-time reference counting approaches) can be used in such a way as to eliminate memory-management jitter.

Region allocation - a form of GC - can be used in such a way as to avoid memory-management jitter.

> GC-enabled OSs aren't used for anything in reality.

You might have a narrow definition of what you consider to be an OS. I would argue that things like the JVM, the Erlang BEAM, and even the browser are OS-like enough to qualify.

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#39

Post by caf »

mh7 wrote: post #16
0x00000000 wrote: post #3

Does anyone know why you would use an unsigned char array to store the MAC address instead of uint8_t? Char is one byte but a but a byte is not guaranteed to be 8 bits yet MAC is defined as 48 bits

Since the fixed width integer types are optional, and if available must be 8, 16, 32 and 64 bits (and two's compl) I don't think CHAR_BITS > 8 is allowed if stdint.h types are supported since sizeof(uint8_t) must be 1.

They're individually optional - so uint16_t can exist without uint8_t.

But you're right - if uint8_t exists, it must be the same as unsigned char.

Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)

#40

Post by dullgiulio »

pjmlp wrote: post #33
TickleSteve wrote: post #32

Earlier quoted context omitted.

GC will always introduce jitter. You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it. There is a reason why the GC-enabled OSs aren't used for anything in reality. BTW: There sho…

> GC will always introduce jitter. > You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. It only introduces jitter if it runs at all. If one really wants to be drastic in performance critical code, in most GC runtimes it is possible to just turn it off. On Go's case a runtime.SetGCPercent(-1) will take care of that. > There is a reason why the G…

And the default is 100, which means a double in newly allocated memory space. I have written several servers that after starting up (and running uselessly the GC once), never need to run it again.
Post reply on HN