I'd like to address Felix the cat, Mickey Mouse, Snoopy, Scratchy, Mr Purr, and any other furry on this post.
I have to point out the very misunderstanding of how TCP/IP and UDP work under the hood.
TCP/IP controls work in the kernel space without any interjection from the user space.
Although UDP is in kernal space, it can be controlled in the User space, giving the programmer much more control. One reason I said tcp/ip could be faster is in the fact that a bad program (er) trying to emulate tcp/ip in user space will be slower. I have combated that by using multiple xtransmit connections with multiple async threads.
When controlling UDP in user space as I do (check out the video linked above) it will take an impact on the CPU for the mere fact that controlling udp packet burst/stream requires spin/locks on the cpu.
On the flip side, Using Huge UDP receive buffers and having a cpu which can deal with spinlocks will outperform any tcp/ip
Scratchy has come out with false statement such as QUOTE
"The kitten named Scratchy claims layer violations in modern routers and switches make it inefficient to use anything but TCP/IP."
This is not true. Again I will say that the inefficiency is bad programmers, and not understanding "burst" udp packets. They as Fluffy says are flinging packets without considerations of the network they are flinging to. This is important. If this is an internal network, we have control of the "packets" we are flinging. If not we have to find out as the programmer what type of network and latency we are slinging packets to.
Considerations a programmer slinging packets need to know:
1. Programmer have to deal with traffic shaping to control your udp streams especially coming from 10gb/s to 2.5 gb/s or less. You have to know what your pushing your packets to ie 2.5 gb/s 1gb/s / 100mb/s / 10mb/s
2. You have to turn off flow control. This just screws with your individual udp streams. The kernal wants to slow you down to max 2gb/s full duplex mode for all connections using pause packets (this is specific to the 1gb/s raspberry pi Ethernet standard connection .
3. Use the biggest buffers in your Ethernet setup, use jumbo packet-frames, buy a raspberry pi with as much memory in your budget (I bought all 16 gig memory for the fact that we end up queuing large packets into memory before transmitting.
If old scratchy needs some love, I have 5 dogs that would love to scratch that itch!
I have to point out the very misunderstanding of how TCP/IP and UDP work under the hood.
TCP/IP controls work in the kernel space without any interjection from the user space.
Although UDP is in kernal space, it can be controlled in the User space, giving the programmer much more control. One reason I said tcp/ip could be faster is in the fact that a bad program (er) trying to emulate tcp/ip in user space will be slower. I have combated that by using multiple xtransmit connections with multiple async threads.
When controlling UDP in user space as I do (check out the video linked above) it will take an impact on the CPU for the mere fact that controlling udp packet burst/stream requires spin/locks on the cpu.
On the flip side, Using Huge UDP receive buffers and having a cpu which can deal with spinlocks will outperform any tcp/ip
Scratchy has come out with false statement such as QUOTE
"The kitten named Scratchy claims layer violations in modern routers and switches make it inefficient to use anything but TCP/IP."
This is not true. Again I will say that the inefficiency is bad programmers, and not understanding "burst" udp packets. They as Fluffy says are flinging packets without considerations of the network they are flinging to. This is important. If this is an internal network, we have control of the "packets" we are flinging. If not we have to find out as the programmer what type of network and latency we are slinging packets to.
Considerations a programmer slinging packets need to know:
1. Programmer have to deal with traffic shaping to control your udp streams especially coming from 10gb/s to 2.5 gb/s or less. You have to know what your pushing your packets to ie 2.5 gb/s 1gb/s / 100mb/s / 10mb/s
2. You have to turn off flow control. This just screws with your individual udp streams. The kernal wants to slow you down to max 2gb/s full duplex mode for all connections using pause packets (this is specific to the 1gb/s raspberry pi Ethernet standard connection .
3. Use the biggest buffers in your Ethernet setup, use jumbo packet-frames, buy a raspberry pi with as much memory in your budget (I bought all 16 gig memory for the fact that we end up queuing large packets into memory before transmitting.
If old scratchy needs some love, I have 5 dogs that would love to scratch that itch!
Statistics: Posted by jackandspayne — Sun Nov 16, 2025 1:31 am