Posts

Due to the lack of money some month ago - now sounds funny - I skipped a conference where I wanted to present an approach to model group mobility of nodes. The idea is to use a form of terrain map (normally used to generate landscape models) as a basis to emulate real world motion characteristics similar. The focus are groups and their motion characterstic within the group. The terrain map is interpreted as what I called penalty map: the object wish is to evade areas with higher penalties to move from start to end....

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 …...