This style of buffer with high and low-water points tends to cause clumping of data flows when the speeds are mismatched. What happens is that transmitter goes full steam ahead until the high water mark is hit, then the receiver effectively blocks the channel while some software in the transmitting device fills its output buffer, and that clumping can continue backing up the channel to the next higher source, and so on and so forth. Then when the receiver has bought some time it goes full steam processing its buffer until the receive buffer is at the low-water mark, then it turns the flow back on the channel, and the transmitter can empty its transmit buffer at full steam, triggering the emptying of it's source's transmit buffer and so on and so forth, back up the chain. If you imagine this process happening globally then you get circular systems with very non-linear behaviour, so I think the result is that latency on the network goes up. Back in 2015 or so someone noticed this happening on the Internet in the TCP/IP stack and they deduced that the problem was that people were making buffers too big! So there was a campaign to reduce latency by decreasing buffer sizes. This was called "buffer bloat" and apparently it worked, because buffer bloat is no longer an issue, I heard. But whether this results in more dropped packets during congestion I don't know. But dropping packets is just another sort of buffering which filters back up the chain eventually resulting in clumpy Internet behaviour as a whole. So maybe you just get times when the Internet appears to go down and your apps all stop. If so then they pushed the problem right out of their domain into the user's minds! Whether that was a good idea or not, I don't know. Personally I think that using circular FIFOs would be a better solution, as I think it might still allow large buffers but without causing clumping: circular buffers can grow and shrink linearly in proportion to the ratio of the speeds of their upstream/downstream connections. I don't really know enough about statistics to be able to analyze this properly though.
This was in The Guardian: David Turner obituary , only eight days after I posted David Turner Talking About Sixty Years of Functional Programming History : This talk was given in London in 2017: See Turner, D. A. "Some History of Functional Programming Languages" also John Hughes - Why Functional Programming Matters and David MacQueen's talk at ICFP 2015 in Numberphile - Sophie Maclean on the Catalan Numbers . At 10:30 This whole discussion abut combinator reduction is especially interesting. I didn't know Arthur Norman had tried building hardware for combinator machines. I'll look that up: maybe start here A.C. Norman Faster combinator reduction using stock hardware in LFP '88: Proceedings of the 1988 ACM conference on LISP and functional programming. At 26:25 on the ISWIM virtual machine implemented in the PAL compacting garbage collector?! This work Reynolds and others did was at MIT in Masecheusetts and Argonne National Laboratory Illinois. Did
... and his posterity too? See On Communication in Linear Time And Hypertext And The Gospel of Sophia . So it looks like El Cielo of the cistine [sic!😂] chapel is not the limit anymore. I think I just met one of his descendents. A guy called Versailles Toledo who is from Chiapas. That might explain the murals I mention in my recent untitled post , just before the post mentioning this video. I also just took this photo of Rafael Gonzales, born here in Tecate, B.C., who told me about a spring near here called Agua Fría , half way from Tecate to Loma Tova , where, a few decades ago, people used to go to have barbecues and stuff, but now he thinks it may be private land. If someone reading this has a Facebook account, please write a link to this post onto his FB page. To see why I took the photo, look at his T-shirt and the horse-shoes and ponder this: Subscribe to BeatrizER and her video(s?) about mathematical logic, ... Sounds like Edith (II) Rix has been online all the time, ...
Comments
Post a Comment