Since several weeks I deal with TCP Quick ACK mechanism. TCP Quick ACK where introduced to bypass the disadvantages of delayed ACKs. If a flow is not interactive and send fully Maximum Segment Sized (MSS) packets from one endpoint to the other there is no real need to artificially delay any packets. In this situation the receiving host will never send any data and the TCP instance can instantly trigger an ACK packet....
Top IPv6 Working Group posting today regarding @/127@ anycast: > to future-proof their network. future-proof == adding crap we do not understand or need
To identify the minimum or maximum of two values often a simple if else construct is used: if (a < b) min = a; else min = b; or more compact using the ternary operator: min = (a < b) ? a : b; The generated instructions for the first if/else construct and the ternary operator does not differs. At least if the compiler is instructed to optimize the code. If the code is not optimized the compiler generates a little bit awkward code with a branch for the former example....
Since several days strange things happen: Delta compression using up to 2 threads. Compressing objects: 100% (8/8), done. error: inflate: data stream error (incorrect header check) error: corrupt loose object 'ebcab349c392aadd151101e6b2651ed451ff4bf7' fatal: object ebcab349c392aadd151101e6b2651ed451ff4bf7 is corrupted error: pack-objects died with strange error as well as mysterious compile errors and stuff like that. One similarity is a raised memory access pattern, … starting memtest to verify my assumption.
Two apparently not related terms, but wait. Network neutrality can be described as a principle that no restriction by internet service providers and governments on content is applied. Restrictions can be limited network resources: Google News experience a higher Quality of Service as my Blog or even worse: you cannot connect to YouTube with your standard ISP contract. In other words: ISP’s start to consider network traffic based on their content....
TCP’s window scale factor is determined at the connection start-up. Among other things local memory constraints are checked and used as the basis to calculate the window scale shift factor. The exact procedure is complex and not of interest here. Currently the Linux network stack does not consider a reduced rcv buffer which can be reduced via setsockopt(). Today I sent a patch which fix this with some lines of code:...
just for the protocol: Linux memory management is terrible complex. Many hidden relations to and from other components in an optimized form that prevent anyone from beeing productive. {Free,Net,Open}BSD code is much more coherent and easier to understand. It is even difficult to write a proper commit message in a understandably way that more then 4 people understand why I modified the code in this way.
Since several days I started to verify the Silly Window Syndrome (SWS) avoidance algorithms and mechanism. To trigger one peculiarity (receiver side SWS) it is more or less unavoidable to shift the network stack into a special state. One requirement is that the socket buffer should be as small as possible to reduce the initial analysis delay. Via setsockopt() it is possible to tune the receiver buffer. But during some analysis I spotted an error in the current network stack, the bug is hidden in the TCP window scale option and the dynamic memory management component....
I thought about how I would design the Translation Lookaside Buffer of the Memory Management Unit (MMU) if I was the CTO of Intel, respective AMD. ;-) In one of my last postings I talked about an potential optimization for @x86/x64_64@ but at the end I decided that the effort of implementing and testing compared with the benefit is to high so I skipped this. But as said this I thought about how would I design the TLB regardless of any existing implementations …...
Via setsockopt(socket, SOL_SOCKET, SO_RCVBUF, n, 4) it is possible to increase/decrease the socket receive buffer where n is the number of byte. Internally the specified number is doubled to cover bookkeeping overhead. The minimum value is defined as SOCK_MIN_RCVBUF (256 byte). It is not possible to specify any smaler value. Even if the user specified something smaller the actual buffer is silently increased to SOCK_MIN_RCVBUF (the man page is a little bit outdated and stated that setsockopt will return with a failure - this is not correct)....